gcp: allow for deprecating and then attaching to image family #1444
Conversation
dustymabe
changed the title
|
@dustymabe: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
dustymabe
force-pushed
the
dusty-ore-gcloud-update-image
branch
from
9667151
to
82cb008
Compare
|
OK I've tested this now and it's working well. Leaving in draft mode until #1435 is merged. |
dustymabe
force-pushed
the
dusty-ore-gcloud-update-image
branch
from
82cb008
to
0ce11a9
Compare
dustymabe
force-pushed
the
dusty-ore-gcloud-update-image
branch
from
0ce11a9
to
a7812be
Compare
|
ok I'm marking this as ready for review as it's no longer blocking on any other work. Regarding #1444 (comment) (using the same API call to also deprecate) I tried really hard to make this happen but I could not get it to work (see WIP in dustymabe@9f5cf34). I reached out to our contacts at google to see if there is an existing bug. Being that it is the alpha API it's possible. For now I suggest we go with what we have here. |
dustymabe
force-pushed
the
dusty-ore-gcloud-update-image
branch
from
a7812be
to
eb92096
Compare
This was passing through the toplevel opts.Image processing before and it was creating a URL for the image rather than just the string passed by the user. Override it here.
This is prep for some future work where we need the images.patch API call. That API call is currently only in the alpha API. Note: ran `go mod vendor` to pick up the alpha API files.
This new command will take advantage of the new Alpha compute API call to image.patch that will allow us to update the image family for an image after it has been created. The image.patch API call also allows for updating the description (which we also allow here) and the deprecation state (which we leave to the deprecate-image command).
Currently we create an image and attach it to an image family in a single API call. We'd like to attach it to an image family *after* the image has been deprecated (deprecated images won't be given to users who are trying to retrieve the latest image for an image family). However, you can't create an image AND deprecate it in the same API call so there is a split second of opportunity for a user to get the newer GCP image before we've officially released it. This change breaks it up so that we can: 1. create the image (not part of a image family) 2. deprecate the image 3. attach the image to an image family The new flow means there is no opportunity for a user to get an image that has yet to be released.
Previously we weren't checking the error from "pending". Let's do that now because we can miss actual errors from the gcloud API otherwise.
dustymabe
force-pushed
the
dusty-ore-gcloud-update-image
branch
from
eb92096
to
d0e6380
Compare
|
Ok I think I've resolved all outstanding requests and/or answered outstanding questions. Care to do a final round of review? |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arithx, bgilbert, dustymabe The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
|
ok CI passed, but prow is MIA - merging. |
Currently we create an image and attach it to an image family in a single API call. We'd like to attach it to an image family after the image has been deprecated (deprecated images won't be given to users who are trying to retrieve the latest image for an image family). However, you can't create an image AND deprecate it in the same API call so there is a split second of opportunity for a user to get the newer GCP image before we've officially released it.
This change breaks it up so that we can:
The new flow means there is no opportunity for a user to get an image that has yet to be released.
This builds on top of #1435 in anticipation of it merging first. See individual commit messages for more details.