Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/FedoraCoreOS

== Summary ==

This changes 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 changes 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 ==

== Benefit to Fedora ==

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

== 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

== Upgrade/compatibility impact ==
N/A

== How To Test ==
See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases

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

== User Experience ==

==== Pros ====

==== Enhancement opportunities ====

== Dependencies ==

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

Contingency deadline: F34 Final release date

Blocks release? No

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

== Release Notes ==


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Wed, Dec 2, 2020 at 9:23 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/FedoraCoreOS
>
>  == Summary ==
>
>  This changes 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 changes 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 ==
>
>  == Benefit to Fedora ==
>
>  Make Fedora CoreOS an official edition, will help spread adoption and
>  position Fedora as credible solution for running container workflow.
>
>  == 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
>
>  == Upgrade/compatibility impact ==
>  N/A
>
>  == How To Test ==
>  See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
>
>  We also have regular tests days, for example
>  https://fedoramagazine.org/fedora-coreos-test-day/
>
>  == User Experience ==
>
>  ==== Pros ====
>
>  ==== Enhancement opportunities ====
>
>  == Dependencies ==
>
>  == Contingency Plan ==
>  Contingency mechanism: (What to do? Who will do it?) Delay promotion until F35
>
>  Contingency deadline: F34 Final release date
>
>  Blocks release? No
>
>  == Documentation ==
>  https://docs.fedoraproject.org/en-US/fedora-coreos/
>
>  == Release Notes == 
Meh, sure I guess? This is a paperwork change. It's been considered an
Edition in practice since it replaced Fedora Atomic, which *was* a
full Edition in its own right.


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

[Adam Williamson]

On Wed, 2020-12-02 at 09:56 -0500, Neal Gompa wrote:
>  
>  Meh, sure I guess? This is a paperwork change. It's been considered an
>  Edition in practice since it replaced Fedora Atomic, which *was* a
>  full Edition in its own right. 
I would dispute that. To me the most obvious factor here is: what do
you see when you go to download Fedora? What you see is this:

https://getfedora.org/

which is very clear that the Editions - the primary Fedora Things - are
Workstation, Server and IoT. CoreOS and Silverblue are clearly labeled
"Emerging Fedora Editions", which clearly communicates to people "these
are things we consider important but aren't ready to make the Main
Things" yet - they are, as the subhead says, "the future of Fedora".
This is admirably clear messaging, I think, and it means that people
will give us a pass on all the sorts of awkward questions I asked in my
other mail.

If CoreOS moves up a few hundred pixels, we will *not* get a pass on
those questions. If we release a bad CoreOS, it will reflect badly on
Fedora. If we do a "Fedora release" and just basically forget to
include CoreOS in the messaging for that release at all, that will look
bad.

Note that if you go to getfedora.org and click on CoreOS *right now*,
it offers you a Fedora 32-based CoreOS. This is the kind of thing that
is kinda fine so long as it's an Emerging Edition. It would *not*,
IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
months after Fedora 34 is "released", our "stable" CoreOS is still
Fedora 33-based, that seems like the sort of thing that would look bad.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Dusty Mabe]

On 12/2/20 12:33 PM, Adam Williamson wrote:

<snip>

>  
>  Note that if you go to getfedora.org and click on CoreOS *right now*,
>  it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>  is kinda fine so long as it's an Emerging Edition. It would *not*,
>  IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>  months after Fedora 34 is "released", our "stable" CoreOS is still
>  Fedora 33-based, that seems like the sort of thing that would look bad.
>   
There are three update streams for Fedora CoreOS. The "stable" stream is still
on Fedora 32 but has been receiving bi-weekly updates and should be switched over
to Fedora 33 soon (probably this week). The `next` and `testing` streams have been
updated to Fedora 33 and the `next` stream has been on F33 since early october. My
point here is that if you want Fedora 33 and you are a Fedora CoreOS user you can
easily adopt a stream that has it.

Why is our FCOS stable stream still on Fedora 32? Our FCOS instances have automatic
updates on by default and we're trying very hard to not break systems on upgrade and
require human intervention. There are several changes in Fedora 33, including migrating
to systemd-resolved and also systemd changing the default fallback hostname from
`localhost`
to `fedora` that are causing issues for people and we're trying to consider these
things first.

Ideally we update our stable stream closer to Fedora's actual release date but I think
it's
important to maybe release Fedora CoreOS from the notion that it's tightly coupled
with the
Fedora major release date for a few reasons:

- we have people follow update streams and systems update automatically
- it's more of a "rolling" release, with incremental feature improvements
and major rebases periodically
    - this is a departure from Atomic Host where you had to manually decide when to do a
major rebase
    - new features get added all the time, mid stream, so it's more of a continuous
development model

Ultimately it's just a slightly different release/development model (adopted from
CoreOS Container
Linux) than what Fedora has traditionally used, but I don't think that's any
reason to treat it like
it's not Fedora. We should embrace it and see the positives along with the negatives
of the model.

Dusty

P.S. For more info on our various update streams see:
https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/

[Kamil Paral]

On Thu, Dec 3, 2020 at 3:27 AM Dusty Mabe <dusty(a)dustymabe.com&gt; wrote:

>  There are three update streams for Fedora CoreOS. The
> "stable" stream is
>  still
>  on Fedora 32 but has been receiving bi-weekly updates and should be
>  switched over
>  to Fedora 33 soon (probably this week). The `next` and `testing` streams
>  have been
>  updated to Fedora 33 and the `next` stream has been on F33 since early
>  october. My
>  point here is that if you want Fedora 33 and you are a Fedora CoreOS user
>  you can
>  easily adopt a stream that has it.
>  
Since FCOS has automatic updates, perhaps the messaging could be something
along the lines "Selected users will begin their automatic upgrade process
to F34 in the next few days, and the full rollout to all users is expected
to be finished in a couple of weeks. If you want to upgrade early, you can
manually switch to the 'testing' branch immediately.". I think it's
pretty
much expected these days that major large-scale upgrades first hit 1% of
the user base, then 10%, then 100% (or similar). Think Android/iOS
upgrades, etc. So if the same approach is taken with FCOS, shortly after
F34 is GA, I believe this process can be pretty clear to the users, if
explained well. And integrate well with their and our expectations at the
same time.

[Adam Williamson]

On Wed, 2020-12-02 at 21:25 -0500, Dusty Mabe wrote:

>  
>  Ideally we update our stable stream closer to Fedora's actual release date but I
> think it's
>  important to maybe release Fedora CoreOS from the notion that it's tightly coupled
> with the
>  Fedora major release date for a few reasons: 
I'm pretty sure I covered this in my original mail.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Ben Cotton]

One uncomfortable question that this raises: is it time to de-Edition
Fedora Server? We'd still produce it, but it would no longer be
considered an Edition (and thus potentially not block releases, etc,
the exact implications would have to be worked out)

As far as I can tell, the Server Working Group has essentially been
dormant for a while, with sgallagh coming in to fix issues when they
arise. So one alternative to demoting Server would be for someone to
revive that WG.

Fedora CoreOS is not an exact replacement for Fedora Server, of
course, but this does present what feels like a natural opportunity to
ask this question.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  One uncomfortable question that this raises: is it time to de-Edition
>  Fedora Server? We'd still produce it, but it would no longer be
>  considered an Edition (and thus potentially not block releases, etc,
>  the exact implications would have to be worked out)
>
>  As far as I can tell, the Server Working Group has essentially been
>  dormant for a while, with sgallagh coming in to fix issues when they
>  arise. So one alternative to demoting Server would be for someone to
>  revive that WG.
>
>  Fedora CoreOS is not an exact replacement for Fedora Server, of
>  course, but this does present what feels like a natural opportunity to
>  ask this question.
>  
There were a number of people interested in helping with reviving the
Server WG, myself included. But we don't know how to have that move
forward. We've never really had a situation like this before...



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

[Adam Williamson]

On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:
>  On Wed, Dec 2, 2020 at 11:11 AM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  > 
>  > One uncomfortable question that this raises: is it time to de-Edition
>  > Fedora Server? We'd still produce it, but it would no longer be
>  > considered an Edition (and thus potentially not block releases, etc,
>  > the exact implications would have to be worked out)
>  > 
>  > As far as I can tell, the Server Working Group has essentially been
>  > dormant for a while, with sgallagh coming in to fix issues when they
>  > arise. So one alternative to demoting Server would be for someone to
>  > revive that WG.
>  > 
>  > Fedora CoreOS is not an exact replacement for Fedora Server, of
>  > course, but this does present what feels like a natural opportunity to
>  > ask this question.
>  > 
>  
>  There were a number of people interested in helping with reviving the
>  Server WG, myself included. But we don't know how to have that move
>  forward. We've never really had a situation like this before... 
I'm not sure it's really warranted, to be honest. A counterpoint is
that you can consider Server to be sort of dormant *because it works*.
We have a defined set of capabilities for Fedora Server, testing of
them is almost entirely automated, and our releases keep providing
those capabilities reliably. We have a couple of representative boring-
server-things that Server is required to be able to do well: being a
database server, and being a FreeIPA server. We have decent automated
tests for those, and when they break, people jump on them and fix them.
All our Fedora Server releases have met them pretty well. People run it
and are happy.

CoreOS can be a database server too, of course. I could set things up
to run those tests for CoreOS builds, I guess. I'm not sure it can be a
FreeIPA server, or if anyone's even tried.

Of course, we can keep publishing Server images and providing those
capabilities without calling it an Edition, but...I'm not sure it just
being sort of quiet and undramatic necessarily merits that, especially
if we don't have clear replacements for its capabilities yet.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Ben Cotton]

On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:

>  There were a number of people interested in helping with reviving
> the
>  Server WG, myself included. But we don't know how to have that move
>  forward. We've never really had a situation like this before...
>  
I'd start with staging a takeover of https://fedoraproject.org/wiki/Server

It looks like there are no meeting logs in the last two years, so I
don't think you'll get much pushback.

I talked to sgallagh before posing this question, so I don't expect
you'll get any pushback. If anything, you'll probably make people
happy. :-)

On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  I'm not sure it's really warranted, to be honest. A counterpoint is
>  that you can consider Server to be sort of dormant *because it works*. 
Is "it still works" sufficient to keep a deliverable at the forefront?
Obviously we want what we ship to work, whether it's an Edition or
bex's Llama Herder Lab. But what is Server doing to move the state of
the art forward? Server is a slightly different case in that generally
you don't want servers to be too adventurous, but if it's in statis,
should it be a flagship?

Like I said above, the Server WG appears to be in zombie state for at
least the last two years. Is Fedora Server doing what it should be
doing now, or is it doing what it should have done two years ago?

>  Of course, we can keep publishing Server images and providing those
>  capabilities without calling it an Edition, but...I'm not sure it just
>  being sort of quiet and undramatic necessarily merits that, especially
>  if we don't have clear replacements for its capabilities yet. 
I'm certainly not advocating we drop Server entirely. But we should
evaluate its place in Fedora, particularly if there's no one providing
active care and feeding. I'd much rather see the Server WG come back
to life and keep it as an Edition.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Alexander Scheel]

On Wed, Dec 2, 2020 at 12:52 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:
>
>  > There were a number of people interested in helping with reviving the
>  > Server WG, myself included. But we don't know how to have that move
>  > forward. We've never really had a situation like this before...
>  >
>  I'd start with staging a takeover of https://fedoraproject.org/wiki/Server
>
>  It looks like there are no meeting logs in the last two years, so I
>  don't think you'll get much pushback.
>
>  I talked to sgallagh before posing this question, so I don't expect
>  you'll get any pushback. If anything, you'll probably make people
>  happy. :-)
>
>  On Wed, Dec 2, 2020 at 12:30 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > I'm not sure it's really warranted, to be honest. A counterpoint is
>  > that you can consider Server to be sort of dormant *because it works*.
>
>  Is "it still works" sufficient to keep a deliverable at the forefront?
>  Obviously we want what we ship to work, whether it's an Edition or
>  bex's Llama Herder Lab. But what is Server doing to move the state of
>  the art forward? Server is a slightly different case in that generally
>  you don't want servers to be too adventurous, but if it's in statis,
>  should it be a flagship?
>
>  Like I said above, the Server WG appears to be in zombie state for at
>  least the last two years. Is Fedora Server doing what it should be
>  doing now, or is it doing what it should have done two years ago? 
IMO, yes. I am a silent consumer of it. It provides a non-graphical
default Fedora installation that just works as a target for various
automated deployments (e.g., qemu + ansible). For both work and
non-work deployments of Fedora on VMs, Fedora Server is my default
mechanism to do so (whether on local libvirt or remote cloud
deployments). I'm not sure it really needs much care and feeding -- a
boring packaging of Fedora with some bare necessities and without any
graphical tooling doesn't need much management or steering. Changing
what is shipped in the base Server distribution frequently is an
anti-feature. That I haven't had any Server-specific bugs or issues is
a good thing.

>  > Of course, we can keep publishing Server images and providing
> those
>  > capabilities without calling it an Edition, but...I'm not sure it just
>  > being sort of quiet and undramatic necessarily merits that, especially
>  > if we don't have clear replacements for its capabilities yet.
>
>  I'm certainly not advocating we drop Server entirely. But we should
>  evaluate its place in Fedora, particularly if there's no one providing
>  active care and feeding. I'd much rather see the Server WG come back
>  to life and keep it as an Edition. 
The care and feeding of a Fedora Server edition, IMO, shouldn't come
from changes in content curation, but all the packagers involved in
maintenance of packages shipped by the edition.


My 2c.

Alex

>  --
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Fabio Valentini]

On Wed, Dec 2, 2020 at 6:48 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  On Wed, 2020-12-02 at 11:14 -0500, Neal Gompa wrote:
>
>  > There were a number of people interested in helping with reviving the
>  > Server WG, myself included. But we don't know how to have that move
>  > forward. We've never really had a situation like this before...
>  >
>  I'd start with staging a takeover of https://fedoraproject.org/wiki/Server
>
>  It looks like there are no meeting logs in the last two years, so I
>  don't think you'll get much pushback.
>
>  I talked to sgallagh before posing this question, so I don't expect
>  you'll get any pushback. If anything, you'll probably make people
>  happy. :-) 
I agree, sign me up! I've been using Fedora Server for years for my
own projects and it's been 99.9% flawless, so I would be sad if it
went away.

Fabio

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
>  I agree, sign me up! I've been using Fedora Server for years for
> my
>  own projects and it's been 99.9% flawless, so I would be sad if it
>  went away. 
No one is talking about making it go away, just de-editioning it. I'd
definitely prefer it to remain an edition, but we need it to be more active
for that to work.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Neal Gompa]

On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
>  > I agree, sign me up! I've been using Fedora Server for years for my
>  > own projects and it's been 99.9% flawless, so I would be sad if it
>  > went away.
>
>  No one is talking about making it go away, just de-editioning it. I'd
>  definitely prefer it to remain an edition, but we need it to be more active
>  for that to work.
>  
Having an active team is one thing, but making changes just because is
quite another. I don't feel it's worth demoting Fedora Server (just
like I didn't like what happened to Fedora Cloud way back when with
Atomic). But if you need me to be there to keep the WG going so it
doesn't get demoted, I'm happy to help shepherd it.



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

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Eduard Lucena]

I'm not part of the server WG, but a super interested user. Count me in to
help if needed.

Br,

El vie, 4 dic 2020 a las 14:00, Neal Gompa (<ngompa13(a)gmail.com>) escribió:

>  On Fri, Dec 4, 2020 at 11:49 AM Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
>  wrote:
>  >
>  > On Fri, Dec 04, 2020 at 10:03:24AM +0100, Fabio Valentini wrote:
>  > > I agree, sign me up! I've been using Fedora Server for years for my
>  > > own projects and it's been 99.9% flawless, so I would be sad if it
>  > > went away.
>  >
>  > No one is talking about making it go away, just de-editioning it. I'd
>  > definitely prefer it to remain an edition, but we need it to be more
>  active
>  > for that to work.
>  >
>
>  Having an active team is one thing, but making changes just because is
>  quite another. I don't feel it's worth demoting Fedora Server (just
>  like I didn't like what happened to Fedora Cloud way back when with
>  Atomic). But if you need me to be there to keep the WG going so it
>  doesn't get demoted, I'm happy to help shepherd it.
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  

-- 
Eduard Lucena
Móvil: [phone]
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Fri, Dec 04, 2020 at 11:59:17AM -0500, Neal Gompa wrote:
>  > No one is talking about making it go away, just de-editioning
> it. I'd
>  > definitely prefer it to remain an edition, but we need it to be more active
>  > for that to work.
>  Having an active team is one thing, but making changes just because is
>  quite another. I don't feel it's worth demoting Fedora Server (just
>  like I didn't like what happened to Fedora Cloud way back when with
>  Atomic). But if you need me to be there to keep the WG going so it
>  doesn't get demoted, I'm happy to help shepherd it. 
It's not a matter of making changes for change's own sake, but I would hope
that we'd have some level of innovation and experimentation in Fedora
Server. There are also just normal things like marketing materials,
promotion, blog posts, docs, etc., that can use ongoing work.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

>  Am 04.12.2020 um 19:08 schrieb Matthew Miller
> <mattdm(a)fedoraproject.org&gt;:
>  
>  It's not a matter of making changes for change's own sake, but I would hope
>  that we'd have some level of innovation and experimentation in Fedora
>  Server. There are also just normal things like marketing materials,
>  promotion, blog posts, docs, etc., that can use ongoing work.
>   
I’m not a maintainer but I use Fedora Server for a lot of our university research
institutions infrastructure (and I’m a dormant member of Fedora docs).

Just in case it is indeed considered useful and desirable I could contribute various
Fedora Server related/specific documentations and how-to's, e.g. an annotated
step-by-step guide to setup a basic server which can get extended for various purposes,
how to set up a Postgres server on top of a basic server, an infrastructure for vm’s and
containers  (including scripts and ansible templates), troubleshooting guides, and other
topics like that (mostly practical but always together with preliminary strategic
considerations). Just let me know.

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Fri, Dec 04, 2020 at 07:53:12PM +0100, pboy(a)uni-bremen.de wrote:
>  I’m not a maintainer but I use Fedora Server for a lot of our
> university
>  research institutions infrastructure (and I’m a dormant member of Fedora
>  docs).
>  
>  Just in case it is indeed considered useful and desirable I could
>  contribute various Fedora Server related/specific documentations and
>  how-to's, e.g. an annotated step-by-step guide to setup a basic server
>  which can get extended for various purposes, how to set up a Postgres
>  server on top of a basic server, an infrastructure for vm’s and containers
>  (including scripts and ansible templates), troubleshooting guides, and
>  other topics like that (mostly practical but always together with
>  preliminary strategic considerations). Just let me know. 

Absolutely! A functioning Working Group needs people interested in and doing
these kinds of things too, not just package maintenance. So if you're
interested, you'd absolutely be welcome in a re-constituted Fedora Server
WG.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Josh Boyer]

On Fri, Dec 4, 2020 at 2:33 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Fri, Dec 04, 2020 at 07:53:12PM +0100, pboy(a)uni-bremen.de wrote:
>  > I’m not a maintainer but I use Fedora Server for a lot of our university
>  > research institutions infrastructure (and I’m a dormant member of Fedora
>  > docs).
>  >
>  > Just in case it is indeed considered useful and desirable I could
>  > contribute various Fedora Server related/specific documentations and
>  > how-to's, e.g. an annotated step-by-step guide to setup a basic server
>  > which can get extended for various purposes, how to set up a Postgres
>  > server on top of a basic server, an infrastructure for vm’s and containers
>  > (including scripts and ansible templates), troubleshooting guides, and
>  > other topics like that (mostly practical but always together with
>  > preliminary strategic considerations). Just let me know.
>
>
>  Absolutely! A functioning Working Group needs people interested in and doing
>  these kinds of things too, not just package maintenance. So if you're
>  interested, you'd absolutely be welcome in a re-constituted Fedora Server
>  WG. 
It would be interesting if we had a set of use cases Fedora Server
actually solves.  So far in this thread we've seen people use it, but
it reads to me like they use it to get a boiled down installation of
Fedora.  So is Fedora Server just a convenient way to get a quick and
simple Fedora installation (e.g. you're using it because it's
*Fedora*), or do people actually use it for traditional server use
cases.

For those using it for traditional server use cases, why?  What about
it do you find better than something like CentOS?

josh

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote:
>  It would be interesting if we had a set of use cases Fedora Server
>  actually solves.  So far in this thread we've seen people use it, but
>  it reads to me like they use it to get a boiled down installation of
>  Fedora.  So is Fedora Server just a convenient way to get a quick and
>  simple Fedora installation (e.g. you're using it because it's
>  *Fedora*), or do people actually use it for traditional server use
>  cases.
>  
>  For those using it for traditional server use cases, why?  What about
>  it do you find better than something like CentOS? 
Yeah, this is absolutely another valuable idea. The Use Cases and Personas
at
https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_...
were created *seven* years ago and reflect aspiration, not nessarily
reality. So it would be very valuable for interested people to update that
to reflect both actual current use and the current aspirations.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Stephen John Smoogen]

On Fri, 4 Dec 2020 at 15:17, Matthew Miller <mattdm(a)fedoraproject.org&gt;
wrote:

>  On Fri, Dec 04, 2020 at 02:51:45PM -0500, Josh Boyer wrote:
>  > It would be interesting if we had a set of use cases Fedora Server
>  > actually solves.  So far in this thread we've seen people use it, but
>  > it reads to me like they use it to get a boiled down installation of
>  > Fedora.  So is Fedora Server just a convenient way to get a quick and
>  > simple Fedora installation (e.g. you're using it because it's
>  > *Fedora*), or do people actually use it for traditional server use
>  > cases.
>  >
>  > For those using it for traditional server use cases, why?  What about
>  > it do you find better than something like CentOS?
>
>  Yeah, this is absolutely another valuable idea. The Use Cases and Personas
>  at
>
> https://fedoraproject.org/wiki/Server/Product_Requirements_Document#User_...
>  were created *seven* years ago and reflect aspiration, not nessarily
>  reality. So it would be very valuable for interested people to update that
>  to reflect both actual current use and the current aspirations.
>
>
>  
Anecdata which is as 'useful' as any other.

Most of the people I have dealt with in the last 4 years with Server have
been using it mainly as a replacement for the Everything DVD and because it
was the most 'un-opinionated' release of Fedora. It wasn't actually being
used in any more of a server release as much as a 'get out of my way' while
still using Fedora.

For the people who were using it as servers, it was split between getting
ready for the next RHEL/CentOS they would be deploying, they needed
packages which were not in EPEL, or things like python/nodejs/etc was new
enough for what they needed to run but wasn't in EL8.


>  --
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  

-- 
Stephen J Smoogen.

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Felix Schwarz]

Am 04.12.20 um 21:35 schrieb Stephen John Smoogen:
>  Anecdata which is as 'useful' as any other. 
just some additional experience from my side:
- Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack
   required to run popular PHP applications like WordPress/NextCloud/...
   AFAIK due to modularity and build-only RPMs it is still quite hard (on RHEL 8)
   to get PHP-related rpms required to deploy these PHP applications.
   With Fedora it works like a breeze.

- Fedora works well, no breaking updates in our server use

- also a lot of recent tech available: wireguard, systemd daemons

Felix

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Japheth Cleaver]

On 12/4/2020 12:35 PM, Stephen John Smoogen wrote:
>  Anecdata which is as 'useful' as any other.
>
>  Most of the people I have dealt with in the last 4 years with Server 
>  have been using it mainly as a replacement for the Everything DVD and 
>  because it was the most 'un-opinionated' release of Fedora. It wasn't 
>  actually being used in any more of a server release as much as a 'get 
>  out of my way' while still using Fedora.
>
>  For the people who were using it as servers, it was split between 
>  getting ready for the next RHEL/CentOS they would be deploying, they 
>  needed packages which were not in EPEL, or things like 
>  python/nodejs/etc was new enough for what they needed to run but 
>  wasn't in EL8. 
It would be interesting to consider how Fedora Server use cases change 
over time during an EL release cycle.

For many server use cases where the box is NOT ephemeral, when CentOS 
and Fedora are similar, it's likely that CentOS is going to be a 
better-engineered and tested option. But as time goes on and the next EL 
release isn't either isn't announced or isn't stable enough to rely on, 
Fedora Server probably sees more use as a quasi-stable release base.. 
This fills a real need when your users are absolutely clamoring for 
things that aren't likely to be backported into the stable EL release 
and you don't want to have to send them into Ubuntu/Debian land (or have 
them grab an un-administered container off the shelf).

In fact, Fedora Server as a "not EL, but better than nothing as a 
temporarily stable platform" during these later periods could be a 
useful niche to fill. Bonus points for some of those extended support 
duration/stable discussions from a few years ago.

Ultimately, however, I feel like the use case of Fedora Server is 
inexorably tied to the RHEL/CentOS (or CentOS Stream) discussions. And a 
Fedora WG that tries to do long-term planning and positioning needs to 
be part of those overall discussions for the greater good of the RedHat 
ecosystem. Short term marketing is fine, but the different sides of 
RedHat need to be on the same page about this all.

-jc

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote:
>  be a better-engineered and tested option. But as time goes on and
>  the next EL release isn't either isn't announced or isn't stable
>  enough to rely on, Fedora Server probably sees more use as a
>  quasi-stable release base.. This fills a real need when your users
>  are absolutely clamoring for things that aren't likely to be
>  backported into the stable EL release and you don't want to have to
>  send them into Ubuntu/Debian land (or have them grab an
>  un-administered container off the shelf). 
Yeah, we may have an opportunity to do this better with CentOS Stream.
Starting with RHEL 8, there's no more "next EL isn't announced" --
instead,
they're every three years. So, we know when Fedora ELN is going to flow into
CentOS Stream and from there to RHEL. We could actually position and label
each Fedora Server release by where it fits on the wave of that cadence.




-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Ken Dreyer]

On Fri, Dec 4, 2020, 3:25 PM Matthew Miller <mattdm(a)fedoraproject.org
>  
wrote:

>  On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote:
>  > be a better-engineered and tested option. But as time goes on and
>  > the next EL release isn't either isn't announced or isn't stable
>  > enough to rely on, Fedora Server probably sees more use as a
>  > quasi-stable release base.. This fills a real need when your users
>  > are absolutely clamoring for things that aren't likely to be
>  > backported into the stable EL release and you don't want to have to
>  > send them into Ubuntu/Debian land (or have them grab an
>  > un-administered container off the shelf).
>
>  Yeah, we may have an opportunity to do this better with CentOS Stream.
>  Starting with RHEL 8, there's no more "next EL isn't announced" --
> instead,
>  they're every three years. So, we know when Fedora ELN is going to flow
>  into
>  CentOS Stream and from there to RHEL. We could actually position and label
>  each Fedora Server release by where it fits on the wave of that cadence.
>  
It's too early to say that this hypothetical workflow is a replacement for
Fedora. Things still show up in RHEL 8 ahead of CentOS Stream.

A strong Fedora Server edition means a strong RHEL Server.

- Ken

>

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Mon, Dec 07, 2020 at 08:44:37AM -0700, Ken Dreyer wrote:
>  It's too early to say that this hypothetical workflow is a
> replacement for
>  Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. 
I don't suggest that it's a replacement, but it can be complementary.

>  
>  A strong Fedora Server edition means a strong RHEL Server. 
Absolutely!

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

>  Am 04.12.2020 um 23:16 schrieb Japheth Cleaver
> <cleaver(a)terabithia.org&gt;:
>  
>  On 12/4/2020 12:35 PM, Stephen John Smoogen wrote:
> > 
> > ... 
> > 
> > For the people who were using it as servers, it was split between getting ready for
> the next RHEL/CentOS they would be deploying, they needed packages which were not in EPEL,
> or things like python/nodejs/etc was new enough for what they needed to run but wasn't
> in EL8.
> > 
>  It would be interesting to consider how Fedora Server use cases change over time during
> an EL release cycle.
>  
>  For many server use cases where the box is NOT ephemeral, when CentOS and Fedora are
> similar, it's likely that CentOS is going to be a better-engineered and tested option.
> But as time goes on and the next EL release isn't either isn't announced or
> isn't stable enough to rely on, Fedora Server probably sees more use as a quasi-stable
> release base.. This fills a real need when your users are absolutely clamoring for things
> that aren't likely to be       backported into the stable EL release and you don't
> want to have to send them into Ubuntu/Debian land (or have them grab an un-administered
> container off the shelf). 
Fedora has advantages not only when RHELx / CentOSx is matured, but in some cases already
at release time, when some important components are already „behind“, e.g. postfix /
dovecot with CentOS 8 regarding SNI and submission (which are quite important features in
a containerised world). And with the current rapid development, even small version
differences can be important.

>  In fact, Fedora Server as a "not EL, but better than nothing as
> a temporarily stable platform" during these later periods could be a useful niche to
> fill. Bonus points for some of those extended support duration/stable discussions from a
> few years ago. 

I see advantages sui generis in Fedora Server over CentOS, not "just" an interim
solution or workaround until the next CentOS version is released. You get (almost) all the
positive features that make CentOS /RHEL stand out (well thought-out architecture and
workflows, security, systematic tools, etc.) and additionally
- more up-to-date application software, which often enables a better response to current
developments and changing requirements
- easier administration due to a greater variety of available packages
- shorter release jumps, which are therefore less disruptive 
- easier (quasi rolling) updates (dnf update), which save a lot of time
- Freedom from strict RH feature management (example BTRFS, XEN some years ago)
- greater backwards hardware compatibility (e.g. exclusion of drivers in el 8, which make
some older hardware unusable or only very difficult to use)

The list can easily be extended.


--
Dr. Peter Boy
pb(a)boy-digital.de
pboy(a)uni-bremen.de

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[James Szinger]

On Sat, 5 Dec 2020 01:24:22 +0100
pboy(a)uni-bremen.de wrote:

>  I see advantages sui generis in Fedora Server over CentOS, not
> "just"
>  an interim solution or workaround until the next CentOS version is
>  released. You get (almost) all the positive features that make CentOS
>  /RHEL stand out (well thought-out architecture and workflows,
>  security, systematic tools, etc.) and additionally
>  - more up-to-date application software, which often enables a better
>  response to current developments and changing requirements
>  - easier administration due to a greater variety of available packages
>  - shorter release jumps, which are therefore less disruptive 
>  - easier (quasi rolling) updates (dnf update), which save a lot of
>  time
>  - Freedom from strict RH feature management (example BTRFS, XEN some
>  years ago)
>  - greater backwards hardware compatibility (e.g. exclusion of drivers
>  in el 8, which make some older hardware unusable or only very
>  difficult to use)
>  
>  The list can easily be extended. 
I totally agree.  I used to use CentOS for server applications, but
with the release of RHEL/CentOS 8, I’ve been moving toward Fedora.

Undelivered -devel packages and modularity are killer anti-features of
EL 8—it is way too hard to build the software I need.  Whereas Fedora
packages much more software, so I spend less time building
dependencies, and the tooling is there to build what I need.  With
Fedora my salary goes more to adding value and less on reinventing the
wheel.

I don’t use Fedora Server directly.  Instead I build container or VMs
with a custom RPM set.  The existence of Fedora Server Edition
provides confidence that Fedora is a suitable and tested platform for
server applications.

Jim

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Michael Catanzaro]

On Sat, Dec 5, 2020 at 7:33 am, James Szinger <jszinger(a)gmail.com&gt; 
wrote:
>  Undelivered -devel packages and modularity are killer anti-features
> of
>  EL 8—it is way too hard to build the software I need. 
Honestly I don't think modularity is a serious problem for end users. 
Missing -devel packages is unbelievably frustrating, though. And EPEL 
just doesn't contain as much as Fedora does, in general.

So for personal servers... well, I've never seen Fedora Server broken 
by automatic updates. I don't think I would use Fedora Server for 
critical business infrastructure, but it works well enough for my 
personal needs. The odds of encountering problems with Fedora are 
simply way lower than the odds of discovering that EPEL lacks something 
that I want, or an essential -devel package that doesn't exist.

Michael

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[James Szinger]

On Mon, 07 Dec 2020 10:21:35 -0600
Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote:

>  On Sat, Dec 5, 2020 at 7:33 am, James Szinger
> <jszinger(a)gmail.com&gt; 
>  wrote:
>  > Undelivered -devel packages and modularity are killer anti-features
>  > of EL 8—it is way too hard to build the software I need.  
>  
>  Honestly I don't think modularity is a serious problem for end users. 
>  Missing -devel packages is unbelievably frustrating, though. And EPEL 
>  just doesn't contain as much as Fedora does, in general. 
I find the modularity end-user documentation to be woefully
inadequate, especially for developers.

>  So for personal servers... well, I've never seen Fedora Server
> broken 
>  by automatic updates. I don't think I would use Fedora Server for 
>  critical business infrastructure, but it works well enough for my 
>  personal needs. The odds of encountering problems with Fedora are 
>  simply way lower than the odds of discovering that EPEL lacks
>  something that I want, or an essential -devel package that doesn't
>  exist. 
I have found updates to Fedora server software to be less disruptive
than the desktop updates.  I also find many small updates easier to
manage than a few big updates.  Our sysadmin at work spent most of
2020 updating the server fleet from CentOS 6 to CentOS 8.  My software
was easy to deal with since I develop and test on Fedora.  A good test
suite is essential.

Jim

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Tue, Dec 08, 2020 at 08:02:01AM -0700, James Szinger wrote:
>  I find the modularity end-user documentation to be woefully
>  inadequate, especially for developers. 
Is there a particular part of the documentation you're struggling with, or
something specifically you find missing? I don't mean to be snarky, but I
heard a lot of this complaint at the last DevConf.cz, and then when the
things mentioned were checked out, they actually _are_ covered pretty nicely
in the https://docs.fedoraproject.org/en-US/modularity/ docs.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[James Szinger]

On Tue, 8 Dec 2020 17:18:24 -0500
Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  On Tue, Dec 08, 2020 at 08:02:01AM -0700, James Szinger wrote:
>  > I find the modularity end-user documentation to be woefully
>  > inadequate, especially for developers.  
>  
>  Is there a particular part of the documentation you're struggling
>  with, or something specifically you find missing? I don't mean to be
>  snarky, but I heard a lot of this complaint at the last DevConf.cz,
>  and then when the things mentioned were checked out, they actually
>  _are_ covered pretty nicely in the
>  https://docs.fedoraproject.org/en-US/modularity/ docs. 
Here are several basic to advanced question that I can’t see answers
for on that page.  All of this is from the perspective of a user of
Fedora or EL, installing and building software for my own use.  That
page seems aimed at those developing Fedora and using the Fedora build
system.

What modules are available, what are they for, and what’s in them?

What streams are available, what are they for, and what’s in them?
(https://docs.fedoraproject.org/en-US/modularity/using-modules-switching-s...
says “This page needs to be extended.”)

What profiles are available, what are they for, and what’s in them?

`yum module info` seems to be part of the answer, but it is not in
that doc.

I have an RPM installed.  Which module and stream is it from?  Do
other modules also provide it?  The same version or different?

What is the modularity equivalent of `yum provides`?

I am trying to build an RPM that BuildRequires something from a
module.  How do I get mock to do this?  What if some of the
BuildRequires are private or hidden?

I am trying to build an RPM that Requires something from a module.
How do I make yum automatically install the correct dependency?

I want to provide modules in my private repository.  How do I set this
up for building and distribution?

https://docs.fedoraproject.org/en-US/modularity/references/ has a link
to https://pagure.io/modulemd which has a link to the modulemd
specification at
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml
which throws a 404.

Jim

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Ken Dreyer]

On Tue, Dec 8, 2020, 3:18 PM Matthew Miller <mattdm(a)fedoraproject.org
>  
wrote:

>  On Tue, Dec 08, 2020 at 08:02:01AM -0700, James Szinger wrote:
>  > I find the modularity end-user documentation to be woefully
>  > inadequate, especially for developers.
>
>  Is there a particular part of the documentation you're struggling with, or
>  something specifically you find missing? I don't mean to be snarky, but I
>  heard a lot of this complaint at the last DevConf.cz, and then when the
>  things mentioned were checked out, they actually _are_ covered pretty
>  nicely
>  in the https://docs.fedoraproject.org/en-US/modularity/ docs.
>  

Hi Matt, I opened https://pagure.io/fedora-docs/modularity/issue/74 about
the docs.

We're still using "calc" in the examples, and "lorim ipsum", etc.

Which module in Fedora today is the best example of modularity? That one
would be a good one to use in the docs.

>

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Thu, Dec 10, 2020 at 10:36:39AM -0700, Ken Dreyer wrote:
>  We're still using "calc" in the examples, and
> "lorim ipsum", etc. 
LOL. That's because of me. And no, I don't. For one thing, calc upstream
development has pretty much stopped rendering the example moot.

Thanks for filing this, and I'll highlight it for the modularity team's
attention.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Ken Dreyer]

On Thu, Dec 10, 2020 at 12:52 PM Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  Thanks for filing this, and I'll highlight it for the modularity
> team's
>  attention. 
Thanks. I also filed https://pagure.io/fm-orchestrator/issue/1629 a
while back. I think this could help users understand MBS a bit better.

- Ken

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[James Szinger]

On Tue, 8 Dec 2020 17:18:24 -0500
Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:

>  Is there a particular part of the documentation you're
> struggling
>  with, or something specifically you find missing? I don't mean to be
>  snarky, but I heard a lot of this complaint at the last DevConf.cz,
>  and then when the things mentioned were checked out, they actually
>  _are_ covered pretty nicely in the
>  https://docs.fedoraproject.org/en-US/modularity/ docs. 
The modularity docs do not even begin to address how to resolve the
following:

$ podman run --rm -it registry.centos.org/centos:8 bash
[root@ad899f6f999b /]# yum module enable perl:5.30 postgresql:12
Failed to set locale, defaulting to C.UTF-8
CentOS-8 - AppStream                            665 kB/s | 6.2 MB     00:09    
CentOS-8 - Base                                 1.8 MB/s | 2.3 MB     00:01    
CentOS-8 - Extras                                22 kB/s | 8.1 kB     00:00    
Problems in request:
Modular dependency problems with Defaults:

 Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
  - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - conflicting requests
Dependencies resolved.
================================================================================
 Package           Architecture     Version             Repository         Size
================================================================================
Enabling module streams:
 perl                               5.30                                       
 postgresql                         12                                         

Transaction Summary
================================================================================

Is this ok [y/N]: y
Complete!
[root@ad899f6f999b /]# yum module install perl-DBD-Pg
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:00:49 ago on Thu Dec 10 20:46:36 2020.
Modular dependency problem:

 Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
  - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - conflicting requests
All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7' are not
active
Error: Problems in request:
broken groups or modules: perl-DBD-Pg
Modular dependency problems:

 Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
  - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - conflicting requests
[root@ad899f6f999b /]# 

How do I get Perl 5.30, PostgreSQL 12 and the DBD::Pg that works with
them?

Jim

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Petr Šabata]

On Thu, Dec 10, 2020 at 9:55 PM James Szinger <jszinger(a)gmail.com&gt; wrote:
>  On Tue, 8 Dec 2020 17:18:24 -0500
>  Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>
>  > Is there a particular part of the documentation you're struggling
>  > with, or something specifically you find missing? I don't mean to be
>  > snarky, but I heard a lot of this complaint at the last DevConf.cz,
>  > and then when the things mentioned were checked out, they actually
>  > _are_ covered pretty nicely in the
>  > https://docs.fedoraproject.org/en-US/modularity/ docs.
>
>  The modularity docs do not even begin to address how to resolve the
>  following:
>
>  $ podman run --rm -it registry.centos.org/centos:8 bash
>  [root@ad899f6f999b /]# yum module enable perl:5.30 postgresql:12
>  Failed to set locale, defaulting to C.UTF-8
>  CentOS-8 - AppStream                            665 kB/s | 6.2 MB     00:09
>  CentOS-8 - Base                                 1.8 MB/s | 2.3 MB     00:01
>  CentOS-8 - Extras                                22 kB/s | 8.1 kB     00:00
>  Problems in request:
>  Modular dependency problems with Defaults:
>
>   Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>    - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - conflicting requests
>  Dependencies resolved.
>  ================================================================================
>   Package           Architecture     Version             Repository         Size
>  ================================================================================
>  Enabling module streams:
>   perl                               5.30
>   postgresql                         12
>
>  Transaction Summary
>  ================================================================================
>
>  Is this ok [y/N]: y
>  Complete!
>  [root@ad899f6f999b /]# yum module install perl-DBD-Pg
>  Failed to set locale, defaulting to C.UTF-8
>  Last metadata expiration check: 0:00:49 ago on Thu Dec 10 20:46:36 2020.
>  Modular dependency problem:
>
>   Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>    - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - conflicting requests
>  All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7' are
> not active
>  Error: Problems in request:
>  broken groups or modules: perl-DBD-Pg
>  Modular dependency problems:
>
>   Problem: module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>    - module freeradius:3.0:8030020201104044033:1e4bbb35-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - conflicting requests
>  [root@ad899f6f999b /]#
>
>  How do I get Perl 5.30, PostgreSQL 12 and the DBD::Pg that works with
>  them? 
Disable the freeradius module; it only has a context for the default
perl stream and is blocking the switch.

P

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[James Szinger]

On Thu, 10 Dec 2020 22:10:03 +0100
Petr Šabata <contyk(a)redhat.com&gt; wrote:
>  Disable the freeradius module; it only has a context for the default
>  perl stream and is blocking the switch. 
Still no joy.  By the way, my point here is not to get this working,
but rather to demonstrate the complexity of modularity and the lack of
documentation.

Jim

$ podman run --rm -it registry.centos.org/centos:8 bash
[root@eb931d6dd4b0 /]# yum -y module disable freeradius
Failed to set locale, defaulting to C.UTF-8
CentOS-8 - AppStream                            417 kB/s | 6.2 MB     00:15    
CentOS-8 - Base                                 121 kB/s | 2.3 MB     00:19    
CentOS-8 - Extras                                24 kB/s | 8.1 kB     00:00    
Dependencies resolved.
================================================================================
 Package           Architecture     Version             Repository         Size
================================================================================
Disabling modules:
 freeradius                                                                    

Transaction Summary
================================================================================

Complete!
[root@eb931d6dd4b0 /]# yum -y module enable perl:5.30 postgresql:12 -y
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:00:57 ago on Thu Dec 10 21:51:46 2020.
Problems in request:
Modular dependency problems with Defaults:

 Problem: conflicting requests
  - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
module(perl:5.24), but none of the providers can be installed
  - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
  - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
Dependencies resolved.
================================================================================
 Package           Architecture     Version             Repository         Size
================================================================================
Enabling module streams:
 perl                               5.30                                       
 postgresql                         12                                         

Transaction Summary
================================================================================

Complete!
[root@eb931d6dd4b0 /]# yum -y module install perl-DBD-Pg
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:01:04 ago on Thu Dec 10 21:51:46 2020.
Modular dependency problem:

 Problem: conflicting requests
  - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
module(perl:5.24), but none of the providers can be installed
  - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
  - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7' are not
active
Error: Problems in request:
broken groups or modules: perl-DBD-Pg
Modular dependency problems:

 Problem: conflicting requests
  - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
module(perl:5.24), but none of the providers can be installed
  - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
module(perl:5.26), but none of the providers can be installed
  - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
  - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
  - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
[root@eb931d6dd4b0 /]#

Modularity documentation [was Re: The future of Fedora Server...] Fedora CoreOS a Fedora Edition (System-Wide Change))

[Petr Šabata]

On Thu, Dec 10, 2020 at 11:08 PM James Szinger <jszinger(a)gmail.com&gt; wrote:
>  On Thu, 10 Dec 2020 22:10:03 +0100
>  Petr Šabata <contyk(a)redhat.com&gt; wrote:
>  > Disable the freeradius module; it only has a context for the default
>  > perl stream and is blocking the switch.
>
>  Still no joy.  By the way, my point here is not to get this working,
>  but rather to demonstrate the complexity of modularity and the lack of
>  documentation.
>
>  Jim 
Yes, I get it. And I'm pretty sure perl module switching is covered in
RHEL release docs (I recall reviewing that) as it's a content-specific
problem here. The user interface could always be improved and guide
the user to the correct resolution better in any generic instance of
this situation. Until then, some of these common problems could be
documented upstream, too.

You probably know you have other modules that require not-5.30 streams
of perl enabled then. The message below points at
perl-libwww-perl:6.34.

P

>  $ podman run --rm -it registry.centos.org/centos:8 bash
>  [root@eb931d6dd4b0 /]# yum -y module disable freeradius
>  Failed to set locale, defaulting to C.UTF-8
>  CentOS-8 - AppStream                            417 kB/s | 6.2 MB     00:15
>  CentOS-8 - Base                                 121 kB/s | 2.3 MB     00:19
>  CentOS-8 - Extras                                24 kB/s | 8.1 kB     00:00
>  Dependencies resolved.
>  ================================================================================
>   Package           Architecture     Version             Repository         Size
>  ================================================================================
>  Disabling modules:
>   freeradius
>
>  Transaction Summary
>  ================================================================================
>
>  Complete!
>  [root@eb931d6dd4b0 /]# yum -y module enable perl:5.30 postgresql:12 -y
>  Failed to set locale, defaulting to C.UTF-8
>  Last metadata expiration check: 0:00:57 ago on Thu Dec 10 21:51:46 2020.
>  Problems in request:
>  Modular dependency problems with Defaults:
>
>   Problem: conflicting requests
>    - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
> module(perl:5.24), but none of the providers can be installed
>    - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
>    - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>  Dependencies resolved.
>  ================================================================================
>   Package           Architecture     Version             Repository         Size
>  ================================================================================
>  Enabling module streams:
>   perl                               5.30
>   postgresql                         12
>
>  Transaction Summary
>  ================================================================================
>
>  Complete!
>  [root@eb931d6dd4b0 /]# yum -y module install perl-DBD-Pg
>  Failed to set locale, defaulting to C.UTF-8
>  Last metadata expiration check: 0:01:04 ago on Thu Dec 10 21:51:46 2020.
>  Modular dependency problem:
>
>   Problem: conflicting requests
>    - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
> module(perl:5.24), but none of the providers can be installed
>    - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
>    - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>  All matches for argument 'perl-DBD-Pg' in module 'perl-DBD-Pg:3.7' are
> not active
>  Error: Problems in request:
>  broken groups or modules: perl-DBD-Pg
>  Modular dependency problems:
>
>   Problem: conflicting requests
>    - module perl-libwww-perl:6.34:8030020200716155257:7cc0a66d-0.x86_64 requires
> module(perl:5.24), but none of the providers can be installed
>    - module perl-libwww-perl:6.34:8030020200716155257:b967a9a2-0.x86_64 requires
> module(perl:5.26), but none of the providers can be installed
>    - module perl:5.24:8010020191114034134:3af8e029-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.24) provided by perl:5.24:8010020191114034134:3af8e029-0.x86_64
>    - module perl:5.26:8000020190628020724:55190bc5-0.x86_64 conflicts with
> module(perl:5.30) provided by perl:5.30:8030020200715145239:568f3a16-0.x86_64
>    - module perl:5.30:8030020200715145239:568f3a16-0.x86_64 conflicts with
> module(perl:5.26) provided by perl:5.26:8000020190628020724:55190bc5-0.x86_64
>  [root@eb931d6dd4b0 /]#
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Dominik 'Rathann' Mierzejewski]

On Friday, 04 December 2020 at 20:51, Josh Boyer wrote:
[...]
>  For those using it for traditional server use cases, why?  What
> about
>  it do you find better than something like CentOS? 
Here are my reasons, in no particular order:
1. Because that's what I use on my desktops.
2. Because latest software versions.
3. Because I don't have to maintain all the packages I'm interested in
for EPEL, too.
4. Because it works so well.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

>  Am 04.12.2020 um 20:33 schrieb Matthew Miller
> <mattdm(a)fedoraproject.org&gt;:
>  
>  On Fri, Dec 04, 2020 at 07:53:12PM +0100, pboy(a)uni-bremen.de wrote:
> > Just in case it is indeed considered useful and desirable I could
> > contribute various Fedora Server related/specific documentations and
> > how-to's, e.g. an annotated step-by-step guide to setup a basic server
> > which can get extended for various purposes, how to set up a Postgres
> > server on top of a basic server, an infrastructure for vm’s and containers
> > (including scripts and ansible templates), troubleshooting guides, and
> > other topics like that (mostly practical but always together with
> > preliminary strategic considerations). Just let me know.
>  
>  
>  Absolutely! A functioning Working Group needs people interested in and doing
>  these kinds of things too, not just package maintenance. So if you're
>  interested, you'd absolutely be welcome in a re-constituted Fedora Server
>  WG. 
OK, I would like to participate and contribute to the documentary side.

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

>  Am 04.12.2020 um 20:33 schrieb Matthew Miller
> <mattdm(a)fedoraproject.org&gt;:
>  
> > ...
> > Just in case it is indeed considered useful and desirable I could
> > contribute various Fedora Server related/specific documentations and
> > how-to's, e.g. an annotated step-by-step guide to setup a basic server
> > which can get extended for various purposes, how to set up a Postgres
> > server on top of a basic server, an infrastructure for vm’s and containers
> > (including scripts and ansible templates), troubleshooting guides, and
> > other topics like that (mostly practical but always together with
> > preliminary strategic considerations). Just let me know.
>  
>  
>  Absolutely! A functioning Working Group needs people interested in and doing
>  these kinds of things too, not just package maintenance. So if you're
>  interested, you'd absolutely be welcome in a re-constituted Fedora Server
>  WG. 
Well, where should we discuss further proceedings?  Is it this generic devel list, is it
server(a)lists.fedoraproject.org? Another one? 

First of all we need content, of course, but we also need some planning beforehand. 
- How to set things in motion, 
- where we want which documentation be published (under Releases, Quick Doc, dedicated
area in https://docs.fedoraproject.org/en-US/docs/, or wiki entries at
https://fedoraproject.org/wiki/Fedora_Project_Wiki?rd=Fedora_Project_Wiki/en), 
- where can drafts be discussed before publication, 
- contact with the Doc project

to name but a few.  




>  -- 
>  Matthew Miller
>  <mattdm(a)fedoraproject.org&gt;
>  Fedora Project Leader

The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))

[Matthew Miller]

On Mon, Dec 07, 2020 at 11:41:01AM +0100, pboy(a)uni-bremen.de wrote:
>  Well, where should we discuss further proceedings? Is it this
> generic
>  devel list, is it server(a)lists.fedoraproject.org? Another one? 
Yes, let's take it to that list. Everyone interested, join us over there. :)

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Kaufmann]

Hi!

On Wed, Dec 02, 2020 at 11:11:02AM -0500, Ben Cotton wrote:
>  One uncomfortable question that this raises: is it time to
> de-Edition
>  Fedora Server? 
Please don't, for me it is the Version I'm currently migrating my Centos
7 boxes to, so having it properly tested and being high on the "if it
breaks it needs to be fixed"-list is kinda important for me.

>  As far as I can tell, the Server Working Group has essentially been
>  dormant for a while, with sgallagh coming in to fix issues when they
>  arise. So one alternative to demoting Server would be for someone to
>  revive that WG. 
Count me in, but honestly I don't see a lot of things that need to be
changed - I'm quite happy with how it behaves. But aside that I'm happy
to help with those issues that come up.

All the best,
Astra

[Matthew Miller]

On Wed, Dec 02, 2020 at 10:59:50PM +0100, David Kaufmann wrote:
>  Count me in, but honestly I don't see a lot of things that need
> to be
>  changed - I'm quite happy with how it behaves. But aside that I'm happy
>  to help with those issues that come up. 
That would be amazing! In order for it to remain as an edition, we (speaking
generally for the Council) like to see regular meetings -- at least monthly.
There are two open issues in the tracker at
https://pagure.io/fedora-server/issues, and even if it's not ever a flood of
things just making sure they're looked at helps keep things going.

That plus status updates on
https://docs.fedoraproject.org/en-US/project/dashboard/ regularly. And of
course people showing up to help with issues at release time.

One outstanding thing that could be worked on is the merger of the Fedora
Cloud Base image and Fedora Server. We agreed that this should be done
several Flocks ago, but no one has had time to actually make it happen.

There was also talk of working more closely with Ansible on system roles.
I'd love to see that revived too! There is also potential for greater
collaboration with CentOS and the CentOS Stream project. I'd love to have a
clear, non-competitive answer for each of these projects on when one should
use what.

And, of course, there's helping develop marketing materials for Mindshare
groups to use to help the Edition grow more users.

But none of these latter things are _necessary_. It's really the first thing
of just reviving the cadence of meetings and status updates.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[David Kaufmann]

On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote:
>  That would be amazing! In order for it to remain as an edition, we
> (speaking
>  generally for the Council) like to see regular meetings -- at least monthly. 
I'll check the situation there - if there are more people interested in
a meeting I'll definitely join. There is a set date currently, I can
make that next week I think and for now I'll just use that one.

>  There are two open issues in the tracker at
>  https://pagure.io/fedora-server/issues, and even if it's not ever a flood of
>  things just making sure they're looked at helps keep things going. 
It seems to me that both can be closed:
- #4: the image target size seems to be fine (not whats in the ticket,
  but the image also matches those sizes)
- #5: this seems to be in the wrong group - it looks like it belongs to
  pagure.io/cloud-sig

>  […] 
>  One outstanding thing that could be worked on is the merger of the
> Fedora
>  Cloud Base image and Fedora Server. We agreed that this should be done
>  several Flocks ago, but no one has had time to actually make it happen. 
Until now I thought of both as having a very different target audience,
I've never looked at Cloud Base, as I almost completely self-host.
I don't really understand why it should be merged, is there some
document or chat log for that?

>  There was also talk of working more closely with Ansible on system
> roles.
>  I'd love to see that revived too! There is also potential for greater
>  collaboration with CentOS and the CentOS Stream project. I'd love to have a
>  clear, non-competitive answer for each of these projects on when one should
>  use what. 
Same as above, I'd like to read up on that. I'm not sure what "system
roles" relate to, I've found linux-system-roles.github.io and I know
a big chunk of fedora-infra systems is managed using ansible.

All the best,
Astra

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Christopher Engelhard]

On 2020-12-03 09:31, David Kaufmann wrote:
>  On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote:
> > That would be amazing! In order for it to remain as an edition, we 
> > (speaking
> > generally for the Council) like to see regular meetings -- at least 
> > monthly.
>  
>  I'll check the situation there - if there are more people interested in
>  a meeting I'll definitely join. There is a set date currently, I can
>  make that next week I think and for now I'll just use that one. 
I'd definitely be interested as well.

> > One outstanding thing that could be worked on is the merger of
> the 
> > Fedora
> > Cloud Base image and Fedora Server. We agreed that this should be done
> > several Flocks ago, but no one has had time to actually make it 
> > happen.
>  
>  Until now I thought of both as having a very different target audience,
>  I've never looked at Cloud Base, as I almost completely self-host.
>  I don't really understand why it should be merged, is there some
>  document or chat log for that? 
I have no inside knowledge on this, so these are just my thoughts:
I'd say the cloud & server editions actually do very similar things - 
I'd expect that the Fedora Cloud images get most use as a server of some 
kind. From a user perspective, if I fired up a Fedora Cloud image on 
AWS, I'd expect it to look pretty much like a (maybe pared down?) Fedora 
Server Edition. One has anaconda, the other cloud-init (or whatever AWS 
uses), but otherwise more or less the same system. Ideally, I would like 
to be presented with more or less the same system regardless of whether 
I'm on AWS, DO, linode, ... or bare metal.

> > There was also talk of working more closely with Ansible on
> system 
> > roles.
> > I'd love to see that revived too! There is also potential for greater
> > collaboration with CentOS and the CentOS Stream project. I'd love to 
> > have a
> > clear, non-competitive answer for each of these projects on when one 
> > should
> > use what.
>  
>  Same as above, I'd like to read up on that. I'm not sure what "system
>  roles" relate to, I've found linux-system-roles.github.io and I know
>  a big chunk of fedora-infra systems is managed using ansible. 
Again, just my thoughts. This would go very much in the 'discuss what do 
we want the edition to be' pile. That said, all editions sort of decide 
how the user will by default interact with them. Workstation assumes the 
user will manage the system via the DE for obvious reasons, CoreOS 
assumes that the user will be managing the system via container tools, 
Fedora Server assumes the user will monitor the system via Cockpit, and 
actually manage it via .... poking around in config files.
So one could think about making Ansible the central configuration tool 
for Fedora Server, just like Cockpit is its central monitoring tool:

Workstation = general purpose workstation use, managed & monitored via 
the DE
CoreOS = general purpose container/kubernetes use, managed & monitored 
via those tools
Server = general purpose non-container server use, managed & monitored 
via cockpit & ansible

Not sure how feasible that is, but I can see the reasoning (full 
disclosure, I love ansible, so I'm in no way impartial here).


Christopher

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Kevin Fenzi]

On Thu, Dec 03, 2020 at 10:29:11AM +0100, Christopher Engelhard wrote:
>  On 2020-12-03 09:31, David Kaufmann wrote:
>  > On Wed, Dec 02, 2020 at 06:11:09PM -0500, Matthew Miller wrote:
>  > > That would be amazing! In order for it to remain as an edition, we
>  > > (speaking
>  > > generally for the Council) like to see regular meetings -- at least
>  > > monthly.
>  > 
>  > I'll check the situation there - if there are more people interested in
>  > a meeting I'll definitely join. There is a set date currently, I can
>  > make that next week I think and for now I'll just use that one.
>  
>  I'd definitely be interested as well. 
So, the problem here is that without some kind of goal or activities it
becomes really hard to meet just to show you exist. 

There's not too many things for a server working group to do these days.
;( 

>  > > One outstanding thing that could be worked on is the merger
> of the
>  > > Fedora
>  > > Cloud Base image and Fedora Server. We agreed that this should be done
>  > > several Flocks ago, but no one has had time to actually make it
>  > > happen.
>  > 
>  > Until now I thought of both as having a very different target audience,
>  > I've never looked at Cloud Base, as I almost completely self-host.
>  > I don't really understand why it should be merged, is there some
>  > document or chat log for that?
>  
>  I have no inside knowledge on this, so these are just my thoughts:
>  I'd say the cloud & server editions actually do very similar things - I'd
>  expect that the Fedora Cloud images get most use as a server of some kind.
>  From a user perspective, if I fired up a Fedora Cloud image on AWS, I'd
>  expect it to look pretty much like a (maybe pared down?) Fedora Server
>  Edition. One has anaconda, the other cloud-init (or whatever AWS uses), but
>  otherwise more or less the same system. Ideally, I would like to be
>  presented with more or less the same system regardless of whether I'm on
>  AWS, DO, linode, ... or bare metal. 
I suppose we could look into this, but it seems kind of complementary to
me:

Server: a install dvd, pxe/netboot
Cloud: a runnable image

Are folks wanting to drop the dvd and netinstall?
Or just market the Cloud image more to server admins that want a ready
to run image?

>  > > There was also talk of working more closely with Ansible on
> system
>  > > roles.
>  > > I'd love to see that revived too! There is also potential for greater
>  > > collaboration with CentOS and the CentOS Stream project. I'd love to
>  > > have a
>  > > clear, non-competitive answer for each of these projects on when one
>  > > should
>  > > use what.
>  > 
>  > Same as above, I'd like to read up on that. I'm not sure what "system
>  > roles" relate to, I've found linux-system-roles.github.io and I know
>  > a big chunk of fedora-infra systems is managed using ansible.
>  
>  Again, just my thoughts. This would go very much in the 'discuss what do we
>  want the edition to be' pile. That said, all editions sort of decide how the
>  user will by default interact with them. Workstation assumes the user will
>  manage the system via the DE for obvious reasons, CoreOS assumes that the
>  user will be managing the system via container tools, Fedora Server assumes
>  the user will monitor the system via Cockpit, and actually manage it via
>  .... poking around in config files.
>  So one could think about making Ansible the central configuration tool for
>  Fedora Server, just like Cockpit is its central monitoring tool:
>  
>  Workstation = general purpose workstation use, managed & monitored via the
>  DE
>  CoreOS = general purpose container/kubernetes use, managed & monitored via
>  those tools
>  Server = general purpose non-container server use, managed & monitored via
>  cockpit & ansible
>  
>  Not sure how feasible that is, but I can see the reasoning (full disclosure,
>  I love ansible, so I'm in no way impartial here). 
The linux-system-roles is it's own project... so I am not sure what the
working group would do here? Help them?

kevin

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Matthew Miller]

On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote:
>  I suppose we could look into this, but it seems kind of complementary
> to
>  me:
>  Server: a install dvd, pxe/netboot
>  Cloud: a runnable image
>  Are folks wanting to drop the dvd and netinstall?
>  Or just market the Cloud image more to server admins that want a ready
>  to run image? 
Mostly the latter. I don't even really care if they end up keeping the
distinct os-release and etc.


>  The linux-system-roles is it's own project... so I am not sure
> what the
>  working group would do here? Help them? 
Help them, and help make it feel like a primary feature of Fedora Server.
Right now, our marketing materials at https://getfedora.org/en/server/
highlight:

* modularity
* cockpit
* FreeIPA

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Alexander Bokovoy]

On to, 03 joulu 2020, Matthew Miller wrote:
> On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote:
> > I suppose we could look into this, but it seems kind of complementary to
> > me:
> > Server: a install dvd, pxe/netboot
> > Cloud: a runnable image
> > Are folks wanting to drop the dvd and netinstall?
> > Or just market the Cloud image more to server admins that want a ready
> > to run image?
>
> Mostly the latter. I don't even really care if they end up keeping the
> distinct os-release and etc. 
I do care about being able to deploy from DVD or pxe/netboot. For home
environments cloud images are not everything you need, especially for
home infrastructure. FreeIPA on Fedora is one of practical home
infrastructure deployment targets.

> > The linux-system-roles is it's own project... so I am not
> sure what the
> > working group would do here? Help them?
>
> Help them, and help make it feel like a primary feature of Fedora Server.
> Right now, our marketing materials at https://getfedora.org/en/server/
> highlight:
>
> * modularity
> * cockpit
> * FreeIPA 



-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Matthew Miller]

On Thu, Dec 03, 2020 at 09:35:02PM +0200, Alexander Bokovoy wrote:
>  >>Server: a install dvd, pxe/netboot
>  >>Cloud: a runnable image
>  >>Are folks wanting to drop the dvd and netinstall?
>  >>Or just market the Cloud image more to server admins that want a ready
>  >>to run image?
>  >
>  >Mostly the latter. I don't even really care if they end up keeping the
>  >distinct os-release and etc.
>  
>  I do care about being able to deploy from DVD or pxe/netboot. For home
>  environments cloud images are not everything you need, especially for
>  home infrastructure. FreeIPA on Fedora is one of practical home
>  infrastructure deployment targets. 

Right, let me be clear: I think we need all of these things, and I think
it's best if we have one Edition that covers the different deployment
scenarios.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

>  Am 03.12.2020 um 20:35 schrieb Alexander Bokovoy
> <abokovoy(a)redhat.com&gt;:
>  
>  On to, 03 joulu 2020, Matthew Miller wrote:
> > On Thu, Dec 03, 2020 at 10:53:39AM -0800, Kevin Fenzi wrote:
> >> I suppose we could look into this, but it seems kind of complementary to
> >> me:
> >> Server: a install dvd, pxe/netboot
> >> Cloud: a runnable image
> >> Are folks wanting to drop the dvd and netinstall?
> >> Or just market the Cloud image more to server admins that want a ready
> >> to run image?
> > 
> > Mostly the latter. I don't even really care if they end up keeping the
> > distinct os-release and etc.
>  
>  I do care about being able to deploy from DVD or pxe/netboot. For home
>  environments cloud images are not everything you need, especially for
>  home infrastructure. FreeIPA on Fedora is one of practical home
>  infrastructure deployment targets. 
Hot only home environments! At least very many companies of all sizes have local server
infrastructure and many cannot or do not want to rely on the cloud alone. I very much hope
that the Fedora project does not fall for hype.

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Miroslav Suchý]

Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a):
>  Mostly the latter. I don't even really care if they end up
> keeping the
>  distinct os-release and etc. 
Is this backed by some numbers and analysis?

My personal usage is that I create **hundred thousands** VM from Fedora cloud image per
year.
And I use one or two netinstall images to deploy new home server for me or friend.
And one or two runnable images when I persuade someone to try Fedora.

Cloud image clearly wins the number by orders of magnitude. But without the later we do
not get the penetration and new
users. And no one willing to use cloud images.


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

Future of Fedora Server Edition [was: Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Samuel Sieb]

On 12/3/20 1:01 PM, Miroslav Suchý wrote:
>  Dne 03. 12. 20 v 20:02 Matthew Miller napsal(a):
> > Mostly the latter. I don't even really care if they end up keeping the
> > distinct os-release and etc.
>  
>  Is this backed by some numbers and analysis?
>  
>  My personal usage is that I create **hundred thousands** VM from Fedora cloud image per
> year.
>  And I use one or two netinstall images to deploy new home server for me or friend.
>  And one or two runnable images when I persuade someone to try Fedora.
>  
>  Cloud image clearly wins the number by orders of magnitude. But without the later we do
> not get the penetration and new
>  users. And no one willing to use cloud images. 
I think you snipped too much and misunderstood the meaning.  My 
understanding is that Matthew is suggesting to merge the cloud and 
server editions into one thing and there doesn't need to be a distinct 
os-release for both of them.  e.g. the "cloud" has the "server" 
os-release and is just a differently packaged version of the server 
edition.  He's not saying that one or the other will go away.  There 
just needs to be different marketing of the cloud packaged server edition.

[Matthew Miller]

On Thu, Dec 03, 2020 at 09:31:43AM +0100, David Kaufmann wrote:
>  Until now I thought of both as having a very different target
> audience,
>  I've never looked at Cloud Base, as I almost completely self-host.
>  I don't really understand why it should be merged, is there some
>  document or chat log for that? 
Possibly, but it's not very long so I'll just summarize. The basics are:

When we came up with this split at Flock Charleston in 2013, the idea was to
focus as you say on different target audiences. We envisioned the cloud
image getting more cloud-specific, and Fedora Server getting a bunch of
features like Server Roles which people who wanted a lightweight
cloud-focused base wouldn't necessarily care for.

Over time, it's evolved so Fedora CoreOS fills the new-way-of-doing-things
container-focused world niche, but people still wanted the more-traditional
Fedora Cloud Base to build on. Meanwhile, people mostly aren't using the
Server Roles in their various attempted incarnations, and are just using it
as a base system to build their own local solutions.

So, we've ended up with two things which are basically used in the same way,
with "where it's deployed" being the main differentiator. It makes more
sense to merge them together into one thing that can be deployed in
different places.

Also, both the Cloud SIG and Server SIG have been under-staffed (with the
attention on CoreOS and ... not Server, generally). So, rather than having
two groups each with one or two struggling members, it seems better to have
a shared group with two or four less-struggling members. :)


>  Same as above, I'd like to read up on that. I'm not sure what
> "system
>  roles" relate to, I've found linux-system-roles.github.io and I know
>  a big chunk of fedora-infra systems is managed using ansible. 

Here's a pretty good blog post on thoughts from a few years ago:
https://sgallagh.wordpress.com/2016/10/13/fedora-server-expanding-through...

And the System Roles project:

  https://linux-system-roles.github.io/

and docs for System Roles in RHEL, which nominally this should be the
upstream for:

  https://access.redhat.com/articles/3050101



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
>  
>  == How To Test ==
>  See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
>  
>  We also have regular tests days, for example
>  https://fedoramagazine.org/fedora-coreos-test-day/ 
So...yeah, that's not really enough to call something a Fedora Edition
:)

I think this has a lot of the issues we had with IoT, but turned up to
11.

We have an entire process for releasing a thing called "Fedora" which
is based around the idea that all the bits that make up a "Fedora
release" get built, tested, and signed off together.

IoT stretched this process a bit, because it's not actually built as
part of the same composes as all the other "Fedora" bits. So we had to
implement an entire parallel validation process just for IoT composes.
But at least it's built *the same way* as Fedora, so we could more or
less just split existing things into two paths and use them, which is
what we did. We now have both mainline and IoT composes and validation
events. Even there, the process wasn't perfect for Fedora 33; if you
look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
to be where we go over the status of the bits-to-be-released in great
detail and decide whether to sign them off, there is precisely one line
about IoT:

17:58:36 <pwhalen> IoT is also covered -
https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_G...

...no-one else said a word about it. So yeah, we clearly don't have
this whole "releasing from multiple streams" entirely down yet.

CoreOS is going to be the same only worse, because it's not even built
the same way as the rest of Fedora. It's not built by Pungi, we don't
get the same messages published when CoreOS builds happen (we don't get
messages published at all, IIRC), the metadata for CoreOS builds is not
in productmd[2] form like the metadata for Pungi builds, the whole
process is entirely different.

So to boil this down into a representative question: when we are doing
the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
whether to release "Fedora CoreOS 34"?

What does the question "is Fedora CoreOS 34 ready to go" even mean, in
the context of how CoreOS is built and released? What set of bits will
we be deciding to ship or not ship, and how will that have been decided
and communicated? Where will we look to find the test results and
criteria on which we would base that decision?

Are any of these silly questions, which would indicate that our release
process is based on assumptions which need to be fundamentally re-
examined as part of this Change?

All of this is stuff we could kind of handwave so long as CoreOS wasn't
an official Edition; we could *more or less* leave the CoreOS team to
decide what a CoreOS release looked like and when it would happen and
when it was good enough to ship, and so on.

But if we're going to call it an Edition, which is one of the primary
things that defines what Fedora *is*, I don't think we can do that any
more. We need more groups to think about and decide on the answers to
questions like the above.

[1]:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-fin...
[2]: https://github.com/release-engineering/productmd
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Neal Gompa]

On Wed, Dec 2, 2020 at 12:19 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
>  >
>  > == How To Test ==
>  > See QA test cases : https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
>  >
>  > We also have regular tests days, for example
>  > https://fedoramagazine.org/fedora-coreos-test-day/
>
>  So...yeah, that's not really enough to call something a Fedora Edition
>  :)
>
>  I think this has a lot of the issues we had with IoT, but turned up to
>  11.
>
>  We have an entire process for releasing a thing called "Fedora" which
>  is based around the idea that all the bits that make up a "Fedora
>  release" get built, tested, and signed off together.
>
>  IoT stretched this process a bit, because it's not actually built as
>  part of the same composes as all the other "Fedora" bits. So we had to
>  implement an entire parallel validation process just for IoT composes.
>  But at least it's built *the same way* as Fedora, so we could more or
>  less just split existing things into two paths and use them, which is
>  what we did. We now have both mainline and IoT composes and validation
>  events. Even there, the process wasn't perfect for Fedora 33; if you
>  look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
>  to be where we go over the status of the bits-to-be-released in great
>  detail and decide whether to sign them off, there is precisely one line
>  about IoT:
>
>  17:58:36 <pwhalen> IoT is also covered -
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_G...
>
>  ...no-one else said a word about it. So yeah, we clearly don't have
>  this whole "releasing from multiple streams" entirely down yet.
>
>  CoreOS is going to be the same only worse, because it's not even built
>  the same way as the rest of Fedora. It's not built by Pungi, we don't
>  get the same messages published when CoreOS builds happen (we don't get
>  messages published at all, IIRC), the metadata for CoreOS builds is not
>  in productmd[2] form like the metadata for Pungi builds, the whole
>  process is entirely different.
>
>  So to boil this down into a representative question: when we are doing
>  the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  whether to release "Fedora CoreOS 34"?
>
>  What does the question "is Fedora CoreOS 34 ready to go" even mean, in
>  the context of how CoreOS is built and released? What set of bits will
>  we be deciding to ship or not ship, and how will that have been decided
>  and communicated? Where will we look to find the test results and
>  criteria on which we would base that decision?
>
>  Are any of these silly questions, which would indicate that our release
>  process is based on assumptions which need to be fundamentally re-
>  examined as part of this Change?
>
>  All of this is stuff we could kind of handwave so long as CoreOS wasn't
>  an official Edition; we could *more or less* leave the CoreOS team to
>  decide what a CoreOS release looked like and when it would happen and
>  when it was good enough to ship, and so on.
>
>  But if we're going to call it an Edition, which is one of the primary
>  things that defines what Fedora *is*, I don't think we can do that any
>  more. We need more groups to think about and decide on the answers to
>  questions like the above.
>
>  [1]:
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-fin...
>  [2]: https://github.com/release-engineering/productmd 
This is a fair point. I've personally been very annoyed about how
little Fedora CoreOS integrates with the rest of the Fedora Project.
One very broken consequence of Fedora CoreOS working this way is that
they basically *don't* participate in Changes discussions and just do
things differently without warning or documentation. This has led to
problems when Fedora CoreOS differs from the rest of Fedora in core,
fundamental ways. This has even happened unintentionally, where Fedora
CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using
the wrong variant of iptables:
https://github.com/coreos/fedora-coreos-tracker/issues/676

Additionally, to the point about their tooling: there's been a bunch
of effort to plug OSBuild based image builds into our normal
infrastructure, and given that even Fedora IoT Edition can
successfully be produced through that pipeline, I would think that we
should have Fedora CoreOS transition to it. There's a lot more effort
going around OSBuild within the project as a whole, and it's much more
likely that we'll be able to incorporate that into the general
infrastructure in a way that makes it traceable and actionable within
and outside the project.

I would personally rather see Fedora CoreOS pulled *back* into the
fold more as an Edtion.


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

[Jonathan Lebon]

On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  This is a fair point. I've personally been very annoyed about
> how
>  little Fedora CoreOS integrates with the rest of the Fedora Project.
>  One very broken consequence of Fedora CoreOS working this way is that
>  they basically *don't* participate in Changes discussions and just do
>  things differently without warning or documentation. This has led to
>  problems when Fedora CoreOS differs from the rest of Fedora in core,
>  fundamental ways. This has even happened unintentionally, where Fedora
>  CoreOS accidentally deviated from Fedora (and RHEL CoreOS!) by using
>  the wrong variant of iptables:
>  https://github.com/coreos/fedora-coreos-tracker/issues/676 
We do look over every Fedora Changes that come through and evaluate
how we need to adapt FCOS for them. I agree we could do a better job
at providing more timely feedback to change owners and the community
(thinking about the recent rpmdb backend change for example). Part of
it I think is that we do not yet have a rawhide stream which would
expose us to all these changes earlier (it's on the radar though!).

But to be clear, the intent is always to match Fedora whenever
possible. Due to our update model, we have to be extremely careful
about these changes, and sometimes that means that FCOS lags behind a
bit in getting them. The iptables example was an unfortunate slip up;
ordinarily this would've been part of the f32 rebase just like the
rest of Fedora.

>  Additionally, to the point about their tooling: there's been a
> bunch
>  of effort to plug OSBuild based image builds into our normal
>  infrastructure, and given that even Fedora IoT Edition can
>  successfully be produced through that pipeline, I would think that we
>  should have Fedora CoreOS transition to it. There's a lot more effort
>  going around OSBuild within the project as a whole, and it's much more
>  likely that we'll be able to incorporate that into the general
>  infrastructure in a way that makes it traceable and actionable within
>  and outside the project. 
I agree build tooling is an important part of the picture. Both teams
of coreos-assembler and osbuild are aware of the overlap that exists
and we do plan to discuss this further. Though this is not something
we are likely to tackle in any serious way anytime soon. So for the
purposes of this discussion, I hope we can put this aside. We do run
our builds in CentOS CI, but we're open to integrating with Fedora
processes in any way necessary. For example, we recently added
informational fedmsgs when builds and releases happen as Clement
linked to above.

[Ben Cotton]

On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  So to boil this down into a representative question: when we are doing
>  the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  whether to release "Fedora CoreOS 34"?
>  
This question is relevant to my interests.

On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  Note that if you go to getfedora.org and click on CoreOS *right now*,
>  it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>  is kinda fine so long as it's an Emerging Edition. It would *not*,
>  IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>  months after Fedora 34 is "released", our "stable" CoreOS is still
>  Fedora 33-based, that seems like the sort of thing that would look bad. 
I agree. I understand the reasoning, but I'd really like to see FCOS
align with the rest of the schedule or at least develop a clear and
succinct explanation of why it's delayed so that the public and the
tech press can easily understand.

On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  I would personally rather see Fedora CoreOS pulled *back* into the
>  fold more as an Edtion 
From a program management perspective, I've largely closed my eyes and
gone "la la la" when it comes to FCOS, in part because it is so
separate from what we know as Fedora. Making FCOS work more like what
we know as Fedora would certainly be helpful from my perspective, but
at the same time there are technical challenges to that. And maybe
what FCOS does from a distro-building standpoint is more like what we
should move toward. Maybe not.

In any case, part of the work to be done here, if the Change is
approved, is for me to figure out how to include FCOS in some of the
program management work.

I wonder if it would be better to target this for Fedora 35, with some
of the work starting now. Given the work it took to get IoT into the
fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
feels pretty optimistic here.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Neal Gompa]

On Wed, Dec 2, 2020 at 12:58 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > So to boil this down into a representative question: when we are doing
>  > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  > whether to release "Fedora CoreOS 34"?
>  >
>  This question is relevant to my interests.
>
>  On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > Note that if you go to getfedora.org and click on CoreOS *right now*,
>  > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>  > is kinda fine so long as it's an Emerging Edition. It would *not*,
>  > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>  > months after Fedora 34 is "released", our "stable" CoreOS is
> still
>  > Fedora 33-based, that seems like the sort of thing that would look bad.
>
>  I agree. I understand the reasoning, but I'd really like to see FCOS
>  align with the rest of the schedule or at least develop a clear and
>  succinct explanation of why it's delayed so that the public and the
>  tech press can easily understand.
>  
I would probably suggest that they *must* make it so they can rebase
and release to a new stable release when the rest of the platform
does. If they want to make releases faster (a la Fedora Cloud), that's
fine. But being slower is not acceptable, IMHO.

>  On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>  >
>  > I would personally rather see Fedora CoreOS pulled *back* into the
>  > fold more as an Edtion
>
>  From a program management perspective, I've largely closed my eyes and
>  gone "la la la" when it comes to FCOS, in part because it is so
>  separate from what we know as Fedora. Making FCOS work more like what
>  we know as Fedora would certainly be helpful from my perspective, but
>  at the same time there are technical challenges to that. And maybe
>  what FCOS does from a distro-building standpoint is more like what we
>  should move toward. Maybe not.
>
>  In any case, part of the work to be done here, if the Change is
>  approved, is for me to figure out how to include FCOS in some of the
>  program management work.
>
>  I wonder if it would be better to target this for Fedora 35, with some
>  of the work starting now. Given the work it took to get IoT into the
>  fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
>  feels pretty optimistic here. 
I suspect that you're right and this should be retargeted for Fedora 35.



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

[Peter Robinson]

On Wed, Dec 2, 2020 at 5:58 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > So to boil this down into a representative question: when we are doing
>  > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  > whether to release "Fedora CoreOS 34"?
>  >
>  This question is relevant to my interests.
>
>  On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > Note that if you go to getfedora.org and click on CoreOS *right now*,
>  > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>  > is kinda fine so long as it's an Emerging Edition. It would *not*,
>  > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>  > months after Fedora 34 is "released", our "stable" CoreOS is
> still
>  > Fedora 33-based, that seems like the sort of thing that would look bad.
>
>  I agree. I understand the reasoning, but I'd really like to see FCOS
>  align with the rest of the schedule or at least develop a clear and
>  succinct explanation of why it's delayed so that the public and the
>  tech press can easily understand.
>
>  On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > I would personally rather see Fedora CoreOS pulled *back* into the
>  > fold more as an Edtion
>
>  From a program management perspective, I've largely closed my eyes and
>  gone "la la la" when it comes to FCOS, in part because it is so
>  separate from what we know as Fedora. Making FCOS work more like what
>  we know as Fedora would certainly be helpful from my perspective, but
>  at the same time there are technical challenges to that. And maybe
>  what FCOS does from a distro-building standpoint is more like what we
>  should move toward. Maybe not.
>
>  In any case, part of the work to be done here, if the Change is
>  approved, is for me to figure out how to include FCOS in some of the
>  program management work.
>
>  I wonder if it would be better to target this for Fedora 35, with some
>  of the work starting now. Given the work it took to get IoT into the
>  fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
>  feels pretty optimistic here. 
From memory we started in IoT Edition process in earnest in F-32, part
of the delay here was because there had never really been the process
properly defined for promotion, but it took some time and engagement
across a number of areas of the project which I feel were useful for
the IoT Edition, overall starting the discussion for what's required
and expected is useful for the Edition themselves to improve and work
in the right direction IMO from experience.

[Clement Verna]

On Wed, 2 Dec 2020 at 19:07, Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > So to boil this down into a representative question: when we are doing
>  > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  > whether to release "Fedora CoreOS 34"?
>  >
>  This question is relevant to my interests.
>
>  On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  >
>  > Note that if you go to getfedora.org and click on CoreOS *right now*,
>  > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
>  > is kinda fine so long as it's an Emerging Edition. It would *not*,
>  > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
>  > months after Fedora 34 is "released", our "stable" CoreOS is
> still
>  > Fedora 33-based, that seems like the sort of thing that would look bad.
>
>  I agree. I understand the reasoning, but I'd really like to see FCOS
>  align with the rest of the schedule or at least develop a clear and
>  succinct explanation of why it's delayed so that the public and the
>  tech press can easily understand.
>  
It is hard for something that releases every 2 weeks to align with the rest
of the schedule, we have the same struggle with the container images. It
feels odd to have to wait 6 months to introduce changes when you release a
new version every couple weeks.


>  On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  >
>  > I would personally rather see Fedora CoreOS pulled *back* into the
>  > fold more as an Edtion
>
>  From a program management perspective, I've largely closed my eyes and
>  gone "la la la" when it comes to FCOS, in part because it is so
>  separate from what we know as Fedora. Making FCOS work more like what
>  we know as Fedora would certainly be helpful from my perspective, but
>  at the same time there are technical challenges to that. And maybe
>  what FCOS does from a distro-building standpoint is more like what we
>  should move toward. Maybe not.
>  
>  In any case, part of the work to be done here, if the Change is
>  approved, is for me to figure out how to include FCOS in some of the
>  program management work.
>
>  I wonder if it would be better to target this for Fedora 35, with some
>  of the work starting now. Given the work it took to get IoT into the
>  fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
>  feels pretty optimistic here.
>  
I am open to moving this to F3X but I currently don't have a clear idea of
what is required to be an Edition. If I could get a list of things that
needs to be done, that would help consider if this is doable or not.


>  --
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Dusty Mabe]

On 12/2/20 12:57 PM, Ben Cotton wrote:
>  On Wed, Dec 2, 2020 at 12:22 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
> >
> > So to boil this down into a representative question: when we are doing
> > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
> > whether to release "Fedora CoreOS 34"?
> >
>  This question is relevant to my interests. 
That's fair. I think the answer to this question is that we need to consider
the way the Fedora CoreOS update streams/release model can play into this.
In short I think we'll all need to evolve a bit. It's just not going to be
the exact same as traditional Fedora major releases have been.

>  
>  On Wed, Dec 2, 2020 at 12:36 PM Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
> >
> > Note that if you go to getfedora.org and click on CoreOS *right now*,
> > it offers you a Fedora 32-based CoreOS. This is the kind of thing that
> > is kinda fine so long as it's an Emerging Edition. It would *not*,
> > IMHO, be fine for an Edition. If we accept CoreOS as an edition and two
> > months after Fedora 34 is "released", our "stable" CoreOS is
> still
> > Fedora 33-based, that seems like the sort of thing that would look bad.
>  
>  I agree. I understand the reasoning, but I'd really like to see FCOS
>  align with the rest of the schedule or at least develop a clear and
>  succinct explanation of why it's delayed so that the public and the
>  tech press can easily understand. 
I 100% would like to get to a point where we rebase to the latest Fedora
major soon after release. As jlebon mentioned earlier this does mean working
harder to get ahead of the curve by adopting a rawhide development stream
(not exposed to users) and taking more part in the Changes process.

>  
>  On Wed, Dec 2, 2020 at 12:31 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
> >
> > I would personally rather see Fedora CoreOS pulled *back* into the
> > fold more as an Edtion
>  
>  From a program management perspective, I've largely closed my eyes and
>  gone "la la la" when it comes to FCOS, in part because it is so
>  separate from what we know as Fedora. Making FCOS work more like what
>  we know as Fedora would certainly be helpful from my perspective, but
>  at the same time there are technical challenges to that. And maybe
>  what FCOS does from a distro-building standpoint is more like what we
>  should move toward. Maybe not. 
Yes. I think we should consider it with a slightly different perspective
than we do other editions, but I'm definitely not asking for a pass. Let's
work together to define the future.

>  
>  In any case, part of the work to be done here, if the Change is
>  approved, is for me to figure out how to include FCOS in some of the
>  program management work.
>  
>  I wonder if it would be better to target this for Fedora 35, with some
>  of the work starting now. Given the work it took to get IoT into the
>  fold (which, as Adam noted, is a smaller effort than FCOS), Fedora 34
>  feels pretty optimistic here. 
I think that's reasonable, but maybe we can meet sooner to try to get some
answers to foundational questions answered so that we can be prepared to
be in better compliance for the Fedora 35 timeframe.

Dusty

[Julen Landa Alustiza]

20/12/3 03:39(e)an, Dusty Mabe igorleak idatzi zuen:
>  
>  
>  
>  I 100% would like to get to a point where we rebase to the latest Fedora
>  major soon after release. As jlebon mentioned earlier this does mean working
>  harder to get ahead of the curve by adopting a rawhide development stream
>  (not exposed to users) and taking more part in the Changes process.
>   
Why should we hide coreos rawhide stream? coreos rawhide should have 
standard rawhide's same exposition level imo. We don't public links on 
getfedora.org, but we allow anyone to use it just changing your repos, 
or directly installing it. Why not allow the same behaviour for coreos 
rawhide allowing to everyone to rebase to it? What's the benefit of 
hiding it from the public?

[Clement Verna]

On Wed, 2 Dec 2020 at 18:27, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Wed, 2020-12-02 at 09:23 -0500, Ben Cotton wrote:
>  >
>  > == How To Test ==
>  > See QA test cases :
>  https://fedoraproject.org/wiki/Category:CoreOS_Test_Cases
>  >
>  > We also have regular tests days, for example
>  > https://fedoramagazine.org/fedora-coreos-test-day/
>
>  So...yeah, that's not really enough to call something a Fedora Edition
>  :)
>
>  I think this has a lot of the issues we had with IoT, but turned up to
>  11.
>
>  We have an entire process for releasing a thing called "Fedora" which
>  is based around the idea that all the bits that make up a "Fedora
>  release" get built, tested, and signed off together.
>
>  IoT stretched this process a bit, because it's not actually built as
>  part of the same composes as all the other "Fedora" bits. So we had to
>  implement an entire parallel validation process just for IoT composes.
>  But at least it's built *the same way* as Fedora, so we could more or
>  less just split existing things into two paths and use them, which is
>  what we did. We now have both mainline and IoT composes and validation
>  events. Even there, the process wasn't perfect for Fedora 33; if you
>  look at the log of the Fedora 33 Go/No-Go meeting[1], which is supposed
>  to be where we go over the status of the bits-to-be-released in great
>  detail and decide whether to sign them off, there is precisely one line
>  about IoT:
>
>  17:58:36 <pwhalen> IoT is also covered -
>
> https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_33_RC_20201020.0_G...
>
>  ...no-one else said a word about it. So yeah, we clearly don't have
>  this whole "releasing from multiple streams" entirely down yet.
>
>  CoreOS is going to be the same only worse, because it's not even built
>  the same way as the rest of Fedora. It's not built by Pungi, we don't
>  get the same messages published when CoreOS builds happen (we don't get
>  messages published at all, IIRC), the metadata for CoreOS builds is not
>  in productmd[2] form like the metadata for Pungi builds, the whole
>  process is entirely different.
>  
Recently messages were added when streams are updated [0][1]. I believe
that other messages could be added if needed.


>  So to boil this down into a representative question: when we are doing
>  the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  whether to release "Fedora CoreOS 34"?
>
>  
Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
next, each stream is released every 2 weeks.
The Go/No-Go is based on reports coming from each stream, next stream is
promoted to testing and testing promoted to stable.
If any blockers are found in next or testing the content will not be
promoted to stable.

I think it is fairly well explained here[2]


>  What does the question "is Fedora CoreOS 34 ready to go" even mean, in
>  the context of how CoreOS is built and released? What set of bits will
>  we be deciding to ship or not ship, and how will that have been decided
>  and communicated? Where will we look to find the test results and
>  criteria on which we would base that decision?
>
>  
To maintain a fortnightly cadence there is a strong reliance on CI, every
build is tested and results are inspected during the release process.
Currently a release is gated on tests running on AWS, GCP and Openstack,
these tests are running on a centos-ci jenkins instance which I think
cannot be access without a centos account (I might be wrong), but yeah
making these tests and results more transparent could be an improvement.


>  Are any of these silly questions, which would indicate that our release
>  process is based on assumptions which need to be fundamentally re-
>  examined as part of this Change?
>  
So what defines an Edition ? I think if we don't want to accept a different
philosophy about release schedule and release engineering we can just close
that Change proposal.

How do you consider Rawhide for example ?


>  All of this is stuff we could kind of handwave so long as CoreOS wasn't
>  an official Edition; we could *more or less* leave the CoreOS team to
>  decide what a CoreOS release looked like and when it would happen and
>  when it was good enough to ship, and so on.
>  
So this change comes down to Can we have a Fedora Edition that has a
different workflow ?


>  But if we're going to call it an Edition, which is one of the
> primary
>  things that defines what Fedora *is*, I don't think we can do that any
>  more. We need more groups to think about and decide on the answers to
>  questions like the above.
>  

[0] - https://github.com/coreos/fedora-coreos-tracker/issues/225
[1] -
https://apps.fedoraproject.org/datagrepper/id?id=2020-81657c3b-9703-431a-...
[2] -
https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#rel...


>  [1]:
>
> https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-10-22/f33-fin...
>  [2]: https://github.com/release-engineering/productmd
>  --
>  Adam Williamson
>  Fedora QA
>  IRC: adamw | Twitter: adamw_ha
>  https://www.happyassassin.net
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Adam Williamson]

On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
>  > 
>  > CoreOS is going to be the same only worse, because it's not even built
>  > the same way as the rest of Fedora. It's not built by Pungi, we don't
>  > get the same messages published when CoreOS builds happen (we don't get
>  > messages published at all, IIRC), the metadata for CoreOS builds is not
>  > in productmd[2] form like the metadata for Pungi builds, the whole
>  > process is entirely different.
>  > 
>  
>  Recently messages were added when streams are updated [0][1]. I believe
>  that other messages could be added if needed. 
Right, I forgot about that, thanks. I've got a ticket lying around here
somewhere to make something actually use them...:)
>  > 
>  > So to boil this down into a representative question: when we are doing
>  > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  > whether to release "Fedora CoreOS 34"?
>  > 
>  > 
>  Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing and
>  next, each stream is released every 2 weeks.
>  The Go/No-Go is based on reports coming from each stream, next stream is
>  promoted to testing and testing promoted to stable.
>  If any blockers are found in next or testing the content will not be
>  promoted to stable.
>  
>  I think it is fairly well explained here[2]
>  > 
>  > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
>  > the context of how CoreOS is built and released? What set of bits will
>  > we be deciding to ship or not ship, and how will that have been decided
>  > and communicated? Where will we look to find the test results and
>  > criteria on which we would base that decision?
>  > 
>  > 
>  To maintain a fortnightly cadence there is a strong reliance on CI, every
>  build is tested and results are inspected during the release process.
>  Currently a release is gated on tests running on AWS, GCP and Openstack,
>  these tests are running on a centos-ci jenkins instance which I think
>  cannot be access without a centos account (I might be wrong), but yeah
>  making these tests and results more transparent could be an improvement. 
Right, but - as I think you started to recognize later in your mail -
we're sort of talking at cross-purposes here. You're talking about a
process that has been developed kind of in isolation for building and
releasing a thing which has the name "Fedora CoreOS" but doesn't
actually really integrate much at all with the processes we have for
building and releasing all the other things that make up "Fedora".

This is kind of fine as things stand because the thing with the name
"Fedora CoreOS" isn't considered to be a core fundamental part of the
thing with the name "Fedora". But this Change is about making it that.
Doing that causes all sorts of awkward impedance mismatches. Like,
saying "Fedora CoreOS 34 does not exist" is awkward, because we still
have this kind of institutional concept of a "Fedora release" which is
important to what the thing called "Fedora" is and does. To the outside
world, there is a strong impression that the thing called "Fedora" is a
product or set of products with a release number that gets released
every six months. The concept of "Fedora 33 release" or "Fedora 34
release" is a strong concept with all these sort of institutional
ripples.

If we want the thing called "Fedora CoreOS" to be a key, fundamental
component of the thing called "Fedora" - which is what making it an
"Edition" is effectively about - we have to deal with those impedance
mismatches.

So in this case, we could, for instance, make "Fedora CoreOS 34" a
'thing' by requiring that the CoreOS stable stream gets bumped at the
same time as the rest of the Fedora "release" happening. That gives us
a nice simple story that fits into our existing way of doing things.
This is more or less what we did with IoT: as things stand, the
situation with IoT is "OK, it's built from a separate compose stream,
but we still expect it to tie into the release cycle. We expect there
to be a release candidate based on the same bits as the mainline
release, with the same release number, that we sign off and release at
the same time."

Of course, that's also the drawback. If we don't want to do that, we
have to resolve the problem some other way, which is quite a
fundamental thing, if you think about it. My point here is that to do
that properly, we have to reconsider the strong idea that "Fedora is a
product that comes out every six months", which is a big job that comes
with quite a lot of consequences. It has consequences, for instance,
for our most important forms of communication to the wider world: how
do we pivot from this simple story that "Fedora is a (set of)
product(s) that come(s) out every six months, look out for our big
Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
this other thing that has three streams which release every two weeks
and roll over according to some completely other schedule"? And so on.

I'm not saying these are things that should stop the Change, I'm saying
they're things that *need to be considered as part of implementing the
Change*, and deciding its schedule. What I'd be worried about is if
this Change just amounted to bumping CoreOS up a few hundred pixels on
getfedora.org but otherwise changing nothing, because I think that
would actually cause some quite fundamental problems in terms of how we
think and talk about the thing called "Fedora".

It's true that for a while we called Atomic an edition, but it had most
of the same issues I talk about above and we didn't really resolve
them. I think we sort of got by with that because at that time our
communication wasn't quite as strong or clear and Atomic was more
obviously a thing which wasn't entirely "baked" yet, so people still
didn't consider it "really" a key part of Fedora, it still got
handwaved. I think that was us getting lucky, and we really should have
addressed more of these concerns more strongly then; I also think it's
not a given we'd get away with the same outcome now if we just hung an
"Edition" sign on CoreOS now but otherwise didn't consider any of these
concerns.
>  > 
>  > Are any of these silly questions, which would indicate that our release
>  > process is based on assumptions which need to be fundamentally re-
>  > examined as part of this Change?
>  > 
>  
>  So what defines an Edition ? 
Good question! getfedora.org uses the concept, but doesn't define it.
So the authoritative source, I guess, is still
https://fedoraproject.org/wiki/Editions , which says "Fedora Editions
are curated sets of packages, guidelines and configuration, and
artifacts built from those pieces, that address a specific, targeted
use-case. The Editions are the primary Fedora outputs that most Fedora
users are encouraged to use and directed towards through the download
site."

>   I think if we don't want to accept a different
>  philosophy about release schedule and release engineering we can just close
>  that Change proposal. 
That's not the outcome I intended, but rather that if we want CoreOS to
be an "Edition" but we don't want to require it to conform to the
existing "philosophy", as you put it, we need the scope of this Change
to include thinking through all the consequences of that and deciding
what to do about them.

>  How do you consider Rawhide for example ? 
Rawhide isn't an edition, which I think should be clear from the
definitions above. Rawhide is sort of the primordial soup from which
Editions and all else eventually emerges, I guess. :P
>  > 
>  > All of this is stuff we could kind of handwave so long as CoreOS wasn't
>  > an official Edition; we could *more or less* leave the CoreOS team to
>  > decide what a CoreOS release looked like and when it would happen and
>  > when it was good enough to ship, and so on.
>  > 
>  
>  So this change comes down to Can we have a Fedora Edition that has a
>  different workflow ? 
More or less, yes - but with a key addition: "...and if so, how?"
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

Release cadence and Editions [was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]

[Matthew Miller]

On Wed, Dec 02, 2020 at 12:15:21PM -0800, Adam Williamson wrote:
>  with quite a lot of consequences. It has consequences, for instance,
>  for our most important forms of communication to the wider world: how
>  do we pivot from this simple story that "Fedora is a (set of)
>  product(s) that come(s) out every six months, look out for our big
>  Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
>  this other thing that has three streams which release every two weeks
>  and roll over according to some completely other schedule"? And so on. 
I think some of this is helped by not thinking of Fedora as the OS itself,
just like Red Hat isn't RHEL and RHEL isn't Red Hat. I mean, it doesn't
solve any of your problems :) but it's a start towards getting people to
think about it differently. I think this reads a lot more simply:

  Fedora is a project that has a set of deliverables that have traditionally
  been released every six months. We now have some deliverables that follow
  a different schedule. We're moving to a model where our main underlying
  software repository updates on the traditional six-month cadence, our
  various products will come with their own release announcements.

  Fedora Workstation, which is our most popular desktop offering, will stay
  on the familiar April/October release cadence. Silverblue, IoT, and CoreOS
  are examples of other Fedora operating system flavors that follow a
  rolling-release model instead. Our KDE Plasma Desktop follows the upstream
  KDE releases, which happen every four months, using the most-current
  Fedora software base at that time. [This last statement is obviously not
  true, but I'd like it to be a possiblity.] On the other hand, our Fedora
  School OS flavor [also not real] updates only once a year, at the end of
  May, so that school IT teams can deploy over the summer and not worry
  about upgrades until the next summer.

Obviously there's some hard work to make that into a reality. But that's
what I'd like to get to and it's basically what the Council decided we'd
like a couple of years ago. (See below.)

Right now, most of the press we get is around Fedora Workstation no matter
what we do. (I have tried very hard to get press folks to talk about Fedora
Server, Atomic, CoreOS, IoT, KDE and Xfce, SoaS, etc., etc., and I'm lucky
if I get a line or two in an article.) If we want press around other
offerings — desktop, or other use cases — it'll actually be _better_ to
split them off so they're not overshadowed.


>  Good question! getfedora.org uses the concept, but doesn't define
> it.
>  So the authoritative source, I guess, is still
>  https://fedoraproject.org/wiki/Editions , which says "Fedora Editions
>  are curated sets of packages, guidelines and configuration, and
>  artifacts built from those pieces, that address a specific, targeted
>  use-case. The Editions are the primary Fedora outputs that most Fedora
>  users are encouraged to use and directed towards through the download
>  site." 
The latest official definition is in
https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what...,
which says:

"Some solutions are the premier showcases that we call Editions; these are
 used in the gating tests for our releases."

I'm not super-set on that, though, and would be open to some further
evolution. For example, "gating tests for our releases" should probably be
"for the twice-yearly Fedora rpm repository major-version releases" or
something.¹ And, I think some element of this still is the key thing: we
shouldn't do the general-repo release if it's not possible for the next
release of an Edition to be based on it.

This document is where we also said "Teams are free to define elements of their
Solutions, such as intent, deliverables, and release cadence."²

>  Rawhide isn't an edition, which I think should be clear from the
>  definitions above. Rawhide is sort of the primordial soup from which
>  Editions and all else eventually emerges, I guess. :P 
I am totally up for renaming it to Fedora Primordial Soup. :)

...

1. I'm also open to having more or fewer things that are Editions,
and finding new and better ways to let teams promote their
not-labeled-as-edition outputs.

2. Put "release cadence" in bold for the purposes of this message.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Clement Verna]

On Wed, 2 Dec 2020 at 21:22, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Wed, 2020-12-02 at 19:42 +0100, Clement Verna wrote:
>  > >
>  > > CoreOS is going to be the same only worse, because it's not even built
>  > > the same way as the rest of Fedora. It's not built by Pungi, we don't
>  > > get the same messages published when CoreOS builds happen (we don't get
>  > > messages published at all, IIRC), the metadata for CoreOS builds is not
>  > > in productmd[2] form like the metadata for Pungi builds, the whole
>  > > process is entirely different.
>  > >
>  >
>  > Recently messages were added when streams are updated [0][1]. I believe
>  > that other messages could be added if needed.
>
>  Right, I forgot about that, thanks. I've got a ticket lying around here
>  somewhere to make something actually use them...:)
>  > >
>  > > So to boil this down into a representative question: when we are doing
>  > > the Fedora 34 Go/No-Go meeting in ~four months' time, how do we decide
>  > > whether to release "Fedora CoreOS 34"?
>  > >
>  > >
>  > Fedora CoreOS 34 does not exist, you have Fedora CoreOS stable, testing
>  and
>  > next, each stream is released every 2 weeks.
>  > The Go/No-Go is based on reports coming from each stream, next stream is
>  > promoted to testing and testing promoted to stable.
>  > If any blockers are found in next or testing the content will not be
>  > promoted to stable.
>  >
>  > I think it is fairly well explained here[2]
>  > >
>  > > What does the question "is Fedora CoreOS 34 ready to go" even mean,
> in
>  > > the context of how CoreOS is built and released? What set of bits will
>  > > we be deciding to ship or not ship, and how will that have been decided
>  > > and communicated? Where will we look to find the test results and
>  > > criteria on which we would base that decision?
>  > >
>  > >
>  > To maintain a fortnightly cadence there is a strong reliance on CI, every
>  > build is tested and results are inspected during the release process.
>  > Currently a release is gated on tests running on AWS, GCP and Openstack,
>  > these tests are running on a centos-ci jenkins instance which I think
>  > cannot be access without a centos account (I might be wrong), but yeah
>  > making these tests and results more transparent could be an improvement.
>
>  Right, but - as I think you started to recognize later in your mail -
>  we're sort of talking at cross-purposes here. You're talking about a
>  process that has been developed kind of in isolation for building and
>  releasing a thing which has the name "Fedora CoreOS" but doesn't
>  actually really integrate much at all with the processes we have for
>  building and releasing all the other things that make up "Fedora".
>  
Indeed and this was because the current tools and processes were not
designed to work
with a Fedora releasing every 2 weeks. Being allowed to think outside of
the box
and doing things differently is IMO a good thing and should be encouraged.


>  This is kind of fine as things stand because the thing with the name
>  "Fedora CoreOS" isn't considered to be a core fundamental part of the
>  thing with the name "Fedora". But this Change is about making it that.
>  Doing that causes all sorts of awkward impedance mismatches. Like,
>  saying "Fedora CoreOS 34 does not exist" is awkward, because we still
>  have this kind of institutional concept of a "Fedora release" which is
>  important to what the thing called "Fedora" is and does. 
To the outside
>  world, there is a strong impression that the thing called
> "Fedora" is a
>  product or set of products with a release number that gets released
>  every six months. The concept of "Fedora 33 release" or "Fedora 34
>  release" is a strong concept with all these sort of institutional
>  ripples.
>  
And why cannot we make this evolve ? Is it bad to have a Fedora that has
streams instead of versions ?
Promoting FCOS to an edition is the opportunity to communicate about this
and say to the outside, hey we
have this new thing in Fedora that has a different model come and check it
out.
Fedora has the reputation of leading innovation and doing things first, I
would like to think that making Fedora CoreOS an edition would match these
values.

Also having a different model allows us to expand and reach out to other
types of users.
For years I have heard "I would like to run Fedora on my server, but there
is no LTS and I don't want to do a major upgrade every year".
Why wouldn't be Fedora CoreOS, a possible answer to that problem ?

I believe that we need to be open to doing things differently and welcome
different use cases.


>  If we want the thing called "Fedora CoreOS" to be a key, fundamental
>  component of the thing called "Fedora" - which is what making it an
>  "Edition" is effectively about - we have to deal with those impedance
>  mismatches.
>
>  So in this case, we could, for instance, make "Fedora CoreOS 34" a
>  'thing' by requiring that the CoreOS stable stream gets bumped at the
>  same time as the rest of the Fedora "release" happening. That gives us
>  a nice simple story that fits into our existing way of doing things.
>  
Is this only a story problem ? I am sorry but I really struggle to
understand why we cannot have a Fedora Edition that does not release every
6 months.
Would you mind explaining a bit more why it matters so much to be able to
say we have a Fedora CoreOS 34 ?



>  This is more or less what we did with IoT: as things stand, the
>  situation with IoT is "OK, it's built from a separate compose stream,
>  but we still expect it to tie into the release cycle. We expect there
>  to be a release candidate based on the same bits as the mainline
>  release, with the same release number, that we sign off and release at
>  the same time."
>
>  Of course, that's also the drawback. If we don't want to do that, we
>  have to resolve the problem some other way, which is quite a
>  fundamental thing, if you think about it. My point here is that to do
>  that properly, we have to reconsider the strong idea that "Fedora is a
>  product that comes out every six months", which is a big job that comes
>  with quite a lot of consequences. It has consequences, for instance,
>  for our most important forms of communication to the wider world: how
>  do we pivot from this simple story that "Fedora is a (set of)
>  product(s) that come(s) out every six months, look out for our big
>  Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO
>  this other thing that has three streams which release every two weeks
>  and roll over according to some completely other schedule"? And so on.
>  
Considering the use cases and target users of Fedora CoreOS I think telling
2 different stories should not be a problem.
IMO this is already happening, I don't think people are confused between
for example Fedora Workstation and Fedora CoreOS.
I do see much more confusion around Silverblue, IoT and Fedora CoreOS tho.


>  I'm not saying these are things that should stop the Change, I'm saying
>  they're things that *need to be considered as part of implementing the
>  Change*, and deciding its schedule. What I'd be worried about is if
>  this Change just amounted to bumping CoreOS up a few hundred pixels on
>  getfedora.org but otherwise changing nothing, because I think that
>  would actually cause some quite fundamental problems in terms of how we
>  think and talk about the thing called "Fedora".
>  
>  It's true that for a while we called Atomic an edition, but it
> had most
>  of the same issues I talk about above and we didn't really resolve
>  them. I think we sort of got by with that because at that time our
>  communication wasn't quite as strong or clear and Atomic was more
>  obviously a thing which wasn't entirely "baked" yet, so people still
>  didn't consider it "really" a key part of Fedora, it still got
>  handwaved. I think that was us getting lucky, and we really should have
>  addressed more of these concerns more strongly then; I also think it's
>  not a given we'd get away with the same outcome now if we just hung an
>  "Edition" sign on CoreOS now but otherwise didn't consider any of these
>  concerns.
>  > >
>  > > Are any of these silly questions, which would indicate that our release
>  > > process is based on assumptions which need to be fundamentally re-
>  > > examined as part of this Change?
>  > >
>  >
>  > So what defines an Edition ?
>
>  Good question! getfedora.org uses the concept, but doesn't define it.
>  So the authoritative source, I guess, is still
>  https://fedoraproject.org/wiki/Editions , which says "Fedora Editions
>  are curated sets of packages, guidelines and configuration, and
>  artifacts built from those pieces, that address a specific, targeted
>  use-case. The Editions are the primary Fedora outputs that most Fedora
>  users are encouraged to use and directed towards through the download
>  site."
>  
According to the above, it sounds to me that Fedora CoreOS fits the
definition.

>  >  I think if we don't want to accept a different
>  > philosophy about release schedule and release engineering we can just
>  close
>  > that Change proposal.
>
>  That's not the outcome I intended, but rather that if we want CoreOS to
>  be an "Edition" but we don't want to require it to conform to the
>  existing "philosophy", as you put it, we need the scope of this Change
>  to include thinking through all the consequences of that and deciding
>  what to do about them.
>  
Happy to do that, is your main concern about communication and the story of
what is "Fedora" ? or what are the other consequences ?


>  > How do you consider Rawhide for example ?
>
>  Rawhide isn't an edition, which I think should be clear from the
>  definitions above. Rawhide is sort of the primordial soup from which
>  Editions and all else eventually emerges, I guess. :P
>  > >
>  > > All of this is stuff we could kind of handwave so long as CoreOS wasn't
>  > > an official Edition; we could *more or less* leave the CoreOS team to
>  > > decide what a CoreOS release looked like and when it would happen and
>  > > when it was good enough to ship, and so on.
>  > >
>  >
>  > So this change comes down to Can we have a Fedora Edition that has a
>  > different workflow ?
>
>  More or less, yes - but with a key addition: "...and if so, how?"
>  
I feel that we already have the how, Fedora CoreOS has been releasing
fortnightly for more than a year now.
So it is a matter of making more widely known how this is done ?


Thanks for sharing your concerns, I think this is a really good
conversation to have.


>  --
>  Adam Williamson
>  Fedora QA
>  IRC: adamw | Twitter: adamw_ha
>  https://www.happyassassin.net
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Adam Williamson]

On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:


[big snip]

>  To the outside
>  > world, there is a strong impression that the thing called "Fedora" is a
>  > product or set of products with a release number that gets released
>  > every six months. The concept of "Fedora 33 release" or "Fedora 34
>  > release" is a strong concept with all these sort of institutional
>  > ripples.
>  > 
>  
>  And why cannot we make this evolve ? Is it bad to have a Fedora that has
>  streams instead of versions ? 
We can.

Can I ask that you please read my *whole* emails before writing your
replies? Or at least if you must reply in-line while reading, please
after you finish, go back and see if what you wrote earlier still
applies? All of this stuff up top is irrelevant because it's all based
on an assumption that I was saying FCOS must at all costs align with
existing processes and schedules, when I was not saying that at all. I
was just trying to outline the situation and the factors that need to
be considered.

I'll reply to the stuff from lower down, where you actually engaged
with what I was actually saying, in a separate mail.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Clement Verna]

On Thu, 3 Dec 2020 at 20:32, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
>
>
>  [big snip]
>
>  > To the outside
>  > > world, there is a strong impression that the thing called "Fedora" is
> a
>  > > product or set of products with a release number that gets released
>  > > every six months. The concept of "Fedora 33 release" or "Fedora
> 34
>  > > release" is a strong concept with all these sort of institutional
>  > > ripples.
>  > >
>  >
>  > And why cannot we make this evolve ? Is it bad to have a Fedora that has
>  > streams instead of versions ?
>
>  We can.
>
>  Can I ask that you please read my *whole* emails before writing your
>  replies? Or at least if you must reply in-line while reading, please
>  after you finish, go back and see if what you wrote earlier still
>  applies? All of this stuff up top is irrelevant because it's all based
>  on an assumption that I was saying FCOS must at all costs align with
>  existing processes and schedules, when I was not saying that at all. I
>  was just trying to outline the situation and the factors that need to
>  be considered.
>  
Sorry if that came down that way, but I was trying to get a better
understanding of your concerns.
I ll try to do better next time :-)


>  I'll reply to the stuff from lower down, where you actually engaged
>  with what I was actually saying, in a separate mail.
>  --
>  Adam Williamson
>  Fedora QA
>  IRC: adamw | Twitter: adamw_ha
>  https://www.happyassassin.net
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Adam Williamson]

On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
>  > >   I think if we don't want to accept a different
>  > > philosophy about release schedule and release engineering we can
>  just
>  > close
>  > > that Change proposal.
>  > 
>  > That's not the outcome I intended, but rather that if we want
>  CoreOS to
>  > be an "Edition" but we don't want to require it to conform to the
>  > existing "philosophy", as you put it, we need the scope of this
>  Change
>  > to include thinking through all the consequences of that and
>  deciding
>  > what to do about them.
>  > 
>  
>  Happy to do that, is your main concern about communication and the
>  story of
>  what is "Fedora" ? or what are the other consequences ? 
For me personally it's mainly about validation and release engineering.
Specifically, making sure the processes we have in place for deciding
when to cut a CoreOS release in a stream and when to bump streams
between releases align with the Fedora-wide release criteria etc, and
making sure the release criteria express all the requirements we
actually intend to have for making those choices as regards CoreOS.
Making sure there's a clear vertically-integrated process, like there
is for "Fedora", from Edition PRDs to release criteria to validation
tests to release decisions, and there are all the necessary bits of
glue in between those layers, so you can pretty easily trace back and
forth between them.

But I suspect there are various consequences for other teams and other
parts of the process, if you think about it. If you just look at a
Fedora release schedule:

https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html

there are a zillion things on there, and they're all aligned to our big
every-six-month-release-machine somehow. At minimum, it'd be a good
idea to look through all those and think about whether and how each
entry would be affected by having an Edition with a completely
different release process.

>  > More or less, yes - but with a key addition: "...and if so,
> how?"
>  > 
>  
>  I feel that we already have the how, Fedora CoreOS has been releasing
>  fortnightly for more than a year now.
>  So it is a matter of making more widely known how this is done ? 
It's a matter of "how" from the perspective of the Fedora project. I
just meant it as an expression of all the other stuff above.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Clement Verna]

On Thu, 3 Dec 2020 at 20:42, Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Thu, 2020-12-03 at 19:48 +0100, Clement Verna wrote:
>  > > >   I think if we don't want to accept a different
>  > > > philosophy about release schedule and release engineering we can
>  > just
>  > > close
>  > > > that Change proposal.
>  > >
>  > > That's not the outcome I intended, but rather that if we want
>  > CoreOS to
>  > > be an "Edition" but we don't want to require it to conform to
> the
>  > > existing "philosophy", as you put it, we need the scope of this
>  > Change
>  > > to include thinking through all the consequences of that and
>  > deciding
>  > > what to do about them.
>  > >
>  >
>  > Happy to do that, is your main concern about communication and the
>  > story of
>  > what is "Fedora" ? or what are the other consequences ?
>
>  For me personally it's mainly about validation and release engineering.
>  Specifically, making sure the processes we have in place for deciding
>  when to cut a CoreOS release in a stream and when to bump streams
>  between releases align with the Fedora-wide release criteria etc, and
>  making sure the release criteria express all the requirements we
>  actually intend to have for making those choices as regards CoreOS.
>  Making sure there's a clear vertically-integrated process, like there
>  is for "Fedora", from Edition PRDs to release criteria to validation
>  tests to release decisions, and there are all the necessary bits of
>  glue in between those layers, so you can pretty easily trace back and
>  forth between them.
>
>  But I suspect there are various consequences for other teams and other
>  parts of the process, if you think about it. If you just look at a
>  Fedora release schedule:
>
>  https://fedorapeople.org/groups/schedule/f-34/f-34-all-tasks.html
>
>  there are a zillion things on there, and they're all aligned to our big
>  every-six-month-release-machine somehow. At minimum, it'd be a good
>  idea to look through all those and think about whether and how each
>  entry would be affected by having an Edition with a completely
>  different release process.
>  
Ok I think I can improve the Change proposal along these lines, and start
with what is currently done for each FCOS release and also how that fits
within the schedule.


>  > > More or less, yes - but with a key addition: "...and if so, how?"
>  > >
>  >
>  > I feel that we already have the how, Fedora CoreOS has been releasing
>  > fortnightly for more than a year now.
>  > So it is a matter of making more widely known how this is done ?
>
>  It's a matter of "how" from the perspective of the Fedora project. I
>  just meant it as an expression of all the other stuff above.
>  --
>  Adam Williamson
>  Fedora QA
>  IRC: adamw | Twitter: adamw_ha
>  https://www.happyassassin.net
>
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Colin Walters]

On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote:
>  
>  What does the question "is Fedora CoreOS 34 ready to go" even mean, in
>  the context of how CoreOS is built and released? What set of bits will
>  we be deciding to ship or not ship, and how will that have been decided
>  and communicated? Where will we look to find the test results and
>  criteria on which we would base that decision? 
There are a whole lot of aspects to this, but one angle to look at this from is that I
personally have always thought the way Fedora uses pungi up until releases and
everything's about a "compose" and then it switches to a Bodhi wild west
where updates are unversioned things that can release at any time...well, it doesn't
make much sense.

The concept that you have boot media that can reach 6 months old is a very bad
anti-pattern because there are often periods of time where the software there has security
vulnerabilities.  *Particularly* for a desktop system starting up a 6 month old web
browser is just actively dangerous.

Now I understand there are reasons traditional Fedora does this - among them that Anaconda
is a huge thing on its own.  But for FCOS we made a massive simplification - the
"Live" FCOS *is the same thing as the OS*.  Our `coreos-installer` is just a
glorified `dd` wrapper (mostly) and all system provisioning logic happens in Ignition,
which we're constantly testing all of the time.
(Personally I'm really proud that for example our Live ISO ships with SELinux
enforcing)

FCOS currently respins both an ostree commit and boot media every release, and because we
use coreos-assembler all the time, those are all strongly versioned together and
consistent.

Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that our OS
build and test process runs natively via podman and Kubernetes (unprivileged).  We're
telling people to use containers; building the operating system shouldn't require you
to `yum install` (or even `rpm-ostree` install stuff directly on a host system.  Our
current build pipeline is Jenkins-running-in-OpenShift; we're actively working on
removing Jenkins from the equation in some circumstances and making the whole thing even
more Kubernetes-native.  This is not at all true of the Koji/pungi stack.

[Matthew Miller]

On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote:
>  (Personally I'm really proud that for example our Live ISO ships
> with
>  SELinux enforcing) 
This is true of Fedora Workstation and other desktop spin live ISOs as well.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Thu, 2020-12-03 at 14:06 -0500, Matthew Miller wrote:
>  On Thu, Dec 03, 2020 at 01:58:56PM -0500, Colin Walters wrote:
>  > (Personally I'm really proud that for example our Live ISO ships with
>  > SELinux enforcing)
>  
>  This is true of Fedora Workstation and other desktop spin live ISOs as well. 
Yes, but the live installer runs 'setenforce 0' at the start then sets
it back on exit. As long as the live installer is running, you're in
permissive.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Matthew Miller]

On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote:
>  > > (Personally I'm really proud that for example our Live
> ISO ships with
>  > > SELinux enforcing)
>  > This is true of Fedora Workstation and other desktop spin live ISOs as well.
>  Yes, but the live installer runs 'setenforce 0' at the start then sets
>  it back on exit. As long as the live installer is running, you're in
>  permissive. 
Huh. Well, then, that's cool that CoreOS doesn't need to do that.

Does the live installer really?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Williamson]

On Thu, 2020-12-03 at 14:43 -0500, Matthew Miller wrote:
>  On Thu, Dec 03, 2020 at 11:36:32AM -0800, Adam Williamson wrote:
>  > > > (Personally I'm really proud that for example our Live ISO ships with
>  > > > SELinux enforcing)
>  > > This is true of Fedora Workstation and other desktop spin live ISOs as well.
>  > Yes, but the live installer runs 'setenforce 0' at the start then sets
>  > it back on exit. As long as the live installer is running, you're in
>  > permissive.
>  
>  Huh. Well, then, that's cool that CoreOS doesn't need to do that.
>  
>  Does the live installer really? 
I dunno when's the last time anyone tried without it, tbh.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Colin Walters]

On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote:

>  I dunno when's the last time anyone tried without it, tbh.
For CoreOS we spent a *lot* of time ensuring that Ignition has first class SELinux
support, and actually making it work on the Live ISO in a not-horribly-hacky way required
a kernel patch:
https://lore.kernel.org/selinux/[e-mail]/...

Also related to the installer experience, note that because the installer ISO is the same
thing as the OS, we ship `podman` and so it's fully supported to use Ignition to run
containers before/after the install.

And this is all really part of the story that a benefit of Ignition (in taking the role of
both cloud-init and kickstart compared to traditional Fedora) is that we have a very
consistent, uniform approach to provisioning/configuring the operating system that applies
across cloud, on-premise metal etc.  Also, because our installer environment *is* the OS,
you also have `podman` there...so running containers before/during/after the install is
natural and encouraged.
This OpenShift enhancement covers a lot of this:
https://github.com/openshift/enhancements/blob/master/enhancements/rhcos/...
(Which is relevant here because the Live ISO in FCOS happened after RHCOS 4.1 shipped;
before that we had a hacky shell script in a minimal initramfs)

We are just constantly testing that flow (actually every PR to coreos-assembler, plus it
gates FCOS releases) which particularly compared to Anaconda is massively simplified
because there's no custom GUI involved.

Related to testing, we actually didn't touch on the whole topic that FCOS is fairly
Github oriented.  I did a blog related to this,
https://blog.verbum.org/2020/12/03/still-on-github/
Our release workflow involves submitting PRs which get tested just like other PRs and run
through the same test suite.  And on that topic, coreos-assembler contains not just
*build* tooling but also *testing* tooling.  Our single (yeah it's big) container
image has everything you need to run all our build *and* tests as a single versioned unit,
which runs completely as non-root with unprivileged podman; no need to touch the host (or
for that matter, depend on Fedora as the host system at all, though the container is
Fedora based the current pipeline uses RHCOS).

Hm well I was just trying to talk about Ignition and SELinux but more ended up here =)

[Adam Williamson]

On Thu, 2020-12-03 at 15:22 -0500, Colin Walters wrote:
>  
>  On Thu, Dec 3, 2020, at 2:48 PM, Adam Williamson wrote:
>  
>  > I dunno when's the last time anyone tried without it, tbh.
>  
>  For CoreOS we spent a *lot* of time ensuring that Ignition has first class SELinux
> support, and actually making it work on the Live ISO in a not-horribly-hacky way required
> a kernel patch:
>  https://lore.kernel.org/selinux/[e-mail]/... 
I meant for the anaconda-based liveinst, not for ignition...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Josh Boyer]

On Thu, Dec 3, 2020 at 1:59 PM Colin Walters <walters(a)verbum.org&gt; wrote:
>  On Wed, Dec 2, 2020, at 12:19 PM, Adam Williamson wrote:
>  >
>  >
>  > What does the question "is Fedora CoreOS 34 ready to go" even mean, in
>  > the context of how CoreOS is built and released? What set of bits will
>  > we be deciding to ship or not ship, and how will that have been decided
>  > and communicated? Where will we look to find the test results and
>  > criteria on which we would base that decision?
>
>  There are a whole lot of aspects to this, but one angle to look at this from is that I
> personally have always thought the way Fedora uses pungi up until releases and
> everything's about a "compose" and then it switches to a Bodhi wild west
> where updates are unversioned things that can release at any time...well, it doesn't
> make much sense.
>
>  The concept that you have boot media that can reach 6 months old is a very bad
> anti-pattern because there are often periods of time where the software there has security
> vulnerabilities.  *Particularly* for a desktop system starting up a 6 month old web
> browser is just actively dangerous.
>
>  Now I understand there are reasons traditional Fedora does this - among them that
> Anaconda is a huge thing on its own.  But for FCOS we made a massive simplification - the
> "Live" FCOS *is the same thing as the OS*.  Our `coreos-installer` is just a
> glorified `dd` wrapper (mostly) and all system provisioning logic happens in Ignition,
> which we're constantly testing all of the time.
>  (Personally I'm really proud that for example our Live ISO ships with SELinux
> enforcing)
>
>  FCOS currently respins both an ostree commit and boot media every release, and because we
> use coreos-assembler all the time, those are all strongly versioned together and
> consistent.
>
>  Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that our OS
> build and test process runs natively via podman and Kubernetes (unprivileged).  We're
> telling people to use containers; building the operating system shouldn't require you
> to `yum install` (or even `rpm-ostree` install stuff directly on a host system.  Our
> current build pipeline is Jenkins-running-in-OpenShift; we're actively working on
> removing Jenkins from the equation in some circumstances and making the whole thing even
> more Kubernetes-native.  This is not at all true of the Koji/pungi stack. 
Is that difference really split along tooling lines?  I'm not sure it
is.  You could use pungi to build updated installation media every
time there's a push of updates.  We just... don't.

This seems more split on the OS consumption model to me, rather than
the tools to make it.  The end user shouldn't care at all about what
tools make it.  They just want to install their OS and keep it updated
and have those updates NOT BREAK their systems or apps.  ostree based
OS updates have some inherent benefits that a per-package update model
lacks and I find it intriguing because you could test a whole OS
update stack to at least ensure it's consistent within itself.
Whether that happens or not is up to the creators of the OS.  You can
do the same with bodhi but we... don't.  Neither set of tools can
really claim to validate the updates won't break third party apps
though.

(There is the whole pets vs. cattle dynamic too, but I'm not sure that
matters much either.  The basic requirements should be the same
between both: I install or update my pet or cattle and my stuff keeps
working unless I want to migrate to something newer).

josh

[Adam Williamson]

On Thu, 2020-12-03 at 14:14 -0500, Josh Boyer wrote:
>  > 
>  > Beyond the pungi-vs-bodhi thing of course, to me it is also very fundamental that
> our OS build and test process runs natively via podman and Kubernetes (unprivileged). 
> We're telling people to use containers; building the operating system shouldn't
> require you to `yum install` (or even `rpm-ostree` install stuff directly on a host
> system.  Our current build pipeline is Jenkins-running-in-OpenShift; we're actively
> working on removing Jenkins from the equation in some circumstances and making the whole
> thing even more Kubernetes-native.  This is not at all true of the Koji/pungi stack.
>  
>  Is that difference really split along tooling lines?  I'm not sure it
>  is.  You could use pungi to build updated installation media every
>  time there's a push of updates.  We just... don't. 
Right. It's a choice, not a capability thing.

At this point I think there are two reasons for the choice:

1) It *does* take a long time to produce a full compose, and doing that
for every update push for every stable release might overwhelm
capacity, I think

2) We don't have the capacity to test full composes very frequently to
the level we test "stable releases"

2 is really the awkward one. It's not really a showstopper, but it
comes with awkward questions. We could respin every month and go
through a full validation process, but that would be a huge lift and
eat up basically the whole of QA's time (and probably a lot of
releng's, and various other people) and we'd probably still miss stuff.
We could produce respins on some sort of schedule and run them through
automated testing and maybe some light manual validation and put them
out on some kind of "use at your own risk" basis, but there the devil
is in the details, particularly of communication. How exactly do you
sell the message "these images are PROBABLY actually a bit better than
the release ones, and they're almost certainly more secure, but we
can't really entirely stand behind them and if you have some problem
with them we're going to tell you to use the official release image
instead"? It's a tricky bit of communication to do successfully. Even
still, we might want to try it. I dunno.

But at that point we've gone a bit off the original topic, and there I
think Colin hit the nail on the head with "for FCOS we made a massive
simplification". Which is a nice thing to be able to do ;) For the
thing called "Fedora", we can't really make all those simplifications,
because of existing expectations and commitments. So this goes back to
my big point: when we make "Fedora CoreOS" a key part of the thing
called "Fedora", we have impedance mismatches, and here's another. The
thing called "Fedora CoreOS" has made these simplifications in
deployment: it's massively restricted what "deployment" means, in terms
of what gets deployed where and how. That gives it quite a big payoff
in various ways in terms of how development and testing and release can
be done. But we really don't have those options for the whole of the
thing called "Fedora", not on any sensible timescale at least. Unless
Josh wants to start getting really radical about RHEL 9...:D
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Colin Walters]

On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote:

>  This seems more split on the OS consumption model to me, rather than
>  the tools to make it.  The end user shouldn't care at all about what
>  tools make it.   
I've been meaning to write a longer blog post on this but briefly:

How you build software gets very entangled with how you ship it, and how you ship it gets
entangled with how users consume and manage it.  It's really this dynamic that has
created so much inertia around traditional dpkg/rpm/etc., and also is already happening in
the container ecosystem too around Kubernetes (the fact you don't do in-place updates
there but schedule a new pod deeply impacts configuration/management).

The fact that FCOS releases are uniform and constant and biweekly feeds into a whole lot
of things across that stack.  The concept of a "stream" was brought up and
that's quite central too, along with the Cincinnati staged rollout system.

>  They just want to install their OS and keep it updated
>  and have those updates NOT BREAK their systems or apps.  ostree based
>  OS updates have some inherent benefits that a per-package update model
>  lacks and I find it intriguing because you could test a whole OS
>  update stack to at least ensure it's consistent within itself. 
Not "could" - that's the basis of our technology stack and how we think and
operate.

>  Whether that happens or not is up to the creators of the OS.  You
> can
>  do the same with bodhi but we... don't.  Neither set of tools can
>  really claim to validate the updates won't break third party apps
>  though. 
We expect applications run as containers.

[Josh Boyer]

On Thu, Dec 3, 2020, 4:11 PM Colin Walters <walters(a)verbum.org&gt; wrote:

>  On Thu, Dec 3, 2020, at 2:14 PM, Josh Boyer wrote:
>
>  > This seems more split on the OS consumption model to me, rather than
>  > the tools to make it.  The end user shouldn't care at all about what
>  > tools make it.
>
>  I've been meaning to write a longer blog post on this but briefly:
>
>  How you build software gets very entangled with how you ship it, and how
>  you ship it gets entangled with how users consume and manage it.  It's
>  really this dynamic that has created so much inertia around traditional
>  dpkg/rpm/etc., and also is already happening in the container ecosystem too
>  around Kubernetes (the fact you don't do in-place updates there but
>  schedule a new pod deeply impacts configuration/management).
>  
Yes.


>  The fact that FCOS releases are uniform and constant and biweekly
> feeds
>  into a whole lot of things across that stack.  The concept of a "stream"
>  was brought up and that's quite central too, along with the Cincinnati
>  staged rollout system.
>  
Also yes!


>  > They just want to install their OS and keep it updated
>  > and have those updates NOT BREAK their systems or apps.  ostree based
>  > OS updates have some inherent benefits that a per-package update model
>  > lacks and I find it intriguing because you could test a whole OS
>  > update stack to at least ensure it's consistent within itself.
>
>  Not "could" - that's the basis of our technology stack and how we think
>  and operate.
>  
Right.  It's not a property inherent to the tool you use to build though.
"Could" means something else could do that as well.


>  > Whether that happens or not is up to the creators of the OS. 
> You can
>  > do the same with bodhi but we... don't.  Neither set of tools can
>  > really claim to validate the updates won't break third party apps
>  > though.
>
>  We expect applications run as containers.
>  
There are still interfaces between the container and the host.  They can
still break things.  I do agree that ostree and the deployment model coreos
is using as a host has really good mitigation for application stability
though.

Outside of that, if one were to run applications directly on the host,
there is a larger surface area that can break.  I think it is interesting
to see what enterprise distros accomplish around this problem and where
they fall down.  Fedora is even further away in this regard, but that's a
conscious choice of the project.

josh

[Kevin Kofler]

Ben Cotton wrote:
>  This changes is to promote Fedora CoreOS to Edition status alongside
>  Workstation, Server and IoT. 
IMHO, Fedora CoreOS is still an experiment with way too many limitations and 
drawbacks to warrant Edition status.

Don't get me wrong, it is nice to have a place for experiments, and this is 
an important way to drive innovation, but one needs to distinguish between 
an experiment and a product, and accept that not all experiments succeed at 
eventually becoming products, ever. Declaring something an Edition will not 
magically make it readier for user consumption.

        Kevin Kofler