Host and Platform
Summary
Host and Platform is an evolution of the Base Runtime module concept introduced in Fedora 26 Boltron, splitting the minimal system further into independent modules allowing for greater flexibility when composing and maintaining the base system.
This change focuses on modular content structure; Changes/ModularRelease deals with details regarding modular delivery.
Owner
- Name: Petr Šabata
- Email: contyk@redhat.com
- Release notes owner: Simon Clark (sclark)
Current status
Detailed Description
The end goal of this change is to provide the modular base operating system content in a way that allows for hardware enablement and general userspace separation, enabling different update cadence and life cycles for each of the two parts.
Being the successors of Base Runtime, the two new modules will include all the content Base Runtime does as well as content from additional Fedora 26 Boltron modules currently extending it. Additional system configuration & management services and utilities are expected to be part of the base system experience, making all the essential content available for installation from the base level modules that are enabled by default.
Implementation
The concept is defined by the following set of objectives and expectations:
- Host and Platform are built and composed as modules, benefiting from all the modularity pipeline enhancements Factory 2.0 provides and are distributed with useful module metadata
- The Host part should deliver hardware enablement components such as the kernel, bootloaders, firmware, possibly additional device drivers and components closely linked to these
- The Platform part defines the operating system release and includes various base userspace components ranging from the C library and init system to system management & deployment tools, container runtime and possibly several services commonly considered to be part of the base system experience
- The Host and Platform modules should be independent, making it possible to run the same Host with different Platforms and vice versa
- Each of the two modules has its own life cycle, update cadence and versioning scheme
- The Host can only be experienced through the Platform
- The Platform part provides all the content needed to produce container base images; the Platform can therefore run without the Host in that scenario
- Both modules are built in a shared, self-hosting buildroot (also known as the Bootstrap module) providing all the build time dependencies needed to build the Host and Platform as well as itself
- While independent on the source level, given the shared build environment the modules' binaries are tightly coupled and the Host part therefore needs to be built for every supported Platform it's intended to be distributed with
- The Platform module provides the minimal build environment for application level modules -- this means that modules built against a certain version of Platform are built using the Platform compiler; this doesn't affect what additional compilers are available to the end users, for example via additional application level modules
Modules
At minimum the group is going to deliver three modules, one of which being an implementation detail only that won't be part of the Host and Platform compose.
- The Host includes the kernel, bootloaders, firmware, and components tightly coupled with any of these
- The Platform includes the C standard library, the init system, basic system tools, filesystem and networking utilities, system Python runtime, system management and deployment tools such as dnf and anaconda, container runtime(s) and possibly additional system services and components necessary to provide a reasonable base system environment
- The Bootstrap module includes a self-hosting package set needed to build the Host and Platform modules. Host and Platform are subsets of this module. The binaries are not part of the compose. This module is also part of Fedora 26 Boltron, defining the buildroot for Base Runtime and several other modules.
Host and Platform modules might be implemented as simple modules or module stacks, depending on what provides more practical value. Given that the content of each will be bound by the same life cycle and update cadence, we don't expect to split them into sub-units unless necessary.
The Host module might be a module stack from day one to simplify packaging of the UEFI bootloader.
The Bootstrap module will be initially created by manually tagging traditional Fedora binaries into a special purpose, module-like tag. The module is self-hosting so that it can later rebuild itself, as well as serve as a base for building future releases, spins, and derived distributions. Unfortunately it's not possible to build the new Bootstrap module using the Fedora 26 Boltron version due to the introduction of a new architecture (s390x) and numerous FTBFS issues.
Differences from Base Runtime
Fedora 26 Boltron Base Runtime module was created with a different set of requirements in mind: it was meant to provide a minimal bootable environment with hardware enablement, init system, basic system tools and a minimal package manager. Unlike Host and Platform, Base Runtime is usable on its own.
Base Runtime is both smaller and larger than Host and Platform -- it provides the basic functionality of both but the Base Runtime userspace package set is much smaller than that of the Platform.
Benefit to Fedora
Separating hardware enablement from general userspace makes it possible for each of the parts to have its own life cycle and update cadence, allowing pairing of one instance of the hardware enablement layer with numerous userspace modules such as "Platform F27" and "Platform F28", easily bringing support for the latest hardware to all supported Fedora releases.
Scope
- Proposal owners: Modularity WG will prepare both modules -- define the generic module metadata, buildroots, profiles, components and API. The group will also build the components and will deliver an installer boot image, container base image and virtual machines built from the Host & Platform content. The group will also create and maintain additional modules needed to accomplish these tasks, such as a "self-hosting buildroot package set" module similar to the one used for building Base Runtime for Fedora 26 Boltron. The group will assist package maintainers and release engineering with fixing packaging problems, component build and module compose issues.
- Other developers: Package maintainers are expected to fix packaging & build issues affecting packages they maintain in a timely fashion.
- Release engineering: #6815
- List of deliverables: Modularity & modular compose will be affected.
- Policies and guidelines: Not needed for this change.
- Trademark approval: Not needed for this change
Upgrade/compatibility impact
This is incompatible with Fedora 26 Boltron, however, the previous release was a proof-of-concept work with no upgrade mechanism in place. A clean installation will be necessary. Many of the Fedora 26 Boltron module content will be included directly in Host and Platform; remaining modules will have to be updated or, in some cases, completely rewritten.
This change doesn't affect the traditional release in any way.
How To Test
Host & Platform need to run on all Fedora supported architectures. Booting a Host & Platform based system on various hardware configurations, installing the Host and Platform provided packages, running them, enabling additional modules and installing content from those are all valid test cases.
Container base images will be also provided. Testing whether they can be used on their own or building additional layers on top of them is also appreciated.
User Experience
Host and Platform will replace Base Runtime in the minimal modular installation, affecting all modular deliverables. See the detailed description above or the Host and Platform page for more details.
Dependencies
Cooperation with modularity, infrastructure and release engineering teams will be required.
- The new modules will include content from many of Fedora 26 Boltron modules. Component lists and inter-module dependencies, both build time and runtime, will need to be updated. Some modules will become obsolete. This will need to be coordinated with the current module maintainers.
- Until the current tooling is updated or replaced, the infrastructure team should create new modules/* dist-git repositories, if requested.
- Release engineering should assist with the bootstrap module tag creation (https://pagure.io/releng/issue/6791) and tagging the necessary secure boot packages (https://pagure.io/releng/issue/6823).
Contingency Plan
- Contingency mechanism: Not applicable.
- Contingency deadline: Not applicable.
- Blocks release? Yes, this blocks further Fedora 27 modularity work.
- Blocks product? Yes, this blocks further Fedora 27 modularity work.
Documentation
The Host and Platform wiki page includes additional information related to implementation of this change.