On Fri, Apr 13, 2018 at 9:39 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
> As some of you may know, one of the upstream projects I work with
is
> the Snappy/Snapcraft system.
>
> Recently, the Snappy system gained full support for having alternative
> base/runtimes used for the basis of snaps[1]. Given the design of the
> Snappy system, it makes it very easy for us to provide a model in
> which people can build applications and services using Fedora in a
> manner where it's available in a cross-distribution fashion. One of
> the key advantages here is that we do not need to rebuild RPMs to
> retrofit them for the snap model, they can be directly sourced and
> installed as components to build a snap.
>
> However, to be able to do this, Fedora needs to provide what is known
> as a "base snap". The base snap provides the foundation for
> applications and devices to be built using Fedora software with snaps.
> Historically, the only "base" supported for general application use
> has been the Ubuntu one shipped by Canonical, but snapd recently
> learned how to use different "base" runtimes for different snaps.
>
> I believe we have an opportunity to be a great enabler for offering
> the latest and greatest technologies for developers to consume for
> their software if they want to distribute it as a snap. While the
> Fedora Workstation WG has been primarily focused on Flatpaks for GUI
> applications, snaps are useful for more than desktop applications.
> Indeed, some of the most interesting uses are involved with server and
> embedded systems software.
You can also use other container formats in the Server and Embedded
space like OCI or docker style containers.
Yes, but those are centered around fully separating the application
from the host, rather than offering flexible points of integration
between the application and the OS, similar to how Flatpaks do for
desktop applications. For example, while it is possible to make
OCI-style containers run "like" services, they typically don't behave
that way. The base runtime must be "booted up" and then the service
inside can be executed. It's opaque from the host, appearing as a
single container thing, rather than the service inside. In contrast,
snaps appear and function more or less like regular software packaged
via RPMs do. They interact with system services directly (through the
mediation provided by snap-confine), and their processes are fully
transparent and show up normally in standard process monitoring tools.
In this model, you get the benefits of independent life cycling while
still being able to do integration with the host system without
bending over backwards with weird hacks to connect the two OS
environments.
> I've worked closely with the upstream developers (of which
Zygmunt
> Krynicki is the main point of contact for Fedora with the Snappy team
> and is CC'd to this email) to ensure that this functionality is
> available to us in a way that allows us to leverage our software as
> effectively as possible. In addition, I've built a relatively trivial
> application[2] to build proof of concept core base snaps with Fedora,
> Mageia, and openSUSE packages.
>
> At least initially, some of these first application snaps will be
> produced in a rather simple manner as we would work with upstream on
> figuring out how to adapt Snapcraft to handle alternative bases. My
> eventual goal is to be able to produce a Modular Fedora variant that
> works off snaps, using our software packaged as RPMs as inputs, as a
> variation of the modularity work going on in Fedora as a whole. This
> work would be more or less similar to the efforts for producing the
> Cloud Base images that are used in cloud providers and for container
> systems to use (e.g. Docker/OpenShift/Kubernetes).
>
> I discussed this with Stephen Gallagher, and he seemed amenable to the
> idea of the Server WG producing the base snap as a deliverable and
> publishing it to the snap store so that it can be used to build
> applications. He suggested that I bring this to broader WG mailing
> list to solicit some feedback on this.
>
> So what do you all think?
Who's going to do the engineering needed to be able to build the base
snap in the Fedora infrastructure like all the other Fedora produced
artifacts?
I've already started on this particular effort, but I hope to leverage
the work done for the Fedora Cloud Base images to simplify things on
the whole. The base snap is a subset of what we ship for Fedora
container base images as well, as the goal is to provide enough of
Fedora to function as a base runtime environment for Fedora-based
snaps.
Do you still need to disable selinux or set it to permissive (I
don't
remember what the exact requirement was there)?
That hasn't been necessary for the last two years, since I contributed
and help maintain an SELinux module for snapd.
--
真実はいつも一つ!/ Always, there's only one truth!