-
Notifications
You must be signed in to change notification settings - Fork 219
Upgrade to CAPI v1.11 #1509
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
Upgrade to CAPI v1.11 #1509
Conversation
✅ Deploy Preview for kubernetes-sigs-cluster-api-gcp ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
We discussed this in CAPI office hours this week. It's a big process https://cluster-api.sigs.k8s.io/developer/providers/migrations/v1.10-to-v1.11, but we should be able to start gradually by just bumping the dependency and sticking with v1beta1. A "real" integration will start using v1beta2 upstream, and then bump our own types to v1beta2 (the big change is status.conditions, I believe) Have we documented our branching strategy anywhere? I would imagine that the release-1.10 branch maps to CAPI 1.10, and we cherry-pick fixes for 1.10 to that branch. If we don't have a doc, I'm happy to send a PR |
050fd9a
to
ed6b043
Compare
4bb63a7
to
459eab7
Compare
Thanks @justinsb. Looks like this bump also requires a number of changes to remove deprecated functions. Let me know if I can help collaborating on this PR. |
there are a few issues
|
Following up from my thoughts here: #1514 (comment)
We could rename this PR to Here are some places where we need bumping:
|
65acc9c
to
ac0797a
Compare
Thanks @damdo - I think I got them all! Except: I don't think those are per go version. They could be bumped, but hopefully we don't have to because it looks like they have a different update policy, which will make auto-bumping hard.
I hope we don't have to do this until we actually release, because our contract is still v1beta1 but we are expected to update to v1beta2 as part of moving to CAPI 1.11. There's a note there saying not to do this until we actually release, and I think we want to do more before releasing. This PR is just getting us onto the CAPI 1.11.x libraries. |
Thank you @salasberryfin - any collaboration would be wonderful. I propose keeping this PR fairly minimal - just bumping to CAPG 1.11.0 but not yet adopting v1beta2 APIs. I think the deprecated functions are ones that I introduced and marked deprecated! They are needed (temporarily) while we continue to use v1beta1 APIs internally. Moving everything to v1beta2 would (I think) be a more invasive code change (I'll happily review though if you want to add that - I think you need to bump CAPI to 1.11 first which is what I'm trying to do in this PR). The CAPI v1beta1 packages are marked deprecated also, and yes - we need to move to v1beta2. |
a39a325
to
b1d9c05
Compare
go.mod
Outdated
module sigs.k8s.io/cluster-api-provider-gcp | ||
|
||
go 1.23.7 | ||
go 1.24.6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer we did bump the minimum required minor version, but not patch version.
This has caused a LOT of pain downstream, and not only in our product. (i.e. just doing go 1.24.0
instead of 1.24.z
)
Core CAPI also has my same take for CAPI v1.11, as you can see here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be great to figure this out, that's why I sent #1515 because I'm confused! Do you have any links to the problems caused? I remember a problem a few years ago in k/k where we found a regression in go on arm x86 32 bit (IIRC).
That said, I do think we should be using toolchain directives
go 1.24
toolchain go1.24.6
On other projects users insist that we run the latest golang because otherwise their vulnerability scanners flag it. I can see a case for not running 1.25.0 while 1.24.x is supported, but if we're using 1.24.x I think we want to be using 1.24.6 to avoid getting flagged by every security team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am happy with using the go toolchain xx
directive bumped to the latest patch version of the version specified in the go xx
directive (staying to a .0 patch release for the whole time).
Do you have any links to the problems caused?
The problem with bumping the patch version of the go xx
directive is that it forces all importers of this module to use that same or a higher patch version to build it.
Which it is fine in most of the projects if they can keep up with the go patch release cadence, but it is hard in environments/projects where the go compiler is bumped once every minor go release, or at least where the bumping cadence is not that high for reasons.
Downstream we explicitly disable toolchain for achieving reproducible/consistent builds, so we can't rely on the go compiler "dynamic version upgrade" feature (or whatever it is called 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I like that approach!
We rely on some helper functions that have moved to v1beta2. This should work because we should be able to use core CAPI v1beta2, before fully upgrading CAPG to v1beta2 semantics.
c30275d
to
86fd846
Compare
86fd846
to
45b9880
Compare
/test pull-cluster-api-provider-gcp-test pull-cluster-api-provider-gcp-apidiff |
@justinsb: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
So I rebased and we are passing e2e with kube 1.33 🎉 The apidiff is "real" - these are API changes, though I think these are mostly just the package-path changing. I believe that all the external facing changes are no-op package-path changes.... |
@cpanato do we need to run any other e2e or conformance on this before merging? |
/test ? |
@damdo: The following commands are available to trigger required jobs:
The following commands are available to trigger optional jobs:
Use
In response to this:
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. |
It looks like last time we ran these: #1459 (comment) So let's run them again. /test pull-cluster-api-provider-gcp-conformance |
we should run the pull-cluster-api-provider-gcp-conformance-ci-artifacts but we need to fix that test :/ so just extra conformance is ok for now |
Would you be able to create an issue for that? So we don't forget :) |
that will be awesome |
Created an issue for that here: #1529 |
pull-cluster-api-provider-gcp-conformance Let's get this merged /unhold |
We upgrade CAPI libraries to 1.11.0, however we continue to use v1beta1 semantics and versions (except in our tests).
This should be an internal version bump, not user facing.