Fedora's Boltron preview

In many ways, distributions shackle their users to particular versions of tools, libraries, and frameworks. Distributions do not do that to be cruel, of course, but to try to ensure a consistent and well-functioning experience across all of the software they ship. But users have often chafed at these restrictions, especially for the fast-moving environments surrounding various web frameworks and their dependencies. Fedora has been making an effort to make it easier for a single system to support these kinds of environments with its Modularity initiative. In late July, Fedora announced a preview release of the server side of the Modularity equation, Boltron, which is a version of the distribution that supports the initiative.

In order to be able to support multiple versions of various packages, those packages need to be created and made available to Fedora installations. That's where Boltron comes in. First, the packages need to be decoupled from a Fedora release, which is how they are delivered today. This was done by adjusting the existing tools rather than starting over. The Modularity working group did so to try to reduce the effects of the changes:

This was done by modifying the existing tooling to support arbitrary branching within the package database so the service level (SL) and end of life (EOL) dates can be separated from a specific Fedora release. More information about arbitrary branching—how it would work and why it is needed—can be found in the focus document.

That document uses the example of the Django web framework and the Python Requests module. The packages in the database would no longer only have branches for each release (e.g. Fedora 25, EPEL 7), but would also have branches corresponding to the upstream release versions. That way, a Django module could have multiple versions that depended on particular versions of its dependencies. So, for example, Django module 1.9 could depend on Requests 2.12, while Django module 1.10 could depend on the master branch for Requests (or, perhaps, 2.13 if following the upstream master is deemed too risky).

There is another side to Modularity, though. There needs to be a way to allow incompatible modules to coexist on a single system. There are a number of ways to support that, each with its own set of tradeoffs. Instead of coming up with yet another solution, the working group is focused on supporting existing mechanisms, such as Flatpak and containers of various sorts (Open Container Initiative (OCI) containers and System containers).

As the announcement notes, the Boltron preview is "somewhere between a Spin and a preview for the future of Fedora Server Edition". There is a wealth of information on the Modularity page for those interested in trying it out or simply for curiosity's sake. Boltron is shipped as a container image that can be downloaded from the Fedora Docker registry as described in the "getting started" guide. There is also a guided walkthrough that serves both as an guide to using Boltron and as a way for the working group to collect feedback on the changes.

A module is simply a collection of related packages that work together to provide some task or service. That could be a web server and a selected group of modules or add-ons, a particular version of a web framework and its dependencies, or a particular language version with any needed runtime components. Multiple versions of those modules can be created, each with its own stability level and lifetime. Each of those versions is handled as a different "stream" of the module.

In Boltron, an updated version of the now familiar dnf command is used to manage modules. For example:

    # dnf install httpd
    # dnf install @httpd
    # dnf module install httpd

The first of these would install the httpd module, if one exists, or fall back to installing the httpd package. The latter two are requesting the httpd module only (the middle reuses the existing "group" syntax for dnf). Individual streams can be chosen for installation by appending the stream name (e.g. httpd-2.4). When a dnf update is done, updates are only taken from the appropriate stream. There are ways to install different profiles of modules (for a database server versus client, say) or to simply install certain packages from a module. Eventually, packages will only come from modules, so a module must be enabled before individual packages can be installed from it.

As the "preview" term would imply, there's not much more to Boltron at this point. There are some 25 modules that have the same stream as that of the regular packages for Fedora 26. So far, the only module with multiple streams is for Node.js, with version 8 being available in the nodejs-8 stream. The intent is that more modules and streams will be added so that Fedora 27 servers can be composed by picking and choosing modules and streams to fit their intended use cases. Containers would presumably be used to manage multiple conflicting modules. There is, clearly, plenty more to be worked on.

The Modularity effort is a bold rethinking of how Fedora is built, used, and managed, as we have noted in some previous articles along the way. For a year or more, Modularity has largely just been an idea and a few, somewhat confusing diagrams, at least from the perspective of Fedora users. We are finally starting to see some of the behind-the-scenes efforts bear fruit. It will be interesting to watch and see where it all leads.

---

to post comments