Bug P2
Status Update
Comments
gu...@gmail.com <gu...@gmail.com> #2
Totally agree. If Google engineers spent their time building lean and reliable tools instead of posting disrespectful garbage on memegen mocking other companies and products we would have a much better GCP toolset.
ma...@google.com <ma...@google.com> #3
internal bug has been created to track this:
an...@gmail.com <an...@gmail.com> #4
Another case showing negative impact of huge google-cloud-cli SDK + image sizes.
$ apt dist-upgrade
[truncated]
# this step hangs for about 90 seconds on every VM run
Preparing to unpack .../4-google-cloud-cli_464.0.0-0_amd64.deb ...
Unpacking google-cloud-cli (464.0.0-0) over (459.0.0-0) ...
Progress: [ 54%] [#####################################################.............................................]
an...@gmail.com <an...@gmail.com> #5
any thoughts from the CLI team on this? there seems to be plenty of appeals from customers. how about providing a lightweight variant that strips the bloat.
tm...@gmail.com <tm...@gmail.com> #6
Assuming Google uses the CLI internally, there should be some cost savings by making this more efficient, in addition to making GCP more usable for all of us.
kr...@cleartrip.com <kr...@cleartrip.com> #7
Its not just the size, it take lots of processing as well. Memory and CPU usage shoots up during gcloud-sdk package update or even repo refresh. We had to disable the gcloud-sdk yum repo in some of our instances.
Just curious, why did Google choose python over Go for CLI tools?
Just curious, why did Google choose python over Go for CLI tools?
ma...@gmail.com <ma...@gmail.com> #8
I had no issues invoking gcloud since 2021 until sometime April-May 2024, when invoking gcloud would freeze an instance forever and prevent it from accepting new ssh connections to diagnose the issue. Wasting a day debugging the issue revealed that snap auto-updating gcloud was the root cause of the problem.
In other words, gcloud automatic update broke my business processes and made me waste a day debugging the issue, all the while paying Google for using its resources. A mini-disaster caused solely by gcloud developers.
Why is this issue has not been solved in 1 day and is now 3 months old?
When I try to answer this question myself, nothing else comes to mind but:
1. Google creates Go language which produces compact executables with no dependencies and uses that for its own applications.
2. Google creates Compute Engine and sells CPU time and storage space.
3. Google creates gcloud command line application for Compute Engine users which takes 2GB+ of storage and takes longer to install than Windows OS.
In other words, gcloud automatic update broke my business processes and made me waste a day debugging the issue, all the while paying Google for using its resources. A mini-disaster caused solely by gcloud developers.
Why is this issue has not been solved in 1 day and is now 3 months old?
When I try to answer this question myself, nothing else comes to mind but:
1. Google creates Go language which produces compact executables with no dependencies and uses that for its own applications.
2. Google creates Compute Engine and sells CPU time and storage space.
3. Google creates gcloud command line application for Compute Engine users which takes 2GB+ of storage and takes longer to install than Windows OS.
sa...@sentinel.sc <sa...@sentinel.sc> #9
Any updates? Google engineers are you even paying any heed? The image size literally doubles because of gcloud cli insanity
ta...@gmail.com <ta...@gmail.com> #10
same issue, the google-cloud-cli is toooooooooo big for e2-micro instance
an...@gmail.com <an...@gmail.com> #11
until Google addresses this issue, give gcloud-lite a try
Description
Overview
google-cloud-cli docker images are too big. The latest tag is presently 1.2GB. Here are some of the negative side effects
google-cloud-cli python module is also large at > 1.1GB.
Example Components Wasting Storage / Image Space
Ways to Reduce Size
Docker image Info