dustymabe reported a new issue against the project: `atomic-wg` that you are following: `` 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 **support**ing 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.
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jberkus added a new comment to an issue you are following: `` -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 ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
dustymabe added a new comment to an issue you are following: ``
-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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
dustymabe added a new comment to an issue you are following: ``
@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 :) ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jberkus added a new comment to an issue you are following: `` In which case: if we're not supporting N-1, then what's the reason to not do a rolling release? ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jasonbrooks added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jberkus added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jberkus added a new comment to an issue you are following: `` I'm going to schedule a meeting for next week to hash this out with the whole Atomic WG that can make it. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
walters added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
walters added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
kushal added a new comment to an issue you are following: `` +1 on dropping support for N-1 releases. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jasonbrooks added a new comment to an issue you are following: `` 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](https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle) 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jberkus added a new comment to an issue you are following: `` 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 it. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jasonbrooks added a new comment to an issue you are following: ``
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
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
jasonbrooks added a new comment to an issue you are following: `` PR for this blog post at: https://github.com/projectatomic/atomic-site/pull/434 ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
dustymabe added a new comment to an issue you are following: `` jbrooks has published blog post on pa.io http://www.projectatomic.io/blog/2017/06/future-plans-for-fedora-atomic-rele... ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
dustymabe added a new comment to an issue you are following: `` waiting on fedora magazine post for this (to try to reach broader audience) and then we'll close. ``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
dustymabe added a new comment to an issue you are following: `` fed mag post here: https://fedoramagazine.org/upcoming-fedora-atomic-lifecycle-changes/
``
To reply, visit the link below or just reply to this email https://pagure.io/atomic-wg/issue/228
The status of the issue: `clarify policy on atomic host support for older Fedora "number" releases` of project: `atomic-wg` has been updated to: Closed as Fixed by dustymabe.