While this feature is 'not mature yet' according to Packit developers,
we can enable it because there's no harm done. If Packit fails to
publish the Bodhi update then fedora-bot will take care of it.
We have three kinds of operating system trees, until we unify them to one,
hide them behind one interface. Use this to read the architecture from the
Tree rather than pass it in as a string to parent pipelines.
Also, make the filename parameter optional in a few places, there should be no
reason to set this rather than introspect it (except for backwards
compatibility).
Lastly, add another playground example sample to build a raw image.
For now all it does is represent the name of the runner and what requirements
it has of the build pipeline.
Move some package definitions from the runner package set to where it belongs.
With the more fine-grained build package set, different images will use
different build pipelines and each of them will be smaller.
We don't currently cache build pipelines so there is no downside to this. Even
when we start caching the difference between having one build pipeline per
image and one shared one is minimal at scale. This will still benefit users
doing one-off builds on-prem.
Most importantly, this tracks things correctly, making pipelines more
composable without having to maintain a global list of dependencies.
This should have no practical effect, but ldconfig is used from
runners, so it is strictly speaking a requirement.
At the same time document the remaining TODO's in the build
pipeline.
The build pipeline requires the selinux packages only if we are going to be
labelling the files in the target OS. Otherwise, skip it.
manifest/build: pull in selinux-targeted unconditionally
This is unconditionally used by the build pipeline itself, until we make that
conditional, it needs to be installed.
We stopped testing on RHEL 8.4 because it wasn't changing, but now it
will be (or might) since it lives inside the common rhel8 package.
Testing the distro ensures we don't break it. RHEL 8.4 is still
supported as EUS.
We will soon change the distro definition to specifically build 8.4 EUS.
Pin osbuild version for RHEL 8.4.
Change the ostree test to support 8.4 (and not 8.5).
Manifest diffs can sometimes get large and putting them in the log makes
life harder for everyone.
Save them in a single file in the job artifacts instead.
Update the comment left by Schutzbot on the PR to mention the artifacts.
edge-raw and edge-simplified-installer: only on 8.6+
ec2 and ec2-ha: available on all RHEL 8
ec2-sap: available on 8.4 and 8.6+ (no 8.5)
The ec2-sap image requires ansible, which in 8.4 is called `ansible` and
was replaced by `ansible-core` in 8.6.
Added unversioned (el8, no minor version) repositories for RHEL 8.4
that provide packages for building ec2 and azure-rhui image types.
Added new repo snapshots to RHEL 8.4: ha, sap, and saphana
With the merging of 8.4 into the main rhel8 package, the name
'rhel-edge-commit' is no longer the primary name for the image type.
More generally, the 'rhel-' prefix doesn't appear in the main name for
any image type anymore.
Converted by loading them through the manifest parser in osbuild and
formatting them through v2 before dumping.
These are not the "real" manifests that osbuild-composer would generate,
but they will make it a tiny bit easier to compare and detect changes in
the distro definition when it's moved to the common rhel8 package.
This represents how our systems should integrate into their environment, typically using
some sort of agent, or commonly cloud-init.
In the future we could imagine this representing network configuration or any other kind
of configuration necessary to reach the environment as well.
For now EC2 and Azure is supported, and stub environments are
added to show the idea, but these are not implemented/used
yet.
The workload encapsulates what the user wants to run on top of the image. Everything
else we do abstracts away the OS, the hardware, the environment, and what is left is what
matters: the workload.
For now only the `Custom` payload is implemented which requires the user to name the
packages they want installed, the repositories to pull them from and what systemd
services to enable.
A few other stub workloads are added to show the idea, but these are not used.
The ideal is for the workload to have only the minimal number of configuration options.
Always include the tools for all the filesystem types in the partition table. There may be
usecases for having additional ones, for instance if the partition table is not known, but
this gives us a minimal baseline.
This includes dosfstools in images that have a vfat partition but did not include the tools.
Any package that is added by the pipeline definition should be in the base package set
and the user package set should only be for packages explicitly added by the user.
Any combination of implicitly added packages should depsolve, or it is a bug. However,
user provided packages can have conflicts which must be handled gracefully.
This change is not breaking, as that would be a bug (per the above) and it makes our
behaviour more predictable as any conflicts are caused by explicitly added packages.
Note that this changes the logic from the kernel package being depsolved twice to only
being depsolved in the base package set.
Pass PackageSets when initialising the Manifest, and read the chains back out.
This also fixes a bug where all repos were always used, rather than filtering per
package set.
Finally, this moves the 'chrony' inclusion from distro.go to the OSPipeline where
it belongs. In doing so the logic is changed slightly, where chrony is now
installed if NTP servers are configured (regardless of source), whereas in the
past it was included if the timezone was set in the blueprint (which made no sense).
If the kernel name is set, then the packaegSpecs must include the kernel package, ensure
this by including the kernel in the package list.
We currently include the kernel both in the userPackages and the base packages.
Including it only in the user packages does not work as the base could end up pulling it
in as well. However, it would be semantically more correct to include it only in the base
set, so if possible we should do that and drop it from the user packages (in a follow-up).
If the partition table includes logical volumes, the lvm2 package should be installed on
the target system.
Drop the corresponding logic from fedora/distro.go.
These objects describes the hardware an image runs on. Including
- architecture
- bootloader
- required firmware
Use the platform abstraction to move firmware packages out of the package set
definitions.
This is a partial revert of 006c5b26, where kernel settings and bootloaders were only
installed on bootable systems.
However, ostree-based systems need the ability to pick up kernels and bootloaders from
the commit to install on the instance, so make this conditional on being bootable or an
ostree commit. This is probably an indication that we need a different abstraction.
Currently an image type could override the boot loader in the architecture, but we should
not allow an image type to select a bootloader type the architecture does not support. So
only in case the architecture supports hybrid boot do we allow the image type to select
one of the two types.
This enables UEFI on AMIs for aarch64.
Collect partition tables / boot loaders / kernels together and
make them conditional on the system being bootable.
As a side-effect, we no longer install the grub2 modules in ostree commits.
