Fedora Ring 0 definition
Brendan Conoboy
blc at redhat.com
Wed Sep 2 18:59:55 UTC 2015
Re-sending this with a better title so people might read it ;-)
On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
> On 08/31/2015 08:17 AM, Harald Hoyer wrote:
> [snip]
>> Minutes:
>> <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html>
>>
>> Minutes (text):
>> <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.txt>
>>
>> Log:
>> <http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.log.html>
>>
>
> 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.
>
> 2. Ring 0 contains, but is not limited to, the minimal install of
> packages to go from Power On to a login prompt.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
--
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com
More information about the devel
mailing list