-
Notifications
You must be signed in to change notification settings - Fork 2.9k
(feat) Storage Transfer Service: add gapic samples and refactor test suite #6120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
frankyn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just have one question on directory structure, the code changes to the samples make this a very appealing migration for existing developers because the delta isn't as heavy.
It still does have a list of data models to worry about but the main thing that's awesome is the removal of auth init.
| // Set up the transfer job | ||
| TransferJob transferJob = | ||
| new TransferJob() | ||
| TransferJob.newBuilder() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is so nice and a lot smaller delta
| </exclusion> | ||
| </exclusions> | ||
| </dependency> | ||
| <dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question on directory structure, wdyt about moving these files one directory up outside of the storage/ directory because it's a different API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, since it's structured that way under googleapis, i think it makes sense to mirror that structure here
| System.out.println("Created transfer job between two GCS buckets:"); | ||
| System.out.println(response.toString()); | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Way more reasonable, thanks for pushing on this Jesse!
| import com.google.storagetransfer.v1.proto.TransferTypes.TransferSpec; | ||
|
|
||
| public class QuickstartSample { | ||
| /** Quickstart sample using transfer service to transfer from one GCS bucket to another. */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion ...immediately transfer from one GCS bucket to another. because datetime is not supplied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, running immediately isn't what happens. Based on the jobs created from my local runs, what actually happens is that the job is created, but does not run, and does not have any runs scheduled. To run it, you would need to do so in the console or call runTransferJob().
Should I update the quickstart to also call runTransferJob()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for clarifying, I missed that, documentation calls out that if StartTime isn't specified it will auto-start, but it may require a scheduled date to run. I think calling runTransferJob() after seems like the least complex to add after creating a job. I feel like scheduling is an advance setting.
@danielbankhead wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, just now seeing this - I think either is fine, but runTransferJob might be a bit more complex for the customer (a user would have to know to disable to job). While more verbose, I think scheduling would make more sense (although it is a somewhat of a misnomer if we want to run this one time). For this reason, I think a one-time helper function would be nice to have across the GAPIC clients.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "a user would have to know to disable to job"?
Jobs that are created and then run this way, only run once. There's no need to disable it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct that there isn't a reason to explicitly disable it; I'm thinking someone new to the product may be concerned because 'Frequency' isn't set and the documentation mentions 'Schedule one-time transfer operations or recurring transfer operations', making it a bit ambiguous if this transfer job will run again in the future.
Setting the schedule to the same date sets the Frequency to 'Once' in the UI - making it clearer to the user that this won't run again in the future.
I think this would be valuable to capture as feedback and share upstream
| .setStatus(TransferJob.Status.ENABLED) | ||
| .build(); | ||
|
|
||
| StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you move client creation before transferJob?
| CreateTransferJobRequest.newBuilder().setTransferJob(transferJob).build()); | ||
|
|
||
| storageTransfer | ||
| .runTransferJobCallable() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the only way to start the job? Wondering if there's an equivalent method such as storageTransfer.createTransferJob() -> storageTransfer.runTransferJob()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only other way would be runTransferJobAsync(). There is no runTransferJob().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for checking! Disregard this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would look like
storageTransfer.runTransferJobAsync(
TransferProto.RunTransferJobRequest.newBuilder()
.setProjectId(projectId)
.setJobName(response.getName())
.build())
.get();
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well it's nice that we have async, but let's leave that for our readers to find.
frankyn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few Nits
| @@ -0,0 +1,129 @@ | |||
| /* | |||
| * Copyright 2020 Google Inc. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2021*
| @@ -0,0 +1,388 @@ | |||
| package com.google.cloud.storage.storagetransfer.samples.test; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing copyright
| @@ -0,0 +1,64 @@ | |||
| /* | |||
| * Copyright 2020 Google Inc. | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2021*
| .build(); | ||
|
|
||
| // Create a Transfer Service client | ||
| StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to move client creation before model construction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can go either way on it. My idea was just having client creation right before the client is actually used, but I can move it up if you prefer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking consistency, but I think your right in this case. You're only creating a client when you actually need it.


This adds the gapic samples for transfer service, replacing the old apiary samples as the "main samples", while marking the apiary samples as apiary. The new gapic samples will be on the main documentation page, while the apiary samples will be in a migration guide.
This is also refactors the test suite. Previously, the tests relied on hard-coded buckets that have the correct permissions set up. This is potentially flaky, and also makes checking out the samples and running the tests difficult. Now, buckets are simply spun up, given the correct permissions, and then deleted at the end of the tests.
Do not merge label: this shouldn't be merged until all artifacts related to the migration to gapic (i.e.: the python samples, the migration guide, the quickstart guides, the CLs publishing all these), are also ready to go