Google-cloud-cli classic request

store-requests
1

From the publish step

The store was unable to accept this snap.

  • (NEEDS REVIEW) confinement ‘classic’ not allowed. If your snap needs classic confinement to function, please make a request for this snap to use classic by creating a new topic in the forum using the ‘store-requests’ category and detail the technical reasons why classic is required.

The snap google-cloud-cli is just a rename of google-cloud-sdk which is also a classic snap.

2

Hello, I compared both snaps and they are similar so I’m granting classic to google-cloud-cli. There are aliases and auto aliases associated with the google-cloud-sdk that I’m be moving to this new snap if that’s ok. Agree?

3

If the aliases thing is a move please hold off, if we can have the aliases on both snaps that would be good. We don’t want to remove the aliases from google-cloud-sdk until we know its not being used.

4

From this

we thought we could have the aliases on both snaps.

5

I just tried to do a release of revision but got this error

wfaris@wfaris-snap:~$ snapcraft release google-cloud-cli 17 beta Snap cannot be published due to inconsistent state.

6

I can confirm that the snap can be published now. The only issue now is that the snap “google-cloud-cli” has not been granted the same aliases that “google-cloud-sdk” has. We def only want to grant “google-cloud-cli” the aliases that “google-cloud-sdk” has if it is possible for them to ALSO exist on “google-cloud-sdk”.

7

Hey @willfaris,

We can of course grant the google-cloud-cli the same aliases as google-cloud-sdk if you request so, but the issue would be conflicts if both snaps are running at the same time (please see Commands and aliases for further details).

Please let me know if you want to proceed with the aliases request! Thanks!

8

Hello @emitorino,

It is not ideal but unless there is another solution I don’t think we have another choice since we are going through this rename. We don’t expect users to install both google-cloud-sdk and google-cloud-cli at the same time, and there is no reason to do so as they essentially provide the same software. We plan on removing the google-cloud-sdk snap package when we see usage move to the new “google-cloud-cli”

I believe the aliases that were granted to google-cloud-sdk are

anthoscli bq docker-credential-gcloud gcloud gsutil

So we formally ask for those same aliases for “google-cloud-cli” snap

9

Hey @willfaris,

I have granted the following aliases to google-cloud-cli : bq, gcloud, gsutil, anthoscli, docker-credential-gcloud and kubectl. Please note that google-cloud-sdk does not have an app kubectl but has kuberun so that would be the only difference. Could you please confirm this is correct? Thanks!

10

I think older versions of the google-cloud-sdk snap did in fact ship a bin/kuberun app but newer versions do not, we never asked Canonical to remove the alias, but I am pretty sure that we asked for kuberun alias when we were including that in google-cloud-sdk. Sorry about not asking to remove the alias when we removed the binary from the snap.

google-cloud-cli, look good except for one thing, we actually don’t want an alias for kubectl there, both snaps ship bin/kubectl but we don’t think users want to call the kubectl that the snap ships with directly, thus we never asked for an alias for google-cloud-sdk snap. Could we remove the alias for kubectl from google-cloud-cli?

11

Don’t worry at all. Do you want to remove it now? I am happy to do so if needed.

I have removed it. Apologize for adding it without your acknowledgement. Could you please check everything is correct now?

Thanks!

12

you can remove the defunct alias for kuberun. Thanks

13

everything seems to be working for google-cloud-cli!

1 Like
14

I have removed it. Thanks!