att-comdev / openstack-helm

PROJECT HAS MOVED TO OPENSTACK
https://github.com/openstack/openstack-helm
69 stars 41 forks source link

doc: minkube.md: maridb chart failing cuz pull of image was failing cuz no quay.io creds #315

Closed tobybot11 closed 7 years ago

tobybot11 commented 7 years ago

Is this a bug report or feature request? (choose one): bug/missing aspect in docs/development/minikube.md

Kubernetes Version (output of kubectl version --short): Client Version: v1.5.5 Server Version: v1.5.3

Helm Client and Tiller Versions (output of helm version --short): Client: v2.2.3+g1402a4d Server: v2.2.3+g1402a4d

Development or Deployment Environment?: development / Mac OSX Sierra / VirtualBox setup

Release Tag or Master: master

Expected Behavior: mariadb job succeeds and mariadb chart DEPLOYED and pod Running

What Actually Happened: pull of quay.io image failed within the instantiation process

How to Reproduce the Issue (as minimally as possible): follow docs/development/minikube.md to the letter up to the helm install local/mariadb ..

Any Additional Comments: was able to fix it by doing the following...

minikube ssh docker login <- enter creds docker login quay.io <- enter creds

is 'docker login' the right way to solve this problem? how'd you deal with this previously?

if this is an ok solution for now, i'd be glad to add a section to minikube.md

v1k0d3n commented 7 years ago

hey @tobybot11! :)

that's really strange behavior, as there should be no login required in fact to pull these public images. we had an issue creep in for about 2 hours or so, for our rabbitmq image that we pulled from mariantis' repo, but that is resolved now (so try repulling?).

that said; which image is this triggering on exactly? our images are pulling from a couple of sources currently, so it would be helpful to know if this is on mariadb (which is coming from quay.io/stackanetes) or on an image like our kube-controller-manager which we can work with on our side. curious, when you issue just docker login, does that default to "https://hub.docker.com", or are you using a custom registry (or even different container runtime)?

tobybot11 commented 7 years ago

Given the sequence of instructions, I didn't test this issue beyond mariadb and it's image from quay.io/stackanetes referred to as quay.io/stackanetes/stackanetes-mariadb:newton). Once I use docker login quay.io in minikube for mariadb, I didn't have this problem with the rest. I'm using the default docker & quay registries and docker container runtime.

Issuing just docker login interacts with https://index.docker.io/v1/ but instructs you to go to "https://hub.docker.com" to set up new creds if you don't have a set. docker pull on this mariadb image wouldn't work (on osx or in minikube ssh) unless I logged into quay.io using docker login quay.io.

I was guessing that there was a way in k8s with the registry-creds addon to handle this but quay.io doesn't show up there yet and this docker login way was simpler, at least for me.

I'll poke around and try some variations and see if I can figure out what's going on.

tobybot11 commented 7 years ago

At this point, when I do docker logout of the quay.io registry in either (osx or in minikube ssh) I'm able to docker pull of the mariadb image from quay.io. Even after removing all remnants of my creds from .docker/config.json or the osxkeychain I am still able to pull from quay.io. Also, I blew away minikube and started from scratch .. and didn't have the issue .. odd.

tobybot11 commented 7 years ago

I'll close this issue until I can reproduce it again.