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).
Allow manifests to be instantiated without providing packageSpecs.
This allows manifests without packageSpecs to be introspected, but
not serialized.
The only reason we used to require packegaSpecs to be passed at
instantiation time was to compute the kernelVer based on the
kernelName and the NEVRAs in the package set. Now move this to be
done at serialize time.
This means that in order to serialize a manifest, you need to pass
the packageSpecs at initialization time, but if you don't need to
serialize, only to introspect it, then you don't need to pass it
at all.
In a future patch packageSpecs will be passed at serialization time
to not have to make that commitment up front.
The new logic is now that before a pipeline can be serialized, all
the pipelines in the manifest must be "prepared" for serialization
by calling serialize_start() on each of them, which does whatever
would in the past have been done at initialization time which
required the pacakgeSpecs. Once serialization has been finished
serialize_end() must be called on each of the pipelines to undo
any of the preparation, making sure we can serialize repeatedly,
possibly while changing the fields of our pipeline in-between,
and that serialization appears from the outside to not have any
side-effects.
In a future PR we may want to rework this logic to instead use a
serialization context.
Allow the packages returned by a pipeline to be extended by setting
the optional property ExtraPackages.
In the case of OSPipeline, a further UserPackages property is added.
This allows the caller to set the set of packages that should be
depsolevd in a second transaction, on top of the one for the base
packages.
This functionality is currently unused so this is a noop.
A build pipeline now tracks all its dependents, and each pipeline
now implements a `getBuildPackages()` method. For now those
return the empty slice, but will be extended by each pipeline in the
future.
`getPackageSetChain() of the build pipeline simply collects all the
build package sets of its dependents.
This returns the package set chains for a given manifest. A package
chain is a list of depsolve requests (include, exclude, repos) to be
performed in sequence as if packages were incrementally installed
to the same image. Each pipeline has its own package set chain, and
the manifest returns a mapping from pipeline name to their
respective chain.
So far this is not used, and always returns the empty chains.
The intention is to eventually make each pipeline (and hence
manifest) self-describing, so they can return exactly the depsolve
requests needed to serialise them, rather than relying on that
information being maintained externally.
Name it `getPackageSpecs()` instead so we can introduce a new
function `getPackages()` that is about package names rather than
full specs, in a follow-up commit.
Panic in case two pipelines with the same name are added to the
manifest. In the future we should deal with allocating fresh names,
but that is not yet needed.
Make it the responsibility of each pipeline to track its required
sources, and use this to generate a manifest from its pipelines.
This removes the dependency on osbuild2 from distro.go, and the
only other uses of osbuild2 are to specify parameters in
ImageConfig, which will eventually go away too.
As a consequence, this only attaches the required sources for a
given manifest, rather than all known packages in the package set
map.
Add a plain `rhel-8` alias as the default distribution name and version
for the `rhel8` package. The `rhel-86` distro is still available via
the NewRHEL86() constructor. These two distributions are identical.
Repositories
------------
The rhel-8 repositories (repositories/rhel-8.json) are now set to the
CDN repositories with no minor version:
https://cdn.redhat.com/content/dist/rhel8/8/...
The rhel-8 test repositories (test/data/repositories/rhel-8.json) were
already set to the plain `8` repositories. The Google repos have been
added.
The test case generator repositories used for `rhel-8` are the rpmrepo
snapshots as for rhel-86.
