[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCP Cloud Resources

On 4/21/21 11:42 PM, Jeremy Stanley wrote:
> On 2021-04-21 12:29:02 -0700 (-0700), Jose R R wrote:
> [...]
>> The Google SDK < https://cloud.google.com/sdk > CLI integrates
>> cooly with Linux shells: from your fav shell you can list
>> available regions/zones, machine types, etc., provision even
>> customized compute resources, check recommendations, etc., etc.; I
>> do not think any other cloud vendor, including AWS, brings the
>> same flexibility and power into a Linux shell to manipulate cloud
>> resources.
> I'm not sure what "integrates cooly with Linux shells" means (and
> Web searches didn't help much to elucidate)... are you talking about
> tab autocompletion of the commands for its CLI or something? If you
> just mean it has a CLI, then I don't expect that's particularly
> novel. Even OpenStack has one.
>     https://packages.debian.org/sid/python3-openstackclient

Yeah, it does, and it's been so for years. Though that's not only it...
Let me dig-up a little bit.

No, google-cloud-sdk doesn't integrate well in Debian. First of all,
it's *NOT* part of Debian, not even in Bullseye.

Back in 2014, in Portland, I tried to package it, and it was horrible. I
heard lots been fixed, but I'm not seeing this as a reality. Let's
investigate to see where we are now, nearly 7 years later.

Just as a quick check, I downloaded the google-cloud-sdk. The tarball
was 80 MB. It contains lots of already packaged libraries in Debian,
some being backports to Python 2.7. Here's a partial list containing the
most shocking bits (the full list of folder in lib/third_party/ contains
69 subfolders):

- argcomplete
- argparse
- backports
- enum
- functools32
- ipaddr
- pytz

worse than that: these are *stripped* versions, without the setup.py or
others, so that it becomes impossible to tell what version each
component is. So, in other words: a security nightmare.

Then I went to check the code in the "platform" folder: it's also full
of vendored libraries, using *old* versions. For example, a py2 only
version of boto. It's full of py2 only code. Some even easy stuff like
print statement instead of functions in what looks like being some code
from Google.

Python 2 support has been dropped upstream in early 2020, and we're
already in march 2021, plus Bullseye is about to be out with Python2
removed. Why even attempting to keep compatibility at this point?

Under platform/gsutil/third_party, I can see many outdated component
- mock (ie: version 2.0.0) released in april 2016.
- monotonic in version 1.4 from October 2017.
- fasteners 0.14.1 released in Nov. 2015.

All this is yet another security nightmare.

At this point, the situation is even worse than in 2014, and I would
suggest anyone using the Google SDK to only set it up on a confine
environment, such as a container, a VM or something like that.

IMO, that's *very* lame integration... Instead of doing gratuitous bold
claims, could you please do your homework, and get google-cloud-sdk in
Debian? The good thing: the way Debian works, your *very* bad practices
are completely forbidden, so you'll have to do things the right way...
And there's lots of DDs that would love to help to achieve this!

All this being said, it's very nice from Google to propose some compute
power sponsorship. Thanks a lot.


Thomas Goirand (zigo)

Reply to: