On Thu, Apr 12, 2018 at 4:00 PM Neal Gompa <ngompa13@gmail.com> wrote:
Hey all,

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.

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?

Best regards,
Neal

[1]: https://forum.snapcraft.io/t/introducing-base-snaps/381
[2]: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap



I had a conversation with Neal and Zygmunt this morning in #fedora-server. We went over the necessary steps for creating a base snap and such and I'm pretty confident that they have a good handle on it.

What they would like to do (and I support this) is get the proof-of-concept base snap creation scripts cleaned up and added to the standard Fedora compose, under the Fedora Server umbrella. I'm CCing Mohan Boddu on this message to get him involved. Neal and Zygmunt are volunteering to do most of the work, with assistance provided where needed on integrating with the compose process.

As we're looking at treating this as a Fedora Server deliverable (with the associated branding), we need to open a vote.

Proposal: Beginning with Fedora 29, the Fedora Server SIG will produce a base snap image for Snappy. This image will not be blocking for the Fedora 29 release. Upon approval of this proposal, Neal Gompa and Zygmunt Krynicki will discuss the plan with rel-eng and upon rel-eng approval will submit a Fedora Change Proposal announcing their intention.

The proposal will be considered accepted as long as it receives three +1 votes and zero -1 votes within the next week.