Fedora Ring 0 definition

[Brendan Conoboy]

On 09/07/2015 05:21 AM, Miloslav Trmac wrote:
> 2015-09-02 23:24 GMT+02:00 Brendan Conoboy <blc at redhat.com
> <mailto:blc at redhat.com>>:
>
>     [blc]
>     >> 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.
>      > [simo]
>      > 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 ?
>
>     [blc]
>     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.
>
>
> (Sorry, I have not been following the conversation over the months in
> detail, have not seen the Flock presentations, and I may well be
> missing something. But still, it seems worth asking for a sanity check.)
>
> The whole conversation seems to me rather confusing, and more likely,
> just confused.
>
> How did we end up (or at least it seems that way) with a consensus
> that we will have policy rings, i.e. organization into ideal subsets,
> and a consensus that they will be based on SRPMs, and perhaps even a
> tentative consensus that the rings should be transitively closed over
> BuildRequires, /without any consensus on what the rings are?!/

We don't have a consensus yet, that's part of what the discussion is 
about.  What we have so far is a general idea that E&S roughly oversee 
how the rings interact and distinct groups should have input into the 
definition of each of the rings.  Ring 0 looks roughly like the Base 
WG's domain.

> AFAICS somehow the goals and means have gotten confused, and we are
> trying to find goals that would make sense in a specific
> implementation method; that’s completely backwards.
>
> Thinking about a few possible goals¹:
>
>   * They have /nothing/ to do with SRPMs—actually even the concept of
>     “source code” does not appear—and most of the policies are not
>     inherently tied to SRPMs; they could just as well be specified,
>     documented, tested or enforced in terms of a whole installed
>     system, or in terms of individual elements. We /might/ want to
>     ultimately /implement/ the policies in terms of SRPMs, but the
>     /goals/ are not in terms of SRPMs, so thinking about the policies
>     in terms of SRPMs is unnecessarily restrictive.
>   * There is no subset/superset relationship between SRPMs, or
>     individual files, implementing these goals; the goals are not even
>     in terms of files!
>
> Let’s think about the/produced artifacts/, whatever that is, first:
> decide what we want to achieve by the policies, and what the desired
> and practical policies would be. /Then/ would be an appropriate time
> to check for subset/superset relationships and other ways to
> inherit/share effort; /not/ at the very start of the definition process!

You are right that we do need to think about overall goals to be 
achieved, then the policies that achieve those goals.  For my part I 
am interested in distinguishing the OS from the applications that run 
on top of it.  This might be the difference between ring 0 and ring 1. 
  It's too early to tell, though.  During today's base wg we talked a 
little bit further about possible goals that a ring 0 might fulfill 
(http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-14/fedora_base_design_working_group.2015-09-14-14.15.log.html). 
  A few hypothetical possibilities as examples:

1. Make a "Base" (or ring0) compose who has its own alpha/beta/ga 
cycle that precedes the RC deadlines for the current editions and 
spins, providing a stable set of NVRs to base upon.

2. New boundaries for primary/secondary arch blocker status, rules for 
excludearch, threshold for inclusion in primary koji, etc.

3. Decouple the ring 0 release cycle and support terms from the 
editions.  Maybe base comes out every 4 months. Or 9 months.  Maybe 
it's supported for 24 months.  Things like that- it's small.  Editions 
and spins can pick the base release to build on.

> Also, it seems to me that it would be useful to, at least
> conceptually/,/ to not think about Fedora as a self-hosting perpetual
> motion^Wrecompilation machine, but as “just another huge application”
> being built using compilers and other tools which come from
> $some_other_magic_place. That’s not to say that self-hosting is not
> valuable—it is a critical property of the subset of the Open Source
> ecosystem which Fedora distributes—but it is more of a property of the
> /ecosystem/ than the /produced artifacts./
>
> In particular, I am fairly baffled by the idea that “ring 0 should be
> self-hosting”: it automatically leads to a huge ring 0, and together
> with the implied hierarchy of rings it implies that other smaller
> functionality/policy subsets don't fit into the model and can’t be
> considered (the SRPM granularity makes it much worse but it is bad
> even without it).  Instead of “/bin/bash and the compiler used for it
> need to be frozen and stable in the same way”, which doesn’t even make
> much sense (/bin/bash needs to have a stable UI, the one component of
> a compiler which we want to be improving and do not need to be
> stable), we could, for example, freeze all “compilers and build tools”
> (yet another artifact group which defies hierarchy) at Alpha time²,
> and take them completely out of the policy picture from then on.

Er, the idea was that ring 0 is *not* self hosting, rather that a 
compose of ring 0 satisfies its own dependency requirements.  The 
further result of this thread is that the compose of ring 0 might 
contain only some subpackages from the source material, to further 
limit the size of the compose and dependencies pulled in.

> /Then/ we could start thinking about /truly minimal/ concepts,
> perhaps  “container minimal” = “the minimal set needed to start and
> run an executable dependent on Fedora ABI” (e.g. kernel version
> requirement +glibc+locale data+Python 3 interpreter+…, useful for
> building containers), “VM minimal” could be “the minimal contents of a
> VM needed to start and run…” (e.g. kernel
> implementation+init+container minimal, useful for single-app VM), “CLI
> minimal”, …
>      Mirek

Right, so I don't think minimal is the end goal, I think the OS (not 
the distribution) is the end goal- minimal is presumably a subset of 
the OS.

> ¹ (I am /not/ seriously proposing these or willing to debate these;
> just as an example of what we /might/ want.)

[great examples of things to dicuss]

Are you saying we might want to consider these but you personally 
don't want to own the discussion? Not clear on why you've put them out 
there but advised against debate.

> *ABI:*
>
>   * *Goal:* There is a well-defined ABI of “The Fedora operating
>     system” available in any Fedora installation. The API has a
>     defined stability promise, lifecycle policy, and
>     deprecation/versioning/transition mechanism, so that any author of
>     an application (FOSS or binary-only) knows what interfaces are
>     appropriate to use so that the applications continue to work and
>     be useful to their users.
>   * *Possible Scope:* glibc’s strcpy(), D-Bus protocol 1.0 on the
>     system and session bus, libgcc.so ABI as of $version, the
>     org.freedesktop.PolicyKit1.Authority D-Bus service, kernel’s
>     /proc/self/attr/* files. Not glibc’s strfry(), D-Bus over IP,
>     format gcc’s standard output, contents of /sys/kernel/debug.
>   * *Implementation: *Document the stable ABI, have a policy of
>     requiring independent regression tests of the ABI and of not
>     breaking the ABI. Document best practices for
>     versioning/transition (perhaps e.g. file formats may not be in the
>     ABI because they can’t be effectively versioned.)
>
> *Administration Interface:
> *
>
>   * *Goal:* There is an efficient way to administer large numbers of
>     Fedora machines in an automated way.
>   * *Possible Scope:* A specific set of “blessed” ansible modules. A
>     $specific_way how to have an installed Fedora system listen on
>     port 22 and accept a specified private key to authenticate as
>     root. Not a commitment to keep /etc/ssh/sshd_config unchanged so
>     that (echo $foo >> /etc/ssh/sshd_config) can be relied upon.
>   * *Implementation: *Document the provided tools, and the scope of
>     what features are expected to be supported by them; have a policy
>     of not accepting features within the documented scope if they can
>     not be managed by these tools.
>
> *User Interface:
> *
>
>   * *Goal:* It is easy to use Fedora, and easy to learn it because its
>     user interface is consistent and well thought-out.
>   * *Possible Scope:* The default desktop and default applications
>     implementing a specific set of functionality, all CLI utilities
>     included in the Administration Interface above. Not “alternative
>     desktops”, ZX Spectrum emulators, GUI applications installed by
>     default but having their menu icons hidden.
>   * *Implementation:* Have a HIG for GUI and CLI, and a policy of only
>     accepting components within scope if they comply. Recommend UX
>     designer involvement for every application in scope.
>
>
> ² This is an obvious but extreme, and probably unwanted, example. We
> probably want some kind of stability for build tools while allowing
> them to be fixed during the release cycle; but it is not obvious at
> all to me that the policies for build tools and built artefacts should
> be the same; e.g. the Bodhi karma system seems to be a poor fit, a
> “does not crash when run” smoketest is completely useless, and we seem
> to have the tools and resources to just use the updated build tools
> for a test mass rebuild to verify their functionality instead, which
> would not apply to non-build-tool artefacts.
>
>
>


-- 
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.