Definition of word "ring"

[Nick Coghlan]

On 20 April 2015 at 23:56, Honza Horak <hhorak at redhat.com> wrote:
> I'd just add that the set is described by expectations we have about this
> set, so for example we can have:
>
> * stable libraries, that we don't expect breaking API/ABI but we expect them
> to be available for any upper ring -- those will be probably in ring 1
>
> * set of RPMs in ring 2 -- e.g. framework like Ruby on Rails, that makes
> sense to be available in more versions, but is not necessary for most of the
> other packages
>
> * another set of RPMs in ring 3 that don't follow all packaging guidelines
> -- e.g. application built in copr
>
> In other words -- when looking at which ring the artifact belongs to, we
> must look at what we expect from that artifact.

>From what I've seen, it's also about pace-of-change and the degree of
relevance the component has to what we're *specifically* working on.

Rings 0 & 1 - we expect these to be rock solid, and our main
requirement for them is "don't break anything". The kernel, systemd,
glibc, etc, they all live here. Fedora updates these and ring 2
components at around the same pace, but RHEL/CentOS slow ring 0/1
right down and RHEL offers long term maintenance support. Ring 1 may
also include "system" versions of particular ring 2 components (e.g.
the system Python interpreter). The key here is that out to ring 1, we
have a coherent, fully integrated system. From a distro perspective,
if a component is in the stripped down Fedora Atomic Host or Fedora
Cloud images, or in the base Server image, it's likely in Ring 0 or 1.

Ring 2 - here we start to see the emergence of application silos.
Language runtimes, database runtimes, web servers - tools like
Software Collections make it possible to coherently manage parallel
stacks that are supported by the distro, but don't provide the same
kind of close integration with the host OS that is the case for the
fully integrated components in ring 0/1. GUI application development
frameworks like Gtk & Qt would appear here, as would the full desktop
environments.

Ring 3: this is where even the community distros start to say that
folks are on their own from a support perspective. However, when
you're working directly in the relevant areas, you can make your own
decisions regarding supportability ofthe components you decide to use.
At this level, we've made the switch from forming part of the distro
itself to running *on* the distro.

I'd also say that *applications* or even *components* don't belong to
rings - rather, particular *versions* of components do. So Python 2.7
and 3.4 are currently both ring 1 components in Fedora 22, but 2.7 is
on its way to only being part of ring 2, while the upcoming 3.5 is
available as a nightly copr build in ring 3. If you extend the rings
analogy to RHEL/CentOS 7, then Python 2.7 would be ring 1, with Python
3 as ring 2 via Software Collections (and hopefully EPEL once
https://bugzilla.redhat.com/show_bug.cgi?id=1119761 is resolved). If
you go even further back to RHEL/CentOS 6, then Python 2.6 would be
ring 1, with both Python 2.7 and Python 3 as ring 2 via SCLs.

Particular images might also have requirements on what can be
included. Atomic Host, for example, might only allow Ring 0 & 1
components, with everything else being brought in via containers, and
similarly, Server might have only Ring 0 & 1 components in the base
image, with everything above that brought in via Rolekit. Fedora
Workstation, by contrast, we would expect to include Ring 2 components
by default.

Container images would typically span multiple rings from a distro
perspective - Rings 0 & 1 for the base OS image, Ring 2 for your
application runtime (etc), and then Ring 3 components for application
level dependencies managed by the application developers rather than
the system administrators.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia