A report from Fedora Flock

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

Flock to Fedora is the Fedora project's annual contributor conference, which is held in a different location each year. This year's conference brought together over two hundred participants in Krakow, Poland. Interesting topics at the conference included Fedora community direction, packaging modularity, and Atomic Workstation. The conference was sponsored by Red Hat, and somewhat surprisingly, by rival distribution openSUSE.

The main purpose of the conference is to allow the leading Fedora developers to get together and make decisions about the direction of the operating system. Thus, the schedule was about one-third meetings of some kind. Other sessions, like the Fedora Badge workshop, Internationalization of Atomic, or Education Outreach explained how to contribute to Fedora in specific ways. There were also some general-interest topics such as Kanban boards and Mailman 3 HyperKitty.

About one-quarter of the sessions involved Linux containers in some way. Fedora's future seems to be tied up with containers, as these sessions showed. So did the first keynote of the conference.

Community activity and changes to Fedora

Fedora project leader Matthew Miller started out the conference with a keynote about the last year of Fedora and plans for the next year. It was basically an update on his session from DevConf.cz 2016; it included a lot of statistics about the size of the community.

Each of the past three Fedora releases has been more popular than the previous, as measured by requests to the update server. Fedora 24, released in July, passed 100,000 connections in the first week. Downloads of ISO images are down, however, likely because of the introduction of easier in-place upgrading in Fedora 22.

On the "needs work" side, though, Fedora showed up as 1.3% of the user base in a recent Stack Overflow survey. As compared with 12% for Ubuntu, this shows that Fedora has a significant gap still to overcome.

Miller also counted Fedora's contributor base. For 2015, there were about 2000 contributors to packaging, the wiki, and reviewing patches in bodhi, which is Fedora's submission-management system. Almost exactly one-third of these are Red Hat staff. Unfortunately, he lacks numbers for other kinds of contributors, such as translators and Copr package maintainers.

In 2017, the project plans to stick to a May and October release schedule. If it misses a release date, the succeeding release cycle will be shortened to put the project back on schedule.

Fedora has also launched the Fedora Hubs initiative, creating a set of newcomer-friendly websites for its various sub-projects such as Fedora Design. While there is a lot going on with Fedora, it is largely invisible to visitors. "IRC and mailing lists are very geeky. We need to provide insight for the non-geeky," he explained. The new web portals will have easy-access information on the current activities and how to get involved.

Miller expects the Flatpak specification for sandboxed desktop applications to become a big part of how Fedora ships software. Flatpak, a freedesktop.org project, was launched publicly in July. Miller noted that application availability will be key to making this work, though, and appealed to the audience to help with Flatpak packaging.

Modularity

Langdon White updated attendees on the current status of Fedora's Modularity project. This is a major initiative for the OS, aimed at providing better package management and a better abstraction for users to manage application deployment and updates. It will also make it easier to mix stable and recent releases of software on Fedora machines, and to install different packages from different Fedora releases.

The project originally started with the "rings" proposal three years ago. The idea was to have an inner core of "highly curated" packages, a second ring of curated "stacks", and an outer ring of "apps" that would be largely created and maintained by third parties.

However, members of the project soon figured out that the "rings" concept wouldn't work. Whether users want stable or unstable software depends on what the user is doing, not which software it is. White pointed out that the owner of a static web site server for a 3-month-long movie promotion will use the latest web development software, whereas the administrator of an enterprise resource planning (ERP) server is going to want stability over features.

The new concept, "modules," provides an abstract concept for a "logical unit of software." This could be as simple as a shell, or as complex as a LAMP stack. Modules could be delivered as an RPM, or a set of RPMs, containers, or Flatpaks. Each module will consist of a set of structured metadata written to the modulemd specification. Separating the metadata from the binary packaging will allow users to install different types of packages.

Modularity isn't ready yet, though. Currently the developers have a plugin for the "dnf" package manager, which has replaced "yum" on Fedora. His team has alpha versions of a module-building pipeline with a UI based on Cockpit. The team is also working on a tool to convert existing RPMs to modules.

White concluded his presentation with a demo of installing modules. First, he had to enable the beta dnf module plugin, then could install a sample LAMP stack module:

# dnf module enable module:profile # dnf module install fm-lamp userdir

The second command installs the LAMP stack module. The "userdir" part is a "profile," which explains how you want the module installed. The module author creates one or more such profiles. In this case, it is telling Fedora to install it like a developer would, with the "public-html" directory in the user's home directory as the web root.

He also showed how simple it can be to switch to a module from a different version of Fedora. For example, say that you had the Fedora 25 version of the LAMP stack module installed, but you wanted to revert to the Fedora 24 version because WordPress wasn't compatible with the latest PHP, you could do this:

# dnf module rebase fm-lamp-24 userdir

White plans for modules to be ready for Fedora 26, in May 2017. He plans to be able to show the completed system at DevConf.cz 2017.

Container building

Another project introduced at DevConf.cz 2016 that is now coming to fruition is Fedora's Layered Docker Image Build Service. This new piece of Fedora infrastructure will support building and distributing official Fedora application container images, just like it currently builds and distributes RPMs. Adam Miller, who heads that project, explained its implementation details and status.

Most of the components to create Fedora's new service come from OpenShift Origin, particularly the OpenShift Build Service (OSBS). Since OSBS is designed to accept code from the public to build containers, it comes with a number of useful features like a Python API, input sanitization, and an enforced requirement for auditable parent images and source code. Particularly useful is automated rebuilds triggered by changes to parent or grandparent images, so that when a new major exploit is announced (such as a new glibc vulnerability, for example), all of the downstream containers will be rebuilt automatically.

A key part of getting the build service to work is the atomic-reactor tool, which builds multiple containers from a git repository and automatically pushes the resulting images to a registry. Integrated with koji, Fedora's general build-infrastructure tool, atomic-reactor enables automated container image creation alongside the RPM builds the system already does.

Like OpenShift, the service relies on contributors adding several "labels" in submitted Dockerfiles. For example, here's a set of labels one might use for a PostgreSQL Dockerfile:

LABEL BZComponent="postgresql" \ Name="fedora/postgresql" \ Version="9.5" \ Release="1" \ Architecture="x86_64"

The Bugzilla component and the name need to be decided by the Fedora community. The release number and the architecture will be set by the build system in the future. At present, only x86_64 is supported.

Miller demonstrated triggering an image build by updating its definition using the new user interface for the service. Administration is based on a combination of Fedora's fedpkg and the Cockpit UI builder.

The build system will be restricted to existing Fedora packagers initially. There are also a few restrictions on the kinds of images that Fedora is going to be able to build. Containers need to be based on RPM installs, not from source or language archives like Python's PyPI or Node.js's NPM. The Fedora project is trying to decide on additional guidelines and has a document up for discussion.

The container team is also trying to figure out how mirroring of container images will work. Fedora's MirrorManager currently can't use container image metadata to check dates or generate metalinks, and the Docker daemon can't use metalinks to download layers. The Fedora team has plans to fix that part by patching Docker.

Atomic Workstation

Two presentations at Flock covered the prototypes and current work on a possible new direction for Fedora workstations. David King presented current work on using OSTree to build a developer desktop and Patrick Uiterwijk spoke about his personal use of an Atomic Workstation.

Fedora Atomic is based on rpm-ostree, which installs systems by decomposing RPMs into a filesystem image that is then deployed immutably. Rpm-ostree depends on the general OSTree project, which is a tool that can generically handle creating distributable filesystem trees from any kind of package. The two project names are often used interchangeably in the Fedora community. Rpm-ostree is currently distributed for Atomic Host, which is a dedicated OS for containerized application servers.

Uiterwijk, a Fedora contributor, also finds OSTree useful for running a laptop on Fedora Rawhide so that he can test it. "I've been running on OSTree since January," he told the audience.

As a developer, the benefits to him include that he's running on a signed, read-only root filesystem that can't be hacked. More than that, he can easily revert updates to the system. "This was a good thing because this morning an update broke wifi. I was able to roll back and restart," he explained.

Right now, doing this yourself requires a lot of work, because there isn't an official Atomic Workstation distribution. This means that users need to build their own treefile and update server. Currently, Uiterwijk is using a daily cron job that composes the tree, then pushes files to Amazon S3. He also ended up writing secprov, which is a secure unattended install program.

He also had to decide which packages should be part of the base OS image and which ones should be installed in containers. He admitted that running desktop applications in containers is still somewhat of a hack.

King wants to make using an OSTree-based workstation less hackish and instead be a standard flavor of Fedora. Currently, there is an alpha developer workstation image based on GNOME, a freedesktop.org base, and a Fedora "core" workstation based on the current Fedora Workstation release. This includes a few desktop applications like LibreOffice.

His idea is that developers would be able to push applications directly to users without breaking their systems. This lets projects like NextCloud ship a "pristine" version of the application if it wants to.

It can even be safer, since the entire application and its dependencies can be signed by the developer, instead of pulling in a bunch of third-party libraries from other sources. Also, since users are installing a filesystem overlay and not an RPM, pre-install and post-install scripts don't run on the local system.

However, having a read-only filesystem does cause some breakage with current applications and usage. Some current packages don't install properly without a post-install script. Other applications, which use symlinks in /usr to provide "alternatives" also get broken. The developers are still debugging SELinux policy issues as well.

Getting Flatpak up to a state of general usability is key to this effort. Flatpak's sandboxing isn't really complete, and depends on Wayland. While the D-Bus proxy is done, other portal implementations for safe system access aren't written yet. Flatpak also depends on systemctl --user , which is a command that allows systemd to manage applications as a non-root user but isn't in many distributions yet.

The bigger issues with depending on Flatpak, though, are in distribution and infrastructure. The first thing is that people need to build Flatpaks of applications to install. Secondly, Fedora's build-infrastructure applications, such as koji, don't yet support Flatpak. The Linux world also needs to answer questions like: "Who's responsible for updates? The distribution, or the application developer?"

Current development is in the workstation-ostree-config and rpm-ostree-toolbox projects. There's also a Fedora continuous integration image available from ci.centos.org, although it doesn't currently have an installer. Interested developers can participate either through the Fedora workstation project, or IRC channel #gnome-os.

Onward for Fedora

Next year's Flock to Fedora hasn't been scheduled yet. According to organizers, it will be held somewhere in North America, with the location to be chosen later this year. Fedora's next big event is DevConf.cz in late January in Brno, Czech Republic. Flock was full of community members' plans for the future of Fedora. Whether it's via modularity, Flatpak, or a wholehearted embrace of containerization, the project seems intent on regaining the ground it lost to other distributions over the last few years.

[Josh Berkus works for Red Hat.]