kata-containers / kata-containers

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/
Apache License 2.0
5.08k stars 1k forks source link

Come up with a policy for bumping toolchains #9841

Open stevenhorsman opened 1 week ago

stevenhorsman commented 1 week ago

In the AC meeting on 6th June 2024 (https://etherpad.opendev.org/p/Kata_Containers_2024_Architecture_Committee_Mtgs#L45) we had a discussion about the balance of keeping our toolchains up-to-date (and the crates/packages used regularly updated) to drive out potential vulnerabilities and concerns that the distro team might have about regularly bumping.

In order to provide clarity there was a suggestion to come up with a policy for our toolchain changes and document that, so that all parties understand where they stand in respect to this.

For example we could say that every odd release we will bump to the latest stable version of golang and rust and leave it unchanged in between, or say we will bump versions every 6 months etc.

beraldoleal commented 1 week ago

Hi @stevenhorsman ...

For example we could say that every odd release we will bump to the latest stable version of golang and rust and leave it unchanged in between, or say we will bump versions every 6 months etc.

IIUC, the idea is to bump on minor odd releases. Is that right?

If so, my concern is that we might (unintentionally) break behaviour by bumping tooling during minor releases.

When MINOR increases, the new release adds new features but without changing the existing behavior.

stevenhorsman commented 1 week ago

@beraldoleal - I was just listing an example of something we could do, rather than a community proposal. Nevertheless, I don't think there is likely to be a change of behaviour, other that removing security bugs, when bumping the toolchain.

If your proposal is that we only bump toolchains on major releases, then either we need a lot more major releases, or we wrap up the project as using two year old toolchains that are past EoL by nearly two years (rust for example only has 6 weeks before the next release makes it EoL) means we are going to be broken with CVE and not able to get new features from dependencies, making development impossible.

beraldoleal commented 1 week ago

@beraldoleal - I was just listing an example of something we could do, rather than a community proposal. Nevertheless, I don't think there is likely to be a change of behaviour, other that removing security bugs, when bumping the toolchain.

If your proposal is that we only bump toolchains on major releases, then either we need a lot more major releases, or we wrap up the project as using two year old toolchains that are past EoL by nearly two years (rust for example only has 6 weeks before the next release makes it EoL) means we are going to be broken with CVE and not able to get new features from dependencies, making development impossible.

Yes, I agree with you, we need to find a middle ground. I was just pointing to our MAJOR vs MINOR "agreement", that we should just take that into consideration. I believe this will be case by case, tho.