-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Push capd-controller-manager images on new cluster-api tags #3101
Comments
Hi @maelvls, thanks for filing this issue. During v1alpha3 planning and while working on getting the v0.3.0 out, we've decided to not publish any CAPD images going forward. As you mentioned, the reason for this was to make sure that our published artifacts are in line with this project's charter and goals. CAPD has always been primarily a development and testing product, and shouldn't be used to run clusters in production; for these reasons up until now we avoided publishing CAPD artifacts, especially because CAPD comes with no support and no guarantees. We can potentially, as you suggested, look into using the staging repository. |
I'm 👍 for just staging, |
/milestone v0.3.x |
FYI, there are two parts to this, for getting started:
Also note, all of CAPD is rooted in test/infrastructure/docker, and it has its own separate HTH! |
+1, we only need to make sure we don't build the release-staging images and tags when it's not master |
Too many negatives 😄 - what needs to change? |
The job kicks in when these are met: https://github.com/kubernetes/test-infra/blob/e50e8f54a551e3ab05f8d04f0ed1f11c53ce5583/config/jobs/image-pushing/k8s-staging-cluster-api.yaml#L10-L14 Then tags and branch names are passed to the Makefile in https://github.com/kubernetes-sigs/cluster-api/blob/master/cloudbuild.yaml#L10-L12 If we push a tag, let's say |
Getting images with tag release is not bad.... it can help for simplifying usage of CAPD with the quickstart/clusterctl |
I don't necessarily see an issue if we are creating the tag in the staging bucket but are not promoting it as part of the release process. I would also expect any tagged images for CAPD to be purged from staging after they have aged out, so we should avoid any references to those tags in any documentation or automation. |
I don't have any objections to semver tags going to staging. We aren't pushing to prod. We're very clear about CAPD's purpose. |
I'll be working on this (if it's OK) next week. I was waiting for a tiny approval from my employer!
Looks like we have reached a consensus: let's have the CI push images for each semver git tag + a master tag too? docker pull gcr.io/k8s-staging-capi-docker/capd-manager:master
docker pull gcr.io/k8s-staging-capi-docker/capd-manager:v0.3.6 Update June 7, 2020: I now have the approval! I'll start working on this on June 10, 2020 |
Context:
During the ClusterAPI Weekly meeting on 6 May 2020, I wondered why no
capd-controller-manager:v0.3.0
image was pushed to the gcr.io/staging-capi-docker registry (see the discussion).@dlipovetsky told me that the "dev experience" with CAPD had changed as detailed in clusterctl/developers.html and that the image isn’t being published right now.
User Story
As a developer or operator, I would like to be able to very quickly get started using CAPI + CAPD. Right now, a newcomer to the project has to go through quite a lot of steps (as detailed in clusterctl/developers.html) including a
docker build
that end up taking quite a lot of time to build (like any other Kubernetes controller) and thekind load
also takes a few seconds.This user story only addresses the
docker build
+kind load
. The developer or operator willing to take a look at ClusterAPI using CAPD will still have to go through the remaining steps in clusterctl/developers.html.Detailed Description
I wish we could have a new OCI image
capd-controller-manager
pushed to gcr.io/staging-capi-docker whenever a tag is created in the cluster-api project. My guess is that it could be done as part of CI?Related: #2738
I'd be happy to help! (in what direction should I look at?)
Update: see the 27 May 2020 weekly meeting recording (at 17:18) where this issue is discussed
The text was updated successfully, but these errors were encountered: