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(a)redhat.com