New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always use gcr.io/google_containers for side-loaded Docker images #49066
Conversation
x-ref #48956 |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: david-mcmahon, ixdy Associated issue: 45391 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/retest |
Automatic merge from submit-queue (batch tested with PRs 49043, 49001, 49057, 49066, 48102) |
…pstream-release-1.7 Automated cherry pick of #49066
Commit found in the "release-1.7" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
What this PR does / why we need it: #45391 changed the behavior for what registry we use in the sideloaded docker images tarfiles shipped with releases. As a result of that change, if
KUBE_DOCKER_REGISTRY
is set to anything other thangcr.io/google_containers
, clusters will fail to start on GCE (and other places where the side-loaded images are used).This PR reverts that change in behavior, which I believe was unintentional; we'll always use
gcr.io/google_containers
for the docker image tarfiles, but will tag the images with$KUBE_DOCKER_REGISTRY
if different.Also, I'm fixing a small bug in variable names that I introduced in #47939.
Note that with recent changes here and in the release repo, we don't even need to tag with
KUBE_DOCKER_REGISTRY
andKUBE_DOCKER_IMAGE_TAG
, but that's a more extensive change, and this smaller fix is more suitable for cherry-picking to 1.7.Release note:
/release-note-none
/sig release
/assign @david-mcmahon