Skip to content

Migrate gsutil usage to gcloud storage#2605

Open
bhandarivijay-png wants to merge 4 commits intoGoogleCloudPlatform:masterfrom
bhandarivijay-png:ai-gsutil-migration-f9700460a55e4e4f8e8cf7fec06624a7
Open

Migrate gsutil usage to gcloud storage#2605
bhandarivijay-png wants to merge 4 commits intoGoogleCloudPlatform:masterfrom
bhandarivijay-png:ai-gsutil-migration-f9700460a55e4e4f8e8cf7fec06624a7

Conversation

@bhandarivijay-png
Copy link
Copy Markdown
Contributor

Automated: Migrate {target_path} from gsutil to gcloud storage

This CL is part of the on going effort to migrate from the legacy gsutil tool to the new and improved gcloud storage command-line interface.
gcloud storage is the recommended and modern tool for interacting with Google Cloud Storage, offering better performance, unified authentication, and a more consistent command structure with other gcloud components. 🚀

Automation Details

This change was generated automatically by an agent that targets users of gsutil.
The transformations applied are based on the gsutil to gcloud storage migration guide.

⚠️ Action Required: Please Review and Test Carefully

While we have based the automation on the migration guide, every use case is unique.
It is crucial that you thoroughly test these changes in environments appropriate to your use-case before merging.
Be aware of potential differences between gsutil and gcloud storage that could impact your workflows.
For instance, the structure of command output may have changed, requiring updates to any scripts that parse it. Similarly, command behavior can differ subtly; the gcloud storage rsync command has a different file deletion logic than gsutil rsync, which could lead to unintended file deletions.

Our migration guides can help guide you through a list of mappings and some notable differences between the two tools.

Standard presubmit tests are run as part of this CL's workflow. If you need to target an additional test workflow or require assistance with testing, please let us know.

Please verify that all your Cloud Storage operations continue to work as expected to avoid any potential disruptions in production.

Support and Collaboration

The GCS CLI team is here to help! If you encounter any issues, have a complex use case that this automated change doesn't cover, or face any other blockers, please don't hesitate to reach out.
We are happy to work with you to test and adjust these changes as needed.

Contact: gcs-cli-hyd@google.com

We appreciate your partnership in this important migration effort!

#gsutil-migration

@google-oss-prow
Copy link
Copy Markdown

Hi @bhandarivijay-png. Thanks for your PR.

I'm waiting for a GoogleCloudPlatform member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@google-oss-prow
Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bhandarivijay-png
Once this PR has been reviewed and has the lgtm label, please assign lpleahy for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Comment thread cli_tools_cloudbuild.yaml
- name: 'gcr.io/cloud-builders/gsutil'
args: ['cp', '/workspace/linux/*', 'gs://$PROJECT_ID/$_RELEASE/linux/']
- name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'gcloud'
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need entrypoint set in rollout/cli_tools_cloudbuild_build.yaml as well?

Comment thread cli_tools_cloudbuild.yaml
- name: 'gcr.io/cloud-builders/gsutil'
args: ['cp', '/workspace/linux/*', 'gs://$PROJECT_ID/$_RELEASE/linux/']
- name: 'gcr.io/cloud-builders/gcloud'
entrypoint: 'gcloud'
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. With the gcr.io/cloud-builders/gcloud image being proposed, we shouldn't need to specify entrypoint at all. The gcloud binary is the default entrypoint for these gcloud images already.

  2. However, is there a reason not to use cloud-sdk image instead: gcr.io/google.com/cloudsdktool/cloud-sdk? The gcloud image prints a notice suggesting to use cloud-sdk, before actually running gcloud.

  3. If we switch to the cloud-sdk image, then we will need the entrypoint: 'gcloud'. If we don't switch, let's remove the redundant entrypoint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants