Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Petr Pisar]

On 2015-08-31, Brendan Conoboy  wrote:
> 2. Ring 0 contains, but is not limited to, the minimal install of 
> packages to go from Power On to a login prompt.
>
I hope you mean a getty. Not a display manager with a greeter.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Harald Hoyer]

On 27.08.2015 14:36, Harald Hoyer wrote:
> Agenda:
> 
> - Fedora.Base - RHEL.Base - Flock recap
> - Ring 1 vs Ring 0
> - define the minimal install (continued)
> - define the docker base image (continued)
> - minimal disk image for importing into libvirt (continued)
> - generic installer? (continued)
> - Open Floor
> 
> Please add items by replying to this mail.


Minutes:

Minutes (text):

Log:

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Brendan Conoboy]

On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]

Minutes:

Minutes (text):

Log:



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. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Simo Sorce]

On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:
> On 08/31/2015 08:17 AM, Harald Hoyer wrote:
> [snip]
> > Minutes:
> > 
> > Minutes (text):
> > 
> > Log:
> > 
> 
> 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.

Can you elaborate more on this point (5) ?

I can totally see how a package may be critical and therefore deserve to
be in ring 0 and yet have optional features in terms of subpackages that
are not necessarily ring 0.
For example some library that offers optionally bindings for somewhat
rarely used languages (say ocaml). The subpackages for those bindings
shouldn't necessarily be ring 0.

Or did I misunderstand the point ?

> 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. / b...@redhat.com


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Brendan Conoboy]

On 08/31/2015 11:41 AM, Simo Sorce wrote:

On Mon, 2015-08-31 at 10:18 -0700, Brendan Conoboy wrote:

On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]

Minutes:

Minutes (text):

Log:



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.


Can you elaborate more on this point (5) ?

I can totally see how a package may be critical and therefore deserve to
be in ring 0 and yet have optional features in terms of subpackages that
are not necessarily ring 0.
For example some library that offers optionally bindings for somewhat
rarely used languages (say ocaml). The subpackages for those bindings
shouldn't necessarily be ring 0.

Or did I misunderstand the point ?


Let's take gcc for example.  The gcc package produces numerous 
subpackages including various compilers and libraries.  One of those 
libraries, libgcc, is linked into nearly every dynamically linked ELF 
executable on your system (Run ldd to confirm), including /sbin/init. 
 Since we really want /sbin/init to function we need to include 
libgcc in ring 0.  Since ring membership is at a source level rather 
than a sub-package level, gcc is ring 0.  There are other good 
arguments for the executable-generating tools living in ring 0, but 
this one illustrates the point.


Ring policies might include things like how long the package is 
supported, what build system can generate it, what release cycle it is 
on, what the packaging guidelines are, what the updates rebase policy 
is, and so forth.  These types of policies apply to source rpms as a 
whole.  You can't apply one to gcc-c++ and another to libgcc.


I think the question you are posing might be, in the context of gcc, 
might be: Does gcc-g++ need to appear in the same repository as 
libgcc? IE, can we decouple what we build from what is presented to 
users?  If the threshold for must-include is repoclosure then no, we 
don't need to include gcc-c++, we only need to include libgcc and make 
gcc-c++ available elsewhere.  In talking to Langdon about 

[Base] Base Design WG agenda meeting August, 31st 2015 14:15 UTC on #fedora-meeting-2

[Harald Hoyer]

Agenda:

- Fedora.Base - RHEL.Base - Flock recap
- Ring 1 vs Ring 0
- define the minimal install (continued)
- define the docker base image (continued)
- minimal disk image for importing into libvirt (continued)
- generic installer? (continued)
- Open Floor

Please add items by replying to this mail.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct