-
Notifications
You must be signed in to change notification settings - Fork 59
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
update barrier approach to major upgrades #480
Comments
We discussed this in the FCOS meeting today. There were differing opinions and we agreed to continue the discussion and open this ticket to get other opinions. |
My vote: use update barriers. I think it starts to become more valuable when we get to Fedora 33 and you ask yourself what happens when someone boots up |
I'm a bit torn on this. I agree it seems like a natural place to have an update barrier before a major upgrade. But the thing is, IMO a lot of the unknowns from upgrade testing come from bits that aren't captured in the OSTree commit. This is why for example, we needed a barrier for the cgroupsv1 bits when we went from f30 to f31 (because kargs are not yet part of the OSTree commit). And adding an upgrade barrier when there's nothing that actually needs to be migrated/worked around doesn't really do anything to resolve that uncertainty. I'm sure we'll eventually hit things that are part of the OSTree commit which passing through a barrier will fix. But it feels odd to just directly assume that without actually having knowledge of such issues. So... I lean more now towards not having a barrier. We should definitely enhance our upgrade testing though to not only start from the previous release but older ones too. |
(Related aside: worth noting that for some time OpenShift CI would bootstrap from el7 RHCOS and pivot to el8 RHCOS and IIRC that wasn't really a big source of problems.) |
Quoting from IRC:
|
We'd be less likely to forget this if we had an update barrier for each Fedora major, but I guess only doing it for every two is OK. |
i'm wrong. we'd need to create barrier for each new release the barrier would guard against nodes updating from N-2 to N |
We discussed this in the community meeting today. There are two options that we were discussing:
|
Create an update barrier for the last version of N-2 so all previous versions have to go through that last version of N-2, which is guaranteed to have the key for N. Decision documented in coreos/fedora-coreos-tracker#480 (comment)
Create an update barrier for the last version of N-2 so all previous versions have to go through that last version of N-2, which is guaranteed to have the key for N. Decision documented in coreos/fedora-coreos-tracker#480 (comment)
updating the SOP notes in coreos/fedora-coreos-config#414 |
Create an update barrier for the last version of N-2 so all previous versions have to go through that last version of N-2, which is guaranteed to have the key for N. Decision documented in coreos/fedora-coreos-tracker#480 (comment)
Create an update barrier for the last version of N-2 so all previous versions have to go through that last version of N-2, which is guaranteed to have the key for N. Decision documented in coreos/fedora-coreos-tracker#480 (comment)
Create an update barrier for the last version of N-2 so all previous versions have to go through that last version of N-2, which is guaranteed to have the key for N. Decision documented in coreos/fedora-coreos-tracker#480 (comment)
Note that for f32 specifically we don't need to retrofit a barrier. For testing, we currently already have a barrier at 30.20191014.1. And checking that:
For stable, we don't have a barrier, but the first release was 31.20200108.3.0, which definitely should have the f32 key. Sanity-checking:
|
thanks for that clarity @jlebon - since coreos/fedora-coreos-config#414 has now merged I'll close this out. |
As part of the procedure to move to the next major Fedora release we are adding a barrier for the last release of Fedora CoreOS based on Fedora 31 content. This is a guarantee that systems have the appropriate keys to validate the commits signed by the latest builds. Note: there were no F31 releases on the `next` stream so skip adding the barrier release there. See: - coreos/fedora-coreos-tracker#480 (comment) - https://github.com/coreos/fedora-coreos-config#moving-to-a-new-major-version-n-of-fedora
As part of the procedure to move to the next major Fedora release we are adding a barrier for the last release of Fedora CoreOS based on Fedora 31 content. This is a guarantee that systems have the appropriate keys to validate the commits signed by the latest builds. Note: there were no F31 releases on the `next` stream so skip adding the barrier release there. See: - coreos/fedora-coreos-tracker#480 (comment) - https://github.com/coreos/fedora-coreos-config#moving-to-a-new-major-version-n-of-fedora
This update barrier is pretty much useless because of coreos/fedora-coreos-tracker#749, but we decided to put them in place anyway just to keep following the process. As far as the process goes. See past discussion on this topic: - coreos/fedora-coreos-tracker#480 (comment) - https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/
This update barrier is pretty much useless because of coreos/fedora-coreos-tracker#749, but we decided to put them in place anyway just to keep following the process. As far as the process goes. See past discussion on this topic: - coreos/fedora-coreos-tracker#480 (comment) - https://docs.fedoraproject.org/en-US/fedora-coreos/update-barrier-signing-keys/
When I was going through and executing the rebase for the F37 cycle I noticed that what we have actually been doing is not adding a barrier for This prompted new discussion on We decided:
So we basically decided to go with |
As discussed in the meeting today: coreos/fedora-coreos-tracker#480 (comment)
As discussed in the meeting today: coreos/fedora-coreos-tracker#480 (comment)
Our update framework allows us to specify update barriers (which means we make updates from an older software version update to a particular version first before allowing it to get access to newer versions). In general how should we approach major upgrades where we jump from Fedora N-1 to Fedora N base content?
Not using an update barrier
Using an update barrier:
We need to try to decide what we think is the best approach for this and apply it to the pending major bump we have coming our way.
The text was updated successfully, but these errors were encountered: