Fedora Ring 0 definition

[Brendan Conoboy]

On 09/02/2015 12:24 PM, Josh Boyer wrote:
> On Wed, Sep 2, 2015 at 2:59 PM, Brendan Conoboy <blc at redhat.com> wrote:
>> Re-sending this with a better title so people might read it ;-)
>
> I read it last week.  Perhaps the lack of commentary isn't because of
> the title.  It's because there is nothing new here.  The proposal
> boils down to "collection/classification of packages that are
> important."  There is nothing about how to actually start here.  See
> below.

Perhaps it's a combination of both, but the repost has definitely 
gotten more replies.  Comments inline below.

>>> At Flock 2015 there was a 2 hour session on the subject of rings which
>>> are basically policy zones inhabited by packages.  Right now fedora
>>> packaging has 1 policy, so the entire OS is in a single ring. Creating
>>> more rings means creating more policies.  By doing this Fedora can
>>> become adopt the flexible to appeal to diverse development communities
>>> and thus grow.  The general consensus at Flock was that Environments
>>> and Stacks should take the lead in helping to define new rings, and
>>> especially how the rings interact.  As a side note, everyone agreed
>>> the word "rings" breaks down the further you get away from the center,
>>> but nobody has come up with something better yet (Venns? Blobs?
>>> Zones?).  A week or so ago, a small Environments and Stacks meeting
>>> took place where it was generally agreed that the Base working group
>>> was the right place to define Ring 0.  That brings us to this
>>> morning's BaseWG meeting.  I talked a lot so here is a rough recap
>>> integrating a few of the questions and comments people had (Do read
>>> the log if you have time!)
>>>
>>> Right now the Fedora distribution is 1 ring, let's call it ring 1. The
>>> distribution contains an operating system and numerous applications
>>> that run on that operating system.  When we talk about defining ring 0
>>> we're really talking about distinguishing between the operating system
>>> and the applications that run on top of it.
>>>
>>> We want to go from this:
>>>
>>> Ring 1: The Fedora Distribution
>>>
>>> To this:
>>>
>>> The Fedora Distribution:
>>> Ring 0: The Linux Operating System
>>> Ring 1: The Applications and Stacks
>>>
>>> It seems quite modest, but working through the details on what this
>>> means is hard.  What is an operating system in the Linux context? Ring
>>> 0 will likely have the strictest set of policies of all the rings, so
>>> we want to keep it as small as possible, but it is more than a minimal
>>> install.  These are the traits of rings in general and ring 0 in
>>> particular as I see it:
>
> The original incarnation of the Base WG defined this already.  How
> does your definition differ?  For that matter, how does your
> definition differ from the existing critpath concept that is already
> implemented in bodhi?

These are good questions, but perhaps premature.  Here's another: What 
is the ongoing purpose of the current Base WG?  This discussion may 
serve as a focal point for some of its next steps.  The discussion at 
flock was, everybody wants to move forward with rings, but they need 
to know the specifics, so that's what we want to accomplish.  I would 
like to see Fedora serve a broader base of users and new/existing 
developer communities- rings in general can do this, but I've only 
written about the ring0/ring1 split.

>>> 1. Ring 0 is a repository of rpm packages built in koji.
>>>
>>> 2. Ring 0 contains, but is not limited to, the minimal install of
>>> packages to go from Power On to a login prompt.
>
> Define login prompt.

Am thinking text login prompt, IE, served by systemd.  Keeping GUI out 
of ring0 seems desirable.

>>> 3. Ring 0 passes repoclosure on its own (Packages listed as hard
>>> "Requires" in a ring 0 spec file are themselves are implicitly ring 0).
>>>
>>> 4. Ring 0 is not self hosting.  Packages listed in "BuildRequires" do
>>> not need to be members of Ring 1.  This isn't ideal, but it's a
>>> practical consideration.
>
> These match the previous definition that the Base WG came up with.
> Nothing came of that except the dependency reduction work that a few
> people jumped into and Harald bravely carried on with.

Hopefully people aren't expecting everything to be brand new and also 
somehow a good idea.

>>> 5. Ring membership is at the source package level, not the binary
>>> package.  If one source package's binary/noarch sub-package is in ring
>>> 0, all sub-packages are in ring 0.
>
> Also the same as before.

Ah, but the compose question might be answered differently.

>>> 6. Ring 0 contains the minimal libraries that define the OS API/ABI,
>>> such as glibc.  This probably happens implicitly by #3, repoclosure.
>>>
>>> 7. Ring 0 contains the tools needed to update existing packages and
>>> install new packages.
>
> Which is where a lot of the bulk came from in the original definition.
> This brings in python at a minimum.  If by tools you mean "graphical
> updaters" then you're almost back to Ring 0 being Fedora distribution.
> So precise language is needed.

How about "1 CLI update tool such as DNF"

> (Also, the original definition included Anaconda because you need
> something to actually install Fedora Ring 0 with and that brought in
> GTK, etc).)

Again, it seems really desirable to keep the GUI stack out of ring 0. 
  The implications for anaconda or compose policy are a good thing to 
dig into.  It may be that we need to separate ring package maintenance 
policy from compose policy.

>>> That's the starting point, but it is by no means comprehensive.  The
>>> OS probably provides specific services beyond the ability to login,
>>> for instance.  Which styles of boot are supported?  Where does
>>> installation infrastructure like anaconda land?  This is equal parts
>>> philosophy and practicality.  Also, policies for ring 0 may differ
>>> from what Base has previously adopted: Do we create a ring 0 minimal
>>> compose since we already need to check repoclosure?  This might be a
>>> great way to refactor primary/secondary such that we can gracefully
>>> transition i686 down and secondary arches up.  Lots of opportunities,
>>> much to consider.
>
> That's what we said last time :)

What a relief, we're almost done ;-)

> Seriously, I'm not meaning to dissuade you at all here.  I'm
> suggesting that you do NOT wait for lots of people to chime in on what
> Ring 0 is and instead come up with a concrete definition for it.
> That's the what.  You're almost there.

Yes, but we want a thousand holes poked in it so we can improve it. 
That's the goal here.  And to bring about questions like "Will this 
let us adopt $POLICY what previously was not possible?" because 
defining rings is really just a boring mental exercise if it doesn't 
lead to letting us do new cool stuff we've prevented ourselves from 
doing previously.

> What is going to get you the most commentary comes after that.  The
> why and how.  Why is Ring 0 defined this way, and how is this proposal
> going to change things within the Fedora project/Fedora distribution?
>
> Answer those questions, particularly the impact to package
> maintainers, and you'll get a lot more feedback.  I promise.

Absolutely- thanks!


-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com