Bump kubernetes to 1.28.4 #556
Conversation
|
This would be useful for us, I was also about to look into upgrading! Is there any reason you chose not to upgrade to v1.28.4 of k8s.io/kubernetes and go 1.21? |
farodin91
force-pushed
the
upgrade-k8s-1.27.8
branch
from
7dcf41c
to
3580f83
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #556 +/- ##
==========================================
+ Coverage 54.70% 54.78% +0.08%
==========================================
Files 41 41
Lines 4645 4636 -9
==========================================
- Hits 2541 2540 -1
+ Misses 1908 1899 -9
- Partials 196 197 +1 ☔ View full report in Codecov by Sentry. |
farodin91
force-pushed
the
upgrade-k8s-1.27.8
branch
from
3580f83
to
5e9016c
Compare
Signed-off-by: Jan Jansen <jan.jansen@gdata.de>
farodin91
force-pushed
the
upgrade-k8s-1.27.8
branch
from
5e9016c
to
dc1d73d
Compare
Updated. |
|
Kudos, SonarCloud Quality Gate passed!
|
There was a problem hiding this comment.
This looks good to me, would be great to get a maintainer to approve and merge this if they're happy 👍 Perhaps @crenshaw-dev ?
|
Thanks so much for picking this up, @majolo! I'm going to wait until we cut Argo CD 2.10 before tackling this, since we have some other high-priority changes we want to get in. |
|
@crenshaw-dev Sounds great. Do you have a time range? We are blocked by this as we can't upgrade to a newer version of kubebuilder. |
|
@farodin91 the earliest will be > next Monday. I'll go ahead and give a quick first-pass review so we can knock out any basic concerns. |
| o.DryRunVerifier = resource.NewQueryParamVerifier(dynamicClient, k.fact.OpenAPIGetter(), resource.QueryParamFieldValidation) | ||
| o.FieldValidationVerifier = resource.NewQueryParamVerifier(dynamicClient, k.fact.OpenAPIGetter(), resource.QueryParamFieldValidation) |
There was a problem hiding this comment.
Do you know why these fields were removed from the upstream struct? Do we need to be switching to some other mechanism of providing these arguments?
There was a problem hiding this comment.
I made a similar change in our fork - without much digging, the following seemed to suggest just removing these is the correct approach?
https://github.com/kubernetes/kubernetes/pull/114294/files
https://github.com/kubernetes/kubernetes/pull/114413/files
There was a problem hiding this comment.
Yep, that's correct. I later learned that both of those verifiers are designed for use with very old Kubernetes versions. Safe to remove now.
|
Thanks @crenshaw-dev could this not be cut first and then included in argo-cd 2.10? It's actually argo-cd that we use (which in turn imports this library) which is causing us the issues. |
|
@majolo theoretically, yes. But practically speaking, no. Before this can be merged, a similar PR will need to be made on the argo-cd repo and reviewed/tested. With those two PRs together, I just don't think I'll have time to review/merge before we cut RC1 Monday. |
|
Any chance of getting this one bumped together with this one: |
|
@crenshaw-dev any update on this one? Thanks! |
|
Hello 👋 , our team owns an internal tool that interacts with both argo cd and k8s. As part of the recent upgrade a different team is making to all our k8s clusters to 1.27+ I'm trying to upgrade our tool's internal libraries. When doing so the gitops-engine dependency, even if I bump it to the sha in main/master is not able to compile and is blocking the upgrade. This PR's code works perfectly with no compile errors (I checked out the forked code locally). I would love to know a rough timeline of when this could get merged? Alternatively if you're willing to push a tag or something so my go.mod file could depend on it. This would be greatly appreciated 🙏 |
|
@asaf-erlich we can start working on getting this merged now. Would you mind rebasing? Could you also open a PR on argo-cd pointing to the latest commit of your fork/branch? Here's an example of what that change looks like. argoproj/argo-cd@90ce09a That PR will let us run Argo CD's tests and catch any issues which weren't revealed by the gitops-engine tests. |
|
Looks like we could actually go to 1.28.6 or to 1.29.1 at this point. |
|
@crenshaw-dev I'm not the original author of the PR, @farodin91 is. I'm happy to attempt those things it will help but would need to create a new PR to do so. I'd like to give @farodin91 at least a day or two to respond and if they cannot do it I can try to do so. |
Go for it. I'm on vacation and next in this week or next week. |
I'll give it a try |
|
Here is the rebased PR: #565 |
Looking at the PR and at https://stackoverflow.com/questions/72312460/how-to-replace-a-go-module-with-a-major-version-to-a-fork-master I will need to edit my own fork's go.mod file, at least temporarily, to declare a different name. Edit: maybe I'll just push that rename to a different branch and create a tag instead to avoid messing with my PR |
|
My first attempt at the test PR (left it in draft state): argoproj/argo-cd#16967 |
|
Hi @asaf-erlich and @crenshaw-dev, would you by any chance be able to drive this effort to completion? I'm in a similar situation as the one described by @asaf-erlich and would greatly benefit from this upgrade. I would even advocate for going a bit further and bumping to 1.29.x, if possible. |
|
Unfortunately I don't have the time to make the required changes. |
|
Focusing effort on this PR: #566 |
|
Superceded by #566. |
No description provided.