Fedora Ring 0 definition

[Brendan Conoboy]

On 09/02/2015 12:24 PM, Adam Miller wrote:
>> On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
>>> For today's meeting we didn't really use zodbot minute keeping
>>> features, so in the interest of sparking some discussion I'd like to
>>> recap.
>>>
>>> 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:
>>>
>>> 1. Ring 0 is a repository of rpm packages built in koji.
>>>
>
> +1
>
>>> 2. Ring 0 contains, but is not limited to, the minimal install of
>>> packages to go from Power On to a login prompt.
>>>
>
> What's the definition of login prompt here? Is the discussion around
> targeting GDM or just a getty from systemd-logind.service?

I was thinking systemd-logind.service.  Keeping the GUI stack out of 
ring 0 seems highly 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).
>>>
>
> +1
>
>>> 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.
>
> Do you mean that BuildRequires don't need to be members of Ring 0 in the above?

Yes.  Restated: Packages listed in 'BuildRequireis' do not need to be 
members of Ring 0.  Minimizing the number of such requirements is 
highly desirable, however.

[snipped +1s]
>>> 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.
>
> +1 - I like the idea of formulating a definition of what these things mean.
>
> I think having Ring0 as a deliverable entity and the core building
> block that all "editions" are built from is a great idea. The way this
> works out in my head is effectively that Workstation, Server, and
> Cloud would be built on top of Ring0 and it could also carry over to
> the spins. Possibly, later in life, allowing the "higher level" bits
> that everyone in the different SIGs care about to move more
> quickly/independently of Ring0. Is that more or less where this is
> going or am I off in crazy town?

That's definitely one of the directions I think this goes: Once you 
break up ring 0 and ring 1 policies you can start thinking about ways 
in which release cycles decouple, or even having longer support terms 
for lower rings.

> Thanks for the recap and +1 for the re-introduction with a new title :)

Thanks!

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