search

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle
https://cluster-api.sigs.k8s.io
Apache License 2.0
3.5k stars 1.3k forks source link

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

Closed maelvls closed 4 years ago

maelvls commented 4 years ago

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: https://github.com/kubernetes-sigs/cluster-api/issues/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

vincepri commented 4 years ago

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 commented 4 years ago

I'm 👍 for just staging, master tag only

vincepri commented 4 years ago

/milestone v0.3.x /assign @maelvls

ncdc commented 4 years ago

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 commented 4 years ago

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

ncdc commented 4 years ago

Too many negatives 😄 - what needs to change?

vincepri commented 4 years ago

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 commented 4 years ago

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

detiber commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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