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.
The kernel name is optional and can be set later.
The bootloader we skip entirely. Instead, set the architecture, which now becomes
mandatory. Use it to deduce the bootloader, and in the future other pipelines can read
this property from the OS Pipeline, rather than having it passed in.
These should both default to being disabled, so move them away from the constructor.
Rename grubLegacy to BIOSPlatform and document that setting it enables BIOS support.
The OSTree parameters can be set after initialisation. We should only require parameters
to be set at initialisation time if we have no good defaults. In the case of OSTree the
default is to not enable OSTree support.
- Fixed shellcheck errors
- Moved checkEnv from common to individual tests
- Fixed package install section in spec file:
Globs which include a directory fail on el-like distros.
- Use gcloud cli to ssh
- (re)Introduce generic s3 tests
Each cloud now has its own file that's sourced on-demand by the main api.sh
script. The main goal of this commit is to reduce the amount of clutter in
api.sh. I, personally, find 1300 lines of bash overwhelming and I think that
this is a reasonable beginning to start cleaning things up.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Let's stay updated!
Also, let's remove 8.4 and 8.5 from Schutzfile, I strongly believe that it's
not used anywhere.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Openshift keeps sending requests to composer for a while after it has
sent SIGTERM, this results in requests being reset randomly on
shutdown. Waiting a few seconds before terminating mitigates this.
Weldr makes assumptions about the names of the package sets. This
does not work in all cases, so should be reworked, but for now just
do enough that we don't regress.
This is meant for rapid prototyping of single image types and for
osbuild development, as an alternative to osbuild-mpp. The same
primitives are used as in the image definitions, but without any
policy or inheritance applied.
The user is expected to only edit `playground.go` and then run
the tool to produce osbuild manifests.
A runner is used to run stages in a build pipeline. It is not about
running them on the host, in that case the runner is autodetected.
Not a functional change.
The build packages should always be computed from its
dependents and there should be no need to override it. Drop the
ability, and all the unused code in fedora/*.
NOTE: due to a bug in a previous patch in this PR the extra
package set was never set on the build pipelines.
No longer name the packageSetChains after the package set, but
keep them named after the pipelines. This should be a
non-functional change as dnf-json does not care about what the
chains are called, only that the names are unique.
squashfs-tools is used by the mono stage, and lorax by lorax.
For now copy over the anaconda boot package set as-is, we can
refactor further from the pipelines.
Rather than providing packageSpecs when constructing the
Manifest, do so at Serialize() time.
This allows the overall flow to be:
```
m := Manifest.New()
m.AddPipeline()
...
c := m.GetPackageSetChains()
p := Depsolve(c)
m.Serialize(p)
```
Before you read this patch, be warned: this is crazy. But rest
assured, this is as bad as it gets, and by the end of this PR it
will all be infinitely simpler than it ever was.
We want Manifests to be self-describing, and in particular, we want
manifest.GetPackageSetChains() to return what
ImageType.GetPackages does today. This should be achieved by
pipelines knowing their required package sets, and the caller
optionally amending additional package sets at Pipeline
initialisation time.
As a first step, while pipelines don't yet know anything about their
required package sets, simply pass in the precomputed
PackageSetChains and set them as optional on each pipeline. Then
we can read the chains back out of t he manifest.
This is not a functional change, but allows us to gradually move
package set definitions from the distros to the pipelines in follow
ups.
The package sets for an image can depend on the blueprint, and
by the same logic there is no reason it should not be able to
depend on the image options.
This is so far a non-functional change, but makes a follow-up
commit simpler (though still without actually depending on
the image options to compute the package sets).
