Base manifest configuration for Fedora CoreOS.
Use https://github.com/coreos/coreos-assembler to build it.
Discussions in https://discussion.fedoraproject.org/c/server/coreos. Bug tracking and feature requests at https://github.com/coreos/fedora-coreos-tracker.
There is one branch for each stream. The default branch is
testing-devel
,
on which all development happens. See
the design
and tooling
docs for more information about streams.
All file changes in testing-devel
are propagated to other
branches (to bodhi-updates
through
config-bot,
and to testing
through usual promotion), with the
following exceptions:
manifest.yaml
: contains the stream "identity", such as the ref, additional commit metadata, and yum input repos.- lockfiles (
manifest-lock.*
files): lockfiles are imported frombodhi-updates
totesting-devel
. Overrides (manifest-lock.overrides.*
) are manually curated.
We intend for Fedora CoreOS to be used directly for a wide variety of use cases. However, we also want to support "custom" derivatives such as Fedora Silverblue, etc. Hence the configuration in this repository is split up into reusable "layers" and components on the rpm-ostree side.
To derive from this repository, the recommendation is to add it
as a git submodule. Then create your own manifest.yaml
which does
include: fedora-coreos-config/ignition-and-ostree.yaml
for example.
You will also want to create an overlay.d
and symlink in components
in this repository's `overlay.d.
By default, all packages for FCOS come from the stable
Fedora repos. However, it is sometimes necessary to either
hold back some packages, or pull in fixes ahead of Bodhi. To
add such overrides, one needs to add the packages to
manifest-lock.overrides.$basearch.yaml
. E.g.:
packages:
# document reason here and link to any Bodhi update
foobar:
evra: 1.2.3-1.fc31.x86_64
Whenever possible, in the case of pulling in a newer package, it is important that the package be submitted as an update to Bodhi so that we don't have to carry the override forever.
Once an override PR is merged,
coreos-koji-tagger
will automatically tag overridden packages into the pool.
Since testing-devel
is directly promoted to testing
, it
must always be in a known state. The way we enforce this is
by requiring all packages to have a corresponding entry in
the lockfile.
Therefore, to add new packages to the OS, one must also add the corresponding entries in the lockfiles:
- for packages which should follow Bodhi updates, place them
in
manifest-lock.$basearch.json
- for packages which should remain pinned, place them
in
manifest-lock.overrides.$basearch.yaml
There will be better tooling to come to enable this, though one easy way to do this is for now:
- add packages to the correct YAML manifest
- run
cosa fetch --update-lockfile
- commit only the new package entries
Updating this repo:
- bump
releasever
inmanifest.yaml
- update the repos in
manifest.yaml
if needed - run
cosa fetch --update-lockfile
- PR the result
Update server changes:
- Set a new update barrier for N-2 on all streams. See discussion.
CoreOS Installer changes:
- Update CoreOS Installer to know about the signing key used for the future new major version of Fedora (N+1). Note that the signing keys for N+1 won't get created until releng branches and rawhide becomes N+1.
Release engineering changes:
- verify that the
f${releasever}-coreos-signing-pending
Koji tag has been created (this should have already been done by releng scripts on branching) koji untag
N-2 packages from the pool (at some point we'll have GC in place to do this for us, but for now we must remember to do this manually or otherwise distRepo will fail once the signed packages are GC'ed). For example:koji list-tagged coreos-pool --quiet | grep fc30 | cut -f1 -d' ' | sort | uniq
- Sanity-check the output, then pipe it to
xargs koji untag-build coreos-pool