Skip to content
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

Closed
maelvls opened this issue May 27, 2020 · 11 comments · Fixed by #3177
Closed

Push capd-controller-manager images on new cluster-api tags #3101

maelvls opened this issue May 27, 2020 · 11 comments · Fixed by #3177
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@maelvls
Copy link
Contributor

maelvls commented May 27, 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 the kind 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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label May 27, 2020
@vincepri
Copy link
Member

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.

@ncdc
Copy link
Contributor

ncdc commented May 27, 2020

I'm 👍 for just staging, master tag only

@vincepri
Copy link
Member

/milestone v0.3.x
/assign @maelvls

@k8s-ci-robot k8s-ci-robot added this to the v0.3.x milestone May 27, 2020
@ncdc
Copy link
Contributor

ncdc commented May 27, 2020

FYI, there are two parts to this, for getting started:

  1. cloudbuild.yaml in this repo, which currently calls make release-staging
  2. The release-staging target in our Makefile

Also note, all of CAPD is rooted in test/infrastructure/docker, and it has its own separate Makefile. I guess you'd make want to have make release-staging invoke the same target in CAPD's Makefile (which doesn't currently exist)?

HTH!

@vincepri
Copy link
Member

+1, we only need to make sure we don't build the release-staging images and tags when it's not master

@ncdc
Copy link
Contributor

ncdc commented May 27, 2020

Too many negatives 😄 - what needs to change?

@vincepri
Copy link
Member

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 v0.3.7 and add a make release-staging in CAPD, the CAPD@v0.3.7 image will also be pushed — I'm not sure if we can get easily around it though

@fabriziopandini
Copy link
Member

Getting images with tag release is not bad.... it can help for simplifying usage of CAPD with the quickstart/clusterctl

@detiber
Copy link
Member

detiber commented May 28, 2020

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.

@ncdc
Copy link
Contributor

ncdc commented May 28, 2020

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.

@maelvls
Copy link
Contributor Author

maelvls commented Jun 5, 2020

I'll be working on this (if it's OK) next week. I was waiting for a tiny approval from my employer!

Semver tags going to staging

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants