Github bot created bad release 1.7.3

[ader1990]

What steps did you take and what happened?

https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.7.3 does not contain any binary / yamls.

To give more context, this situation breaks the cluster init command, as by default, the command tries to find the latest release, and at this moment, it finds the 1.7.3 release on Github, and then tries to use files that are not in the release download links (as they currently don t exist).

What did you expect to happen?

https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.7.3 to contain all binary / yamls like https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.7.2 does.

Cluster API version

None.

Kubernetes version

No response

Anything else you would like to add?

No response

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[chrischdi]

Could you please refer which clusterctl version you are using?

This seems to be this bug:

• clusterctl tries to download latest tag when no release exists. #7889

Which should have been solved in:

• 🐛 Verify that there is a release for the tag #10220

which be part of clusterctl versions >= v1.7.0 :-)

A similar fix was done for the e2e test module which is part of v1.7.3.

[vishalanarase]

Just followed the release process document, i will discuss this issue in the release call

[chrischdi]

Note: v1.7.3 is not yet released, which is why binaries/yamls are not visible yet. The github action did actually work, but the release is not published yet.

[sbueringer]

Yeah, everything is fine with the release. It's just in progress. The point here is just about if clusterctl works correctly or not.

[ader1990]

Just followed the release process document, i will discuss this issue in the release call

Thank you. Saw that the previous releases were done from a PR and the binary/yamls appeared in the release page after 15-20 minutes (almost 5h passed already now). I can close this issue if the release has not finished being released.

The term release can be confusing as the PR merged was actually creating a commit to be tagged and not a release. And saw that no actions were in progress, that s why I created the issue.

[ader1990]

Yeah, everything is fine with the release. It's just in progress. The point here is just about if clusterctl works correctly or not.

I can close the issue if the "release" was properly created by the Github bot process and there are no pending issues on why it takes so much time.

[sbueringer]

The reason is that cutting a release is much more than what the GitHub bot is doing. Please see: https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/main/docs/release/release-tasks.md

What Christian is talking about is that clusterctl >= v1.7.0 should be able to handle this. It should just use v1.7.2.

Are you using clusterctl >= v1.7.0?

[sbueringer]

So to clarify:

• it is expected that the release is not entirely done yet
• it is not expected that clusterctl init fails (if you use clusterctl >= v1.7.0)

[sbueringer]

This is what clusterctl v1.7.0 is doing on my env

/clusterctl init --infrastructure docker
Fetching providers
Installing cert-manager Version="v1.14.4"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v1.7.2" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v1.7.2" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v1.7.2" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-docker" Version="v1.7.2" TargetNamespace="capd-system"

Your management cluster has been initialized successfully!

You can now create your first workload cluster by running the following:

  clusterctl generate cluster [name] --kubernetes-version [version] | kubectl apply -f -


New clusterctl version available: v1.7.0 -> v1.7.3
sigs.k8s.io/cluster-api

[ader1990]

So to clarify:

• it is expected that the release is not entirely done yet
• it is not expected that clusterctl init fails (if you use clusterctl >= v1.7.0)

Thank you for the explanation @sbueringer. It took me a while to test things out, as I had to wait around 4 minutes for clusterctl to run (as it had to timeout or maybe retry the http requests):

• it is expected that the release is not entirely done yet -> I understand now. A suggestion maybe: have a release issue as other projects have to track the actual release and close it once the FULL release gets produced (all steps are followed)? I would not have opened this issue if there wasn't a PR with the name containing the term release. I took a look first at the previous releases and saw that the yamls/binaries were usually added to the release page after around 15 minutes.
• it is not expected that clusterctl init fails (if you use clusterctl >= v1.7.0) -> I was using clusterctl version 1.3 and updated now to 1.7.2. After that, I ran with the new clusterctl version:

time clusterctl init --infrastructure tinkerbell -v 5
Using configuration File="~/.cluster-api/clusterctl.yaml"
Fetching providers
error using httpGet to get file from GitHub releases, falling back to github client: error getting file, status code: 404 owner="kubernetes-sigs" repository="cluster-api" version="v1.7.3" path="metadata.yaml"
Potential override file SearchFile="~/.config/cluster-api/overrides/cluster-api/v1.7.2/core-components.yaml" Provider="cluster-api" Version="v1.7.2"
Fetching File="core-components.yaml" Provider="cluster-api" Type="CoreProvider" Version="v1.7.2"
error using httpGet to get file from GitHub releases, falling back to github client: error getting file, status code: 404 owner="kubernetes-sigs" repository="cluster-api" version="v1.7.3" path="metadata.yaml"
Potential override file SearchFile="~/.config/cluster-api/overrides/bootstrap-kubeadm/v1.7.2/bootstrap-components.yaml" Provider="bootstrap-kubeadm" Version="v1.7.2"
Fetching File="bootstrap-components.yaml" Provider="kubeadm" Type="BootstrapProvider" Version="v1.7.2"
error using httpGet to get file from GitHub releases, falling back to github client: error getting file, status code: 404 owner="kubernetes-sigs" repository="cluster-api" version="v1.7.3" path="metadata.yaml"
Potential override file SearchFile="~/.config/cluster-api/overrides/control-plane-kubeadm/v1.7.2/control-plane-components.yaml" Provider="control-plane-kubeadm" Version="v1.7.2"
Fetching File="control-plane-components.yaml" Provider="kubeadm" Type="ControlPlaneProvider" Version="v1.7.2"
Potential override file SearchFile="~/.config/cluster-api/overrides/infrastructure-tinkerbell/v0.4.0/infrastructure-components.yaml" Provider="infrastructure-tinkerbell" Version="v0.4.0"
Fetching File="infrastructure-components.yaml" Provider="tinkerbell" Type="InfrastructureProvider" Version="v0.4.0"

...
real    3m5.752s
user    0m2.069s
sys     0m0.342s

clusterctl version
clusterctl version: &version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.2", GitCommit:"a5898a2f63b8d3c556f192b76794b5b67900be5d", GitTreeState:"clean", BuildDate:"2024-05-14T16:09:34Z", GoVersion:"go1.21.9", Compiler:"gc", Platform:"linux/arm64"}

New clusterctl version available: v1.7.2 -> v1.7.3
sigs.k8s.io/cluster-api

[ader1990]

As I was using an old version of clusterctl, my issue is invalid. Still, would be great to have an issue or discussion/project tracking the release that gets closed when everything has been completed.

[sbueringer]

Thx for the feedback!

I'll re-open. I think we should look into the 4 min delay. I saw something similar on my machine. Just wasn't sure if it's specific to my env

/reopen

(I'll leave the point about having an issue etc. up to the release team)

[k8s-ci-robot]

@sbueringer: Reopened this issue.

In response to this:

Thx for the feedback!

I'll re-open. I think we should look into the 4 min delay. I saw something similar on my machine. Just wasn't sure if it's specific to my env

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sbueringer]

(cc/fyi @chrischdi regarding the delay)

[chrischdi]

Just checked again: The following PR:

• 🌱 test: check for metadata.yaml when resolving releases to not try to use unreleased versions + avoid retry on 404 (also in clusterctl) #10618

has an additional fix which improves on the timeout.

This was backported to v1.7 and gets released in clusterctl v1.7.3 .

[sbueringer]

Tested this with the partially-released CAPV v1.10.1 and with clusterctl v1.7.3 it was falling back in a reasonable timeframe to v1.10.0.

I'll close this issue then
/close

My take on release process changes. We already have a lot of work, especially for the release team (see: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md). I think it's not worth the effort to add additional work by having to open an issue for every release that we do.

I'll prefer having to answer/close a few issues if folks are using old clusterctl versions & if the release process takes a bit longer. That's a lot less work in the long run.

[k8s-ci-robot]

@sbueringer: Closing this issue.

In response to this:

Tested this with the partially-released CAPV v1.10.1 and with clusterctl v1.7.3 it was falling back in a reasonable timeframe to v1.10.0.

I'll close this issue then
/close

My take on release process changes. We already have a lot of work, especially for the release team (see: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md). I think it's not worth the effort to add additional work by having to open an issue for every release that we do.

I'll prefer having to answer/close a few issues if folks are using old clusterctl versions & if the release process takes a bit longer. That's a lot less work in the long run.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ader1990]

Tested this with the partially-released CAPV v1.10.1 and with clusterctl v1.7.3 it was falling back in a reasonable timeframe to v1.10.0.

I'll close this issue then /close

My take on release process changes. We already have a lot of work, especially for the release team (see: https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-tasks.md). I think it's not worth the effort to add additional work by having to open an issue for every release that we do.

I'll prefer having to answer/close a few issues if folks are using old clusterctl versions & if the release process takes a bit longer. That's a lot less work in the long run.

Thank you for the info and help, much appreciated!