"addons configure registry-creds" always uses gcr.io for GCR

[atombender]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT
Minikube version (use minikube version): 0.20

Environment:

• OS (e.g. from /etc/os-release): N/A
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): N/A
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): N/A
• Install tools: N/A
• Others: N/A

What happened:
If you run minikube addons configure registry-creds, and you ask it to enable the GCR credentials, it will create Docker credentials for https://gcr.io/. As a consequence, the instructions didn't work for me, because we use https://us.gcr.io/ for all our Docker images.

The configuration can be fixed manually by doing kubectl edit secret gcr-secret in each namespace, replacing the registry URL (plus mucking around with base64), but that's very inconvenient.

What you expected to happen:
I expected it to enable the credentials for all known GCR URLs. Or at least me ask which registry/registries to enable.

How to reproduce it (as minimally and precisely as possible):
See above.

Anything else do we need to know:
N/A

[r2d4]

Makes sense. We could either supply the user with a list of all known GCR URLs, or provide the default but allow a custom url.

[atombender]

The gcloud toolchain (specifically, docker-credential-gcr) adds all of them to docker.json, and that's probably the way to go. E.g. my ~/.docker/config.json has:

  "credHelpers" : {
    "beta.gcr.io" : "gcr",
    "us.gcr.io" : "gcr",
    "gcr.kubernetes.io" : "gcr",
    "bucket.gcr.io" : "gcr",
    "gcr.io" : "gcr",
    "asia.gcr.io" : "gcr",
    "b.gcr.io" : "gcr",
    "eu.gcr.io" : "gcr",
    "appengine.gcr.io" : "gcr"
  }

[aaron-prindle]

This should be fixed with #1436. This flag recently added to the registry-creds addon and now our registry configuration supports this. Closing.

[atombender]

@aaron-prindle I'd strongly prefer it to add all the known GCR URLs.

The approach used by the PR means there'll be manual setup and documentation needed on the team end in my company, and from what I can tell it cannot be automated (it always shows an interactive prompt); it also means that it won't work if a team uses multiple GCR URLs, since it only supports a single URL, from what I can tell. It also will fail if a team uses a specific GCR URL and then migrates to another.

A good reason to populate all the GCR URLs is that from a GCR perspective, they're all "identical". They're just regional GCS buckets. (I don't even know Google, with all their multiregional network magic, does it this way, since they have the ability to automatically route a client to the nearest server, and also have a CDN. But right now there are multiple URLs, so we have to work around it.)

In my company we prefer to automate as much as possible. We are building a tool that will set up Minikube and run minikube addons configure registry-creds for the user. It can't be interactive. If we know the prompts beforehand, we could probably pipe through stdin, but that would obviously be super brittle.

[atombender]

I can look into doing a PR for what I described + adding command line flags for automation purposes.

…

On Jul 24, 2017, at 19:38, Aaron Prindle ***@***.***> wrote: Reopened #1732. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[aaron-prindle]

@atombender it definitely makes the most sense to populate all of the GCR URLs. The GCR URL is set as an endpoint for the secret that the registry-creds addon generates. The place that is done is here:
https://github.com/upmc-enterprises/registry-creds/blob/master/main.go#L202

It seems like making this a list of all the available options, like what you posted above, would solve the issue. Thanks for looking into this!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close