Fedora Ring 0 definition
Brendan Conoboy
blc at redhat.com
Wed Sep 2 20:28:09 UTC 2015
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
More information about the devel
mailing list