search

fluxcd / flux

Successor: https://github.com/fluxcd/flux2
https://fluxcd.io
Apache License 2.0
6.9k stars 1.08k forks source link

Update dependencies #3639

Closed kingdonb closed 2 years ago

kingdonb commented 2 years ago

Working on upgrades for the next patch release

kingdonb commented 2 years ago

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, ~I moved the Go YAML v3 upgrade to another PR~ (we will not upgrade to YAML v3, this is a major change):

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. 👍

kingdonb commented 2 years ago

This passes 👍

After this merges I'll cut the next release. (The CHANGELOG is in 86cfd4ae now.)

kingdonb commented 2 years ago

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 👍

kingdonb commented 2 years ago

WDYT @pjbgf ? kustomize is pinned/frozen in place at 3.8.4 and sops is already at 3.7.3, the latest. I think that's everything, except for Kubernetes. Let me know if you find anything I have missed, I'll add it.

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.

pjbgf commented 2 years ago

@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.

kingdonb commented 2 years ago

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: