#228 clarify policy on atomic host support for older Fedora "number" releases
Closed: Fixed 2 years ago Opened 2 years ago by dustymabe.

After talking with people from the fedora community and from the atomic WG it has become clear that there is a lot of confusion on our policy for support for N-1 releases of Fedora Atomic Host.

First off some terminology:
support: means that we test and release new 2 week releases for this number release (i.e. we currently test/release new two week releases of Fedora 25 Atomic Host).
N-1: currently is Fedora 24 Atomic Host
life support: means that we still push out OSTree updates for the OSTree that backs this number release, but we don't create new image releases and we don't formally test it.

Currently we have been offering support for the current (N) release of Fedora and life support for the previous (N-1) release of Fedora. In the future I'd like to formalize our support policy and stop providing life support for previous releases once it is no longer a current release.

There are a couple of reasons for this:

  • The level of effort going into N-1 is very minimal and I wouldn't want someone running that to get a false sense of security from it.
  • If N-1 breaks in releng for whatever reason, spending time on N-1 is not a high priority and I'd like to not have to fix it if it breaks.

For F26 I'd like to formally state this policy of supporting only the N release. We can also life support the N-1 for an agreed upon time period after the N release (30to60 days or something) to allow for transition.

Note: There is also some discussion about making Fedora Atomic a rolling release. That is outside the scope of this ticket.


-1 on dropping Life Support for N-1 unless we're ready to shift to rolling releases. That's pretty much the worst of all possible worlds.

Proposed policy: Life Support+

From the date N is released:

  • We continue offering OSTree updates for 6 months on N-1
  • We do not do "releases" of N-1 in terms of new images, etc.
  • We run automated tests (only) on N-1 OStrees once every 2 weeks, when a new N is released.

Running tests on the OSTree means:

  1. Install last image of N-1
  2. Upgrade to latest OSTree in that series
  3. Run whatever automated tests we have

I'd just like to clarify for anyone reading this that "rolling" doesn't mean rolling like rawhide or suse tumbleweed, unless the wheel you have in mind is giant and square and "turns" once each six months when a new fedora comes out.

RHEL and CentOS atomic hosts "roll" from 7.1 to 7.2 to 7.3, etc. The user upgrades w/ atomic host upgrade and there's no rebasing or editing of repo config files required. When we talk about making fedora atomic a rolling release, this is the sort of rolling we're talking about. A very modest (and completely sensible, imo) sort of rolling.

-1 on dropping Life Support for N-1 unless we're ready to shift to rolling releases. That's pretty much the worst of all possible worlds.
Proposed policy: Life Support+
From the date N is released:

We continue offering OSTree updates for 6 months on N-1
We do not do "releases" of N-1 in terms of new images, etc.
We run automated tests (only) on N-1 OStrees once every 2 weeks, when a new N is released.

Running tests on the OSTree means:

Install last image of N-1
Upgrade to latest OSTree in that series
Run whatever automated tests we have

I would prefer not to pretend we support it and would rather have it be clear to the user. What about complex relationships between docker and openshift/kubernetes? What about breakages in releng? What about changes to our processes that we can't/won't change for the older release? All of those things multiply and start to make things more of a maintenance burden. I'd prefer to concentrate our efforts on the existing release (and also prepare for the next release) without having to worry about N-1.

@jbrooks
I'd just like to clarify for anyone reading this that "rolling" doesn't mean rolling like rawhide or suse tumbleweed, unless the wheel you have in mind is giant and square and "turns" once each six months when a new fedora comes out.
RHEL and CentOS atomic hosts "roll" from 7.1 to 7.2 to 7.3, etc. The user upgrades w/ atomic host upgrade and there's no rebasing or editing of repo config files required. When we talk about making fedora atomic a rolling release, this is the sort of rolling we're talking about. A very modest (and completely sensible, imo) sort of rolling.

you and @maxamillion should schedule that VFAD so we can flesh out this :)

+1 on dropping support for N-1, the premise of Atomic Host was to move forward faster and adding legacy Fedora release lifecycle update streams to that seems counter productive.

I'm +1 to dropping support for N-1

Metadata Update from @dustymabe:
- Issue tagged with: meeting

2 years ago

In which case: if we're not supporting N-1, then what's the reason to not do a rolling release?

AFAICT, the thought is that rolling is a big disruptive thing, so we need to study it first. We are in fact not supporting N-1 now, so making that official isn't really a big deal.

we just need to agree on what rolling means to us and write it down somewhere. It could mean a lot of different things. The VFAD on this topic should resolve this. Let's not discuss what rolling means to us here.

@jasonbrooks I am -1 to make desupporting the old ostree official without at least a plan (and a deadline) to move to rolling upgrades. See #231 for my explanation on why these two issues are inexorably tied together.

I'm going to schedule a meeting for next week to hash this out with the whole Atomic WG that can make it.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link, e.g. we'd do:

ln -sr repo/refs/heads/fedora/26/x86_64/atomic-host repo/refs/heads/fedora/stable/x86_64/atomic-host

Then someone who wants the "follow the latest major" behavior automatically now today could opt-in to it.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link

I like this and would use it myself.

One thing we could do that would be pretty easy is to add a new /stable ref as a symbolic link, e.g. we'd do:
ln -sr repo/refs/heads/fedora/26/x86_64/atomic-host repo/refs/heads/fedora/stable/x86_64/atomic-host
Then someone who wants the "follow the latest major" behavior automatically now today could opt-in to it.

Interesting. Would a rebase still be required? I still think that sticking w/ the supported version should be the default, and you'd instead opt in to forgoing support, but failing that, this sounds nicer than what we have now.

A rebase would only be required one time to track /stable - thereafter it'd be a stream of minor updates, until such time as on the server we change the link to point to the next major.

Basically the client is just going to download whatever the server says.

+1 on dropping support for N-1 releases.

As discussed in the Atomic WG meeting, I've taken a crack at communicating this change:

Future Plans for Fedora Atomic Release Life Cycle

  • The Fedora Project ships new releases at ~6 month intervals, and maintains each release for ~13 months. Release X is supported until one month after the release of Release X+2.

  • Since the first Fedora Atomic host shipped, as part of Fedora 21, the project has maintained separate ostree repositories for both of the active Fedora releases. For instance, there are currently trees available for Fedora Atomic 25 and Fedora Atomic 24.

  • Fedora Atomic sets out to be a particularly fast-moving branch of Fedora, with releases every two weeks and updates to key “atomic” components such as docker and kubernetes that move more quickly than one might expect from Fedora.

  • Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

  • Starting with either the Fedora 26 to 27 or the 27 to 28 upgrade cycle, the Fedora Atomic Workgroup intends to collapse Fedora Atomic into a single version which will track the latest stable Fedora branch. When a new stable version of Fedora is released, Fedora Atomic users will automatically shift to the new version when they install updates.

  • Traditional OS upgrades can be disruptive and error-prone, but due to the image-based technologies that Atomic Hosts use for system components (rpm-ostree) and for applications (linux containers), upgrading an Atomic Host between major releases is little different than installing updates within a single release.

  • In both scenarios, the system updates are applied by running an rpm-ostree command and rebooting, with rollback to the previous state available in case something goes wrong, and applications running in containers are unaffected by the host upgrade or update.

  • There’s work that must be done to prepare for this collapsed release structure, but for users that wish to opt for this new behavior starting with the upcoming Fedora 25 to Fedora 26 upgrade cycle, we’ll be preparing a “stable” ostree repo location that you can rebase to follow the latest major release. Look for more information on that shortly.

Suggested revision:

  • Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

Should be

  • Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a "best effort" basis, meaning that the ostree is updated, but there is no organized testing of the older releases.

Suggested revision:

Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree, and dealing with support of the older release on a best-effort basis.

Should be

Due in part to this faster pace, the Fedora Atomic workgroup has always focused its testing and integration efforts most directly on the latest stable release, encouraging users of the older release to rebase to the newer tree as soon as possible. Releases older than the current tree are supported only on a "best effort" basis, meaning that the ostree is updated, but there is no organized testing of the older releases.

+1

waiting on fedora magazine post for this (to try to reach broader audience) and then we'll close.

Metadata Update from @dustymabe:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata