F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)

[Vipul Siddharth]

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

This change is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.


== Owners ==

* Name: [[User:cverna|Clement Verna]]
* Email: cverna(a)fedoraproject.org

* Products: Fedora CoreOS
* Responsible WGs: Fedora CoreOS Group


== Detailed Description ==

This change is to promote Fedora CoreOS to Edition status alongside
Workstation, Server and IoT.

[https://fedoraproject.org/wiki/Editions/Promotion_Process#Prerequisites
Prerequisites] are tracked bellow :

* Edition has a team with regular public meeting :
[https://apps.fedoraproject.org/calendar/meeting/9437/ weekly meeting
happening on #fedora-meeting-1]

* Trademark approval from the Fedora Council :
[https://pagure.io/Fedora-Council/tickets/issue/340 council ticket]

* Product requirements document (PRD) :
https://fedoraproject.org/wiki/CoreOS/PRD

* Technical specification :
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md


== Feedback ==

This change was previously submitted for Fedora 34 and feedback were
collected in the following [https://pagure.io/fesco/issue/2516 FESCo
ticket].
The 2 main feedback received are either addressed or in the process of
being addressed.

* FCOS should not trail behind the latest Major Fedora version: see
[[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major
Fedora Version release Go/NoGo criteria]]

* FCOS should demonstrate the test case mapping to the Basic Release
Criteria: see
[[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Basic_Release_Criteria|Basic
Release Criteria]]


== Benefit to Fedora ==

Make Fedora CoreOS an official edition, will help spread adoption and
position Fedora as credible solution for running container workflow.

We have started to publish monthly update of what is happening in
Fedora CoreOS based on the feedback received from
[https://discussion.fedoraproject.org/t/fedora-coreos-survey/34408/2 a
community survey]. Part of these monthly update are
[https://discussion.fedoraproject.org/t/this-month-in-fedora-coreos-may-20...
the count me stats] which gives us a good understanding of FCOS
adoption.


== Scope ==
* Proposal owners: see change owners

* Other developers: N/A

* Release engineering: Fedora CoreOS is already being composed and released.

* Policies and guidelines: N/A

* Trademark approval: https://pagure.io/Fedora-Council/tickets/issue/340


== How To Test ==

See QA test cases :
https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases and Fedora
CoreOS own test suite Kola
https://github.com/coreos/coreos-assembler/blob/main/docs/kola.md#testing...

We also have regular tests days, for example
https://fedoramagazine.org/fedora-coreos-test-day/


=== Basic Release Criteria ===

We are currently evaluating our compliance to the Fedora Basic Release
Criteria https://github.com/coreos/fedora-coreos-tracker/issues/1239.
This is an effort that will be done during the Fedora 37 development cycle.


==== Supported Architecture and Platforms ====

Fedora CoreOS is currently built for the x86_64, aarch64 and s390x
architecture, These
[https://docs.fedoraproject.org/en-US/fedora-coreos/platforms/#_well_known...
platforms] are supported and can be configured directly using
Ignition.

The [https://github.com/coreos/mantle/tree/cl/kola kola] test suite is
run for each stream release on AWS, Azure, GCP and OpenStack.


==== Stream release Go/NoGo ====

Stream releases are scheduled fortnightly, a GitHub issue
([https://github.com/coreos/fedora-coreos-streams/issues/242 example])
is created for each stream release with the release process.
The release status can be tracked in each ticket. If each steps and
validation were successful the release is considered GO.

Issues are reported in the
[https://github.com/coreos/fedora-coreos-tracker issue tracker] and
discussed during the weekly
[https://github.com/coreos/fedora-coreos-tracker#meetings IRC
meeting]. A stream release can become a NOGO during these meeting, the
blocker issue is then linked to the release GitHub issue.


==== Major Fedora Version release Go/NoGo ====

The policies around the Major version rebases are described in Fedora
CoreOS document
https://github.com/coreos/fedora-coreos-tracker/blob/main/Design.md#major...
(see copy below)

The release process integrates with Fedora's release milestones in the
following ways:

Fedora Beta Release
  The next stream is switched over to the new release.
Fedora Final Freeze
  The next stream switches to weekly releases to closely track the GA
content set.
Fedora General Availability
Fedora CoreOS re-orients its release schedule in the following way:
  Week -1 (Fedora "Go" Decision): next release:
     next release with final Fedora GA content
  Week 0 (GA release): triple release:
     testing release promoted from previous next
     next release contains latest Fedora N content, including Bodhi updates
  Week 2: triple release:
     stable release promoted from previous testing, now fully rebased
to Fedora N
     testing and next are now in sync


== Contingency Plan ==
Contingency mechanism: (What to do? Who will do it?) Delay promotion until F38

Contingency deadline: F37 Final release date

Blocks release? No


== Documentation ==
https://docs.fedoraproject.org/en-US/fedora-coreos/

-- 
Vipul Siddharth
He/His/Him
FPgM team member

[Chris Murphy]

On Sat, Jun 25, 2022 at 12:17 PM Vipul Siddharth
<siddharthvipul1(a)gmail.com&gt; wrote:
>  This document represents a proposed Change. As part of the Changes
>  process, proposals are publicly announced in order to receive
>  community feedback. This proposal will only be implemented if approved
>  by the Fedora Engineering Steering Committee.
>
>
>  == Summary ==
>
>  This change is to promote Fedora CoreOS to Edition status alongside
>  Workstation, Server and IoT. 
Consider updating the proposal to include Cloud since it now has
Edition status once again.


-- 
Chris Murphy

[Dusty Mabe]

On 6/27/22 13:36, Chris Murphy wrote:
>  On Sat, Jun 25, 2022 at 12:17 PM Vipul Siddharth
>  <siddharthvipul1(a)gmail.com&gt; wrote:
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> >
> > This change is to promote Fedora CoreOS to Edition status alongside
> > Workstation, Server and IoT.
>  
>  Consider updating the proposal to include Cloud since it now has
>  Edition status once again. 
Updated!

Thanks for the feedback.

[Timothée Ravier]

We also probably need a new FESCO ticket. The current one still points to the one from the
F34 change request:
- https://fedoraproject.org/wiki/Changes/FedoraCoreOS
- https://pagure.io/fesco/issue/2516

[Dusty Mabe]

On 7/5/22 10:10, Timothée Ravier wrote:
>  We also probably need a new FESCO ticket. The current one still
> points to the one from the F34 change request:
>  - https://fedoraproject.org/wiki/Changes/FedoraCoreOS
>  - https://pagure.io/fesco/issue/2516 
Yes. I imagine as part of this process a new ticket will get created for F37

Dusty

[Neal Gompa]

On Sat, Jun 25, 2022 at 2:17 PM Vipul Siddharth
<siddharthvipul1(a)gmail.com&gt; wrote:
>  == Feedback ==
>
>  This change was previously submitted for Fedora 34 and feedback were
>  collected in the following [https://pagure.io/fesco/issue/2516 FESCo
>  ticket].
>  The 2 main feedback received are either addressed or in the process of
>  being addressed.
>
>  * FCOS should not trail behind the latest Major Fedora version: see
>
> [[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major
>  Fedora Version release Go/NoGo criteria]]
>  
I don't feel this is sufficiently addressed. Why is it that the stable
stream can't be switched when all the other artifacts are released?
Why is it two weeks *after* GA?



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Dusty Mabe]

On 7/5/22 17:03, Neal Gompa wrote:
>  On Sat, Jun 25, 2022 at 2:17 PM Vipul Siddharth
>  <siddharthvipul1(a)gmail.com&gt; wrote:
> >
> >
> > == Feedback ==
> >
> > This change was previously submitted for Fedora 34 and feedback were
> > collected in the following [https://pagure.io/fesco/issue/2516 FESCo
> > ticket].
> > The 2 main feedback received are either addressed or in the process of
> > being addressed.
> >
> > * FCOS should not trail behind the latest Major Fedora version: see
> >
> [[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major
> > Fedora Version release Go/NoGo criteria]]
> >
>  
>  I don't feel this is sufficiently addressed. Why is it that the stable
>  stream can't be switched when all the other artifacts are released?
>  Why is it two weeks *after* GA? 
Fedora CoreOS is unique in that by default nodes are automatically updated. We let the
exact content
set that we are going to ship to our `stable` stream bake in our `testing` stream for ~two
weeks. This
allows people to find issues that we don't find in our CI and report them. We find CI
is good, but
there is no substitute for real workloads.

The exact content set delivered as part of Fedora GA isn't available two weeks before
GA date so it's
hard for us to ship GA content in our `stable` stream on GA day and follow our current
update model.

We do have the `next` stream which does get updated often in the weeks before GA, but a
significantly
smaller set of users are running `next`.

Dusty

[Chris Murphy]

On Tue, Jul 5, 2022 at 9:43 PM Dusty Mabe <dusty(a)dustymabe.com&gt; wrote:
>  On 7/5/22 17:03, Neal Gompa wrote:
>  > On Sat, Jun 25, 2022 at 2:17 PM Vipul Siddharth
>  > <siddharthvipul1(a)gmail.com&gt; wrote:
>  >>
>  >>
>  >> == Feedback ==
>  >>
>  >> This change was previously submitted for Fedora 34 and feedback were
>  >> collected in the following [https://pagure.io/fesco/issue/2516 FESCo
>  >> ticket].
>  >> The 2 main feedback received are either addressed or in the process of
>  >> being addressed.
>  >>
>  >> * FCOS should not trail behind the latest Major Fedora version: see
>  >>
> [[https://fedoraproject.org/wiki/Changes/FedoraCoreOS#Major_Fedora_Version_release_Go/NoGo|Major
>  >> Fedora Version release Go/NoGo criteria]]
>  >>
>  >
>  > I don't feel this is sufficiently addressed. Why is it that the stable
>  > stream can't be switched when all the other artifacts are released?
>  > Why is it two weeks *after* GA?
>
>  Fedora CoreOS is unique in that by default nodes are automatically updated. We let the
> exact content
>  set that we are going to ship to our `stable` stream bake in our `testing` stream for
> ~two weeks. This
>  allows people to find issues that we don't find in our CI and report them. We find CI
> is good, but
>  there is no substitute for real workloads.
>
>  The exact content set delivered as part of Fedora GA isn't available two weeks before
> GA date so it's
>  hard for us to ship GA content in our `stable` stream on GA day and follow our current
> update model.
>
>  We do have the `next` stream which does get updated often in the weeks before GA, but a
> significantly
>  smaller set of users are running `next`. 
Given the amount of testing happening to produce GA, is it possible to
have an exception to the 2 week rule for GA?

-- 
Chris Murphy

[Adam Williamson]

On Tue, 2022-07-05 at 23:29 -0400, Chris Murphy wrote:
>  > 
>  > Fedora CoreOS is unique in that by default nodes are automatically updated. We let
> the exact content
>  > set that we are going to ship to our `stable` stream bake in our `testing` stream
> for ~two weeks. This
>  > allows people to find issues that we don't find in our CI and report them. We
> find CI is good, but
>  > there is no substitute for real workloads.
>  > 
>  > The exact content set delivered as part of Fedora GA isn't available two weeks
> before GA date so it's
>  > hard for us to ship GA content in our `stable` stream on GA day and follow our
> current update model.
>  > 
>  > We do have the `next` stream which does get updated often in the weeks before GA,
> but a significantly
>  > smaller set of users are running `next`.
>  
>  Given the amount of testing happening to produce GA, is it possible to
>  have an exception to the 2 week rule for GA? 
I did talk about this with Dusty already, and my opinion is the two
week delay is fine. The situations aren't the same, as Dusty said,
CoreOS is unique here: pushing something out on the 'stable' stream
means that almost all CoreOS users (who haven't changed the default
config) will get it almost immediately. That's not the case with
'regular' Fedora installs, where the user chooses when to upgrade. Many
users don't upgrade to a new release as soon as it comes out, they'd
rather wait and see how things shake out. For me, the two week delay
for the CoreOS 'stable' stream to be kicked over is just the same as
that.

I wouldn't be happy if we didn't have a coherent and definite story to
tell here, but "the CoreOS stable stream will update to the new release
in two weeks, or you can switch to the 'next' stream to get it right
away!" is a perfectly fine story to tell on release day, I think.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net