> 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.
So I have a problem with the fact that you appear to be answering for
rel-eng (yet again) and appearing to commit them to doing something
that hasn't going through the standard Change process.
Where is the the Fedora change? Where is the assessment of the changes
that are needed here for FESCo to approve?
With my old rel-eng hat on the needed integration with the compose
process would be:
* ability to build the artifacts in koji, I suspect this will be image
build via imagefactry with appropriate reporting of the contents into
PDC
* pungi so that the compose process can build the above images
* bodhi integration so as to be able to compose updates when things
like CVEs occur
The above it needed so that it can integrated in the compose process,
but also so we know what's in them so we know if they need to be
regenerated in case of CVEs etc.
Probably also need some ability to push the base image to what ever
repository snaps have so people that use them can choose them to build
their apps on (else what is the point?)
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.
Well the change process actually has the rel-eng sign off so it's sort
of putting the cart before the horse, but while there's snap support
I've not seen any patches around the integration into
imagefactory/koji/pungi which is the core compose process. I feel
these patches should be posted and accepted before the process goes
forward, or at least be documenting and have the teams that would need
to provide them agree. Traditionally these sorts of things have
generally come from those wanting the feature and aren't the job of
rel-eng to code and deliver (they seriously have more than enough to
deal with on a day-to-day basis) and rely on tools that are maintained
by a number of teams outside of rel-eng.
The proposal will be considered accepted as long as it receives three
+1
votes and zero -1 votes within the next week.
I've no idea if I have a vote, which no doubt means I don't, but I'm -1
I feel this is a diversion of other things that the Server Working
Group should be focusing on like making Modularity amazing.
I'm also very unclear as to what value a base Snap provides to the
Server WG. I mean sure it provides the ability for someone that wishes
to use the Snap delivery mechanism to use Fedora with in that "base
container" to build their application on to run in the, IMO rather
small, eco system that is the Snap ecosystem, but to run those on the
Server WG deliverable is shipping the appropriate runtimes part of the
proposal? I think it should be a similar but related change. If it's
not part of the proposal why is it useful to the Server Working Group?
Ultimately I feel it adds a diversion and/or distraction to other
things the Server WG should be focusing on like the widely open and
already adopted OCI container mechanism, modularity, orchestration
through tooling and other such things.
Peter