Fedora base snap for building Fedora-based snaps
by Neal Gompa
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
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 10 months
Chair needed: Server SIG Weekly Meeting (2018-04-17)
by Stephen Gallagher
I will be out of town tomorrow during the meeting and won't be able to
attend. Can someone else volunteer to chair the meeting? Mostly I just want
us to level-set on where we are as we enter Final Freeze.
4 years, 11 months
Criteria proposal: cover Server roles in upgrade criteria
by Adam Williamson
Preamble: I know we're planning to throw rolekit out entirely, but I
believe we're planning to continue to consider the actual functions
behind the roles (FreeIPA and postgres) as blocking, so I'd like to get
this done so we remember to include it in that change.
Postamble: Back in F27 cycle, specifically in the 2017-10-23 blocker
review meeting, we agreed to cover the release-blocking Server roles in
the upgrade criteria. That is noted here:
https://bugzilla.redhat.com/show_bug.cgi?id=1503321#c7
However, we never actually made the change. So, here I am proposing it!
We should change the Beta criterion 'Upgrade requirements' as follows.
Main text should go from:
"For each one of the release-blocking package sets, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
set installed."
to:
"For each one of the release-blocking package sets, and the package
sets for each of the release-blocking Server roles, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
set installed."
I think that's actually all the change necessary, as the bullet point
"The upgraded system must meet all release criteria" then requires that
the upgraded roles actually work.
Thoughts? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 11 months
Server SIG meeting (2018-04-10)
by Stephen Gallagher
I have a conflict today and won't be available to run the meeting. I think
it would still be good to have some more live brainstorming, so if someone
else could volunteer to start the meeting record and guide the
conversation, I'd appreciate it.
4 years, 11 months
Server SIG Weekly Meeting Minutes (2018-04-03)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-04-03)
================================================================
Meeting started by sgallagh at 20:00:17 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-03/serversig...
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 20:00:18)
* Agenda (sgallagh, 20:06:40)
* Agenda Item: Brainstorming (sgallagh, 20:06:46)
* Brainstorming (sgallagh, 20:07:36)
* Feedback: Fedora Server has too short a lifecycle (sgallagh,
20:08:35)
* Feedback: Fedora Server should be more minimalistic (sgallagh,
20:08:35)
* Feedback: SELinux needs better usability (sgallagh, 20:08:35)
* Feedback: Support OpenCL (sgallagh, 20:08:36)
* Feedback: Easy "home media server" would be nice (sgallagh,
20:08:36)
* Feedback: Cockpit should be able to control more of the system
(sgallagh, 20:08:36)
* Feedback: Focus on simplifying common task execution (sgallagh,
20:08:36)
* Feedback: Support enterprise HBAs (sgallagh, 20:08:37)
* We will go through the list individually (sgallagh, 20:11:46)
* Fedora Server has too short a lifecycle (sgallagh, 20:12:01)
* The core problem that people want to solve generally is "I don't
want my applications to break, because I rely on them" (sgallagh,
20:14:16)
* Rephrased: Core problem is "I want to be able to keep my system
up-to-date wrt bug and security fixes without my applications
breaking" (sgallagh, 20:16:35)
* Users automatically assume that the classic solution to this problem
is the only one: longer compatibility lifecycle for the whole OS.
(sgallagh, 20:17:34)
* Fedora Server attempts to solve the core problem with Modules and
reliable OS release upgrades. (sgallagh, 20:18:25)
* Enhancement proposal: automatically upgrade when release is EOL
(sgallagh, 20:22:03)
* Enhancement proposal supplement: Cockpit UI for scheduling the
automatic update after EOL (sgallagh, 20:23:11)
* Fedora Server should be more minimalistic (sgallagh, 20:27:38)
* This topic is really easy to get rat-holed on. Will revisit later.
(sgallagh, 20:40:44)
* SELinux needs better usability (sgallagh, 20:40:52)
* Cockpit SELinux Troubleshooter improvements would be ideal for this
(sgallagh, 20:43:59)
* Support OpenCL (sgallagh, 20:46:42)
* This task would require specialized expertise that isn't readily
available (sgallagh, 20:48:40)
* Easy "home media server" (sgallagh, 20:48:56)
* Server Focus (sgallagh, 20:55:07)
* Q: Is there a customer story similar to our previous OLPC effort
that we could get behind? (sgallagh, 20:55:41)
* LINK: https://freedombox.org/ ? (nirik, 20:56:01)
* ACTION: Homework assignment: Think of an OLPC-style initiative that
Server could back and present it next week. (sgallagh, 21:00:24)
Meeting ended at 21:04:33 UTC.
Action Items
- ------------
* Homework assignment: Think of an OLPC-style initiative that Server
could back and present it next week.
Action Items, by person
- -----------------------
* **UNASSIGNED**
* Homework assignment: Think of an OLPC-style initiative that Server
could back and present it next week.
People Present (lines said)
- ---------------------------
* sgallagh (129)
* dperpeet (46)
* nirik (39)
* smooge (13)
* bowlofeggs (11)
* orc_fedo_ (8)
* zodbot (7)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.0
Comment: https://www.mailvelope.com
wkYEAREIABAFAlrD7H0JEHolVWI2uqOjAABNHQCfcqkENOdc+3GL6IDtztb/
7uDD4GYAniSTQYmDy5RGNkZqFZU/lWWzOxjq
=uiPJ
-----END PGP SIGNATURE-----
4 years, 11 months
