🐛 Update CAPI version to v1beta1 in kustomization in test-framework

[k8s-infra-cherrypick-robot]

This is an automated cherry-pick of #5526

/assign sbueringer

[sbueringer]

/retitle 🐛 Update CAPI version to v1beta1 in kustomization in test-framework

[sbueringer]

Hey folks,
I think we should cherry-pick that fix. Without this change providers which are depending on GenerateCIArtifactsInjectedTemplateForDebian (CAPO) won't be able to use the functionality with the release-1.0 branch and are forced to upgrade to v1.1.x.

/cc @fabriziopandini

[fabriziopandini]

@sbueringer is there a problem to move to v1.1?
I'm also ok in making an exception, but soon or later we have to draw a line...

[jichenjc]

if 1.1 technically works ,I think CAPO should give a try instead ask for exception
will work with @mdbooth to give a try on
kubernetes-sigs/cluster-api-provider-openstack#1136

[sbueringer]

@sbueringer is there a problem to move to v1.1? I'm also ok in making an exception, but soon or later we have to draw a line...

Agree. In general there shouldn't be a problem with moving to v1.1. Although CAPO is currently in a state where CI is broken and they have to pick up the cert-manager fix, this fix and it would be probably easier for them if they don't also have to migrate to v1.1 to get CI working again.

Also if I understand correctly they would be forced to switch from CAPI v1.0.x to v1.1.x in the middle of their v0.5.x release series (which is something that we in core CAPI would consider a breaking change as it also changes the minor version of CR / client-go / ...). (Although I have to say, I have no idea why that issue surfaced just now, but I don't want to invest the time/effort to figure that out)

My point of view is that it was an oversight at the time that we only fixed this on main and didn't cherry-pick it back into release-1.0. This fix was originally made ~ 3 weeks after the v1.0.0 release. CAPA just switched to the main branch at that time, so they didn't need it in release-1.0.

[mdbooth]

@sbueringer is there a problem to move to v1.1? I'm also ok in making an exception, but soon or later we have to draw a line...

Agree. In general there shouldn't be a problem with moving to v1.1. Although CAPO is currently in a state where CI is broken and they have to pick up the cert-manager fix, this fix and it would be probably easier for them if they don't also have to migrate to v1.1 to get CI working again.

Also if I understand correctly they would be forced to switch from CAPI v1.0.x to v1.1.x in the middle of their v0.5.x release series (which is something that we in core CAPI would consider a breaking change as it also changes the minor version of CR / client-go / ...). (Although I have to say, I have no idea why that issue surfaced just now, but I don't want to invest the time/effort to figure that out)

This is correct. Our CI seems to have broken on 2nd Feb and the primary focus right now is to fix it. We are currently trying to tag a new bugfix release on the 0.5 branch and we would strongly prefer not to upgrade our CAPI dep on that branch. We also need to fix it on main. I'm fine with upgrading the dep on main, and it sounds like this is something we need to do soon anyway, but I'll also avoid that today if it complicates getting CI working again.

[jichenjc]

but I'll also avoid that today if it complicates getting CI working again.

ok, I think we are talking about 0.5 branch and main branch
0.5 branch we want this to be merge then create a new tag (1.0.5?)
and main branch we upgrade to 1.1.0 ? @mdbooth

[sbueringer]

but I'll also avoid that today if it complicates getting CI working again.

ok, I think we are talking about 0.5 branch and main branch 0.5 branch we want this to be merge then create a new tag (1.0.5?) and main branch we upgrade to 1.1.0 ? @mdbooth

We won't create a core CAPI release after merging this PR, but you can pickup a commit from the CAPI release-1.0 branch for your cluster-api/test dependency

[mdbooth]

@sbueringer FYI we discussed the 0.5 branch in our office hours meeting this morning. There was only 1 remaining patch under consideration for inclusion and the user requesting it said not to bother, so we can live without the backport after all. I'll update our patch on main to bump to the 1.1 release branch instead.

[sbueringer]

@sbueringer FYI we discussed the 0.5 branch in our office hours meeting this morning. There was only 1 remaining patch under consideration for inclusion and the user requesting it said not to bother, so we can live without the backport after all. I'll update our patch on main to bump to the 1.1 release branch instead.

Related short thread in Slack: https://kubernetes.slack.com/archives/C8TSNPY4T/p1644401812439519
(just to provide the full context on this PR)

[fabriziopandini]

/lgtm
/approve

With the PR merged we can unblock CAPO (they will work on a commit); we can separately discuss patch release planning

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fabriziopandini

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [fabriziopandini]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment