Update dependencies #3639
Update dependencies #3639
Conversation
kingdonb
force-pushed
the
upgrade-dependencies
branch
from
7d22d07
to
ea7db40
Compare
|
I guess this trips over some dependencies upgrading to Go YAML v3 @ v3.0.0 which has a CVE I tried upgrading ourselves to the latest YAML.v3 but because the tests immediately failed, The dependencies that upgraded Go YAML to v3 had pinned a specific version which has CVEs against it, I upgraded those deps, but also replaced their YAML v3 versions with the latest (known safe) version 3.0.1, and in a local build found that it did not invoke the untrustworthy dependency. 👍 |
|
This passes 👍 After this merges I'll cut the next release. (The CHANGELOG is in 86cfd4a now.) |
kingdonb
force-pushed
the
upgrade-dependencies
branch
from
618dc66
to
0d81968
Compare
|
I lined up all the release PRs, so when this one gets approved I should be able to knock them all down and release in about an hour 👍 |
|
WDYT @pjbgf ? Do you think there are any other version pins we should advance? K8s 1.25.x is out now, which means K8s 1.21.x series is finally out of support (EOL). We have been pinning this series (1.21.x) and planned on upgrading past the breaking issues from those dependencies again around this milestone, about when there should be no more people still running on K8s 1.16.x, I have lost track of the details about supporting at the edges. I thought we had an issue pinned where we discussed how we plan to handle this, but I'm not seeing it. Will search for it again later. I think that we might still want to consider publishing that type of upgrade but it should come later, if at all, in a next MINOR v1.26.0. I am not aware of any issues with K8s 1.24 or 1.25 preventing Flux v1 users from advancing on that upgrade path. We can release these upgrades as a patch now, and plan those upgrades for next release. That's what I'd propose. That being said, I have not yet tested against K8s 1.25.0, I do not have a test matrix of different Kubernetes release versions at my disposal for testing against, as my maintainer duties are not resourced in that way here. I have plenty of ARM64 resources but Flux v1 only runs on AMD64 officially. I will try to make a 1.25.0 cluster and root out any issues with the e2e. We are not expecting to make major changes in the Flux v1 codebase again. I think there are some deprecation warnings that may impact users in the strange place of being on the very latest Kubernetes release but also pinned to Flux legacy v1, there are probably no users in this position. (It seems much more likely that Flux v1 runs on systems which are never upgraded.) I have not checked the deprecation schedule for this release out yet, but I think we are due for another breaking change requiring upgrade soon from upstream Kubernetes. Maybe someone else is more on top of this information than I am today. |
|
@kingdonb I agree with the approach, let's take the Kubernetes update as a separate thread/release. In the coming days I plan to take a look around Flux 1 and the impact of 1.21.x being EOL and 1.22.x becoming EOL soon. |
|
I think #3564 is the issue that I was looking for. If there are any more deprecation warnings to address, let's open an issue. Reopened: |
* no need to upgrade Flux to yaml.v3 The dependencies which use yaml.v3 pinned a specific unreleased version that was not secure, so we should replace it. (There's no CVE reported against v2.4.0, the version that Flux itself uses internally.) Co-authored-by: Paulo Gomes <paulo.gomes@weave.works> Signed-off-by: Kingdon Barrett <kingdon@weave.works>
kingdonb
force-pushed
the
upgrade-dependencies
branch
from
c1b7492
to
b7cc565
Compare
Working on upgrades for the next patch release