-
Notifications
You must be signed in to change notification settings - Fork 2k
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
move default image registry to quay #246
move default image registry to quay #246
Conversation
Makefile
Outdated
@@ -35,7 +35,7 @@ container: build | |||
docker build -t ${REGISTRY}/kube-state-metrics:$(TAG) . | |||
|
|||
push: container | |||
gcloud docker -- push ${REGISTRY}/kube-state-metrics:$(TAG) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I don't use this make target, we can leave this for the google people as a help, as the image should still be published on gcr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
README.md
Outdated
@@ -27,7 +27,7 @@ Currently, `client-go` is in version `v4.0.0-beta.0`. | |||
|
|||
## Container Image | |||
|
|||
The latest container image can be found at `gcr.io/google_containers/kube-state-metrics:v0.5.0`. | |||
The latest container image can be found at `quay.io/coreos/kube-state-metrics:v1.0.1`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's enumerate both container image repositories here, but write a note, that the gcr image is only maintained on best effort as it requires external action from Google employees as no Google employee actively works on kube-state-metrics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done. PTAL.
I'm fine with doing this, but we should still try to maintain the gcr repository, as people have expressed their interest in the gcr image before. @piosz last time I opened a PR like this we closed it, as we said this process will be opened up to non google employees, what is the state on this, as we have trouble regarding this on every release? |
6f503ea
to
54e446b
Compare
@kubernetes/sig-release-feature-requests could you please address the questions above? |
... and apologies for not doing great job here, but we only have a limited capacity. I agree that lack of access to the official Docker repository for non-googlers is painful. |
/assign @piosz |
Any updates? |
In one of the previously cited PRs I see a comment "I pinged some Googlers". Who and how? Was the release team notified? What is the release process for kube-state-metrics? At a glance, I didn't see this in the README and didn't see other obvious docs in the top level dir. Our repo template suggests RELEASE.md. The general issue for solving this is: How large is the image? Also, how do users know which Kubernetes releases a given release of kube-state-metrics will work with? |
Whenever we want to release a version of kube-state-metrics, I ping @piosz and @loburm as they are active members of sig-instrumentation and kube-state-metrics is owned by sig-instrumentation. Previous attempts (that I could quickly find) around this include: We picked up development from the previous maintainer and just continued as it was handled before: cut release, notify Googler to push image. I've previously been told that opening the release process is already in progress, so I for the time being decided to wait it out as the current approach wasn't giving us, as maintainers, too much pain.
I'm not sure I understand the relevance, but my docker host is telling me
The README has a section on this, basically whatever client-go support matrix is. I'll make sure we add a release process document, once we finish this discussion 🙂 . |
@bgrant0607 One more thing. heapster has the same release image not found problem in
@brancz I don't think we have a release team.
What is a reference implementation of a normalized release process? |
@andyxning There is a dedicated @kubernetes/sig-release-members team. |
@kubernetes/sig-release-members is not the release team, it's the SIG that sources many (but not all) release team members. https://github.com/orgs/kubernetes/teams/kubernetes-release-managers/members consists of the current release team. |
@jdumars thanks for the info. Sorry for the confusion then. |
@brancz An image so small could be posted to github: https://help.github.com/articles/creating-releases/ |
@bgrant0607 Github releases can be used to ship binaries. Seems github does not support image registry protocol, i.e., |
@andyxning Bits are bits. It's true that Github doesn't support pulling images via a registry API. Anyway, this isn't part of the official Kubernetes release and doesn't seem to be used in https://github.com/kubernetes/kubernetes/tree/master/cluster/addons. Other repos (e.g., kompose) also push their release artifacts to random places. We haven't standardized that yet. So long as no tests run by prow pull this image (we've had a lot of failures caused by other registries in the past), I don't have a strong opinion right now. |
/lgtm |
Yes I would suggest that we just document both image registries and users are free to choose which they want, and we'll continue as we do today. |
@piosz @bgrant0607 Thanks for your suggestions on this.
Absolutely. we need to work together to make kube-state-metrics friendly to users. :) |
…egistry_to_quay move default image registry to quay
This PR will move kube-state-metrics image registry from
gcr.io
toquay.io
.This is mainly because there are some times(#224 comment, #88 comment) the latest image can not be pushed to gcr.io timely. Users may be delayed to use the latest kube-state-metrics for this reason. A better way was to use
quay.io
as the docker registry as @brancz should be able to push the latest image when a new kube-state-metrics is released./cc @brancz @loburm @fabxc @piosz
This change is