Skip to content

Conversation

@JesseLovelace
Copy link
Member

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

@JesseLovelace JesseLovelace added the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Oct 1, 2021
@JesseLovelace JesseLovelace requested a review from frankyn October 1, 2021 20:36
@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Oct 1, 2021
@product-auto-label product-auto-label bot added the samples Issues that are directly related to samples. label Oct 1, 2021
@snippet-bot
Copy link

snippet-bot bot commented Oct 1, 2021

Here is the summary of possible violations 😱

There is a possible violation for not having product prefix.

The end of the violation section. All the stuff below is FYI purposes only.


You are about to delete the following frozen region tags.

Here is the summary of changes.

You are about to add 11 region tags.
You are about to delete 7 region tags.

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

  • Refresh this comment

Copy link
Contributor

@frankyn frankyn left a 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()
Copy link
Contributor

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>
Copy link
Contributor

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?

Copy link
Member Author

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());
}
}
Copy link
Contributor

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. */
Copy link
Contributor

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.

Copy link
Member Author

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()?

Copy link
Contributor

@frankyn frankyn Oct 29, 2021

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?

4fMNjboxUdxHV5L

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.

Copy link
Member Author

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

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.

Screen Shot 2021-11-12 at 8 04 47 AM

I think this would be valuable to capture as feedback and share upstream

.setStatus(TransferJob.Status.ENABLED)
.build();

StorageTransferServiceClient storageTransfer = StorageTransferServiceClient.create();
Copy link
Contributor

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()
Copy link
Contributor

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()?

Copy link
Member Author

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().

Copy link
Contributor

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.

Copy link
Member Author

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();

Copy link
Contributor

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.

Copy link
Contributor

@frankyn frankyn left a 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.
Copy link
Contributor

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;
Copy link
Contributor

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.
Copy link
Contributor

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();
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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.

@JesseLovelace JesseLovelace removed the do not merge Indicates a pull request not ready for merge, due to either quality or timing. label Nov 24, 2021
@JesseLovelace JesseLovelace merged commit 1cdb592 into main Nov 24, 2021
@JesseLovelace JesseLovelace deleted the stsgapicsamples branch November 24, 2021 20:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes This human has signed the Contributor License Agreement. samples Issues that are directly related to samples.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants