Enable F34 testing on AWS as there is nothing blocking it. F34 is not
yet supported on `rhos-01` as there is no runner definition.
Remove F33 repositories for testing and add repo definitions for F34 and
F35.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
There's conflicting ansible versions in the 86 nightlies and epel. There
should be a correct combination of plugins which fixes the callback on
86. But let's drop it to unblock for now.
`json_query` requires python3-jmespath which, while available in the
repos, it can sometimes cause issues when the ansible interpreter is
different from the system interpreter.
The `json_query` is only used in a handful of locations that can easily
be served by `jq`, which we use in other places already.
It should be `1048576` (exactly 512 MiB), like it is for all other
distributions. It somehow got mingled in when the distribution was
forked off from 8.5/9.0 beta (1048676 to 1048576 strongly suggests
a sed command was involved, so we blame that).
The unification of the partition table also introduced uuids and
types in uuid form for partition tables in dos layout, sill used
on PPC64LE and s390x. The org.osbuild.sfdisk stage did work with
that but produced a `/boot` partition with the wrong type, which
grub2 refused to read from and thus prevented boot. Fix this by
removing uuids from the dos partition tables.
Reported-by: Jakub Rusz <jrusz@redhat.com>
The fix is already in Koji 1.27.1 which should be available in all downstreams
we are testing against.
See https://src.fedoraproject.org/rpms/koji
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
- the /var/log/audit mountpoint has been added previously to the
blueprint but wasn't explicitly checked
- reordered the list of mountpoints to match the blueprint
(alphabetically)
- added logging of successfull results we that QE can see what has been
tested in the logs and use it for verification purposes.
Related: rhbz#2002727, rhbz#2001891
Port all of the pipeline refactoring done to RHEL-90 to RHEL-86. Both
distros now use the same approach.
Regenerate all RHEL-8.6 and CentOS 8 image test cases.
[1] https://git.centos.org/centos/kickstarts/tree/master
Signed-off-by: Tomas Hozza <thozza@redhat.com>
RHSM configuration is now applied conditionally only on RHEL. The same
applies to the customization to subscribe the system on first boot.
The reason is that the CentOS `@core` package group does not contain
`subscription-manager`. Thus it is not installed on CentOS Stream by
default and also CentOS 8 image definitions don't apply any changes
to the RHSM configuration [1].
In addition, make sure to not install any subscription-manager
packages on CentOS Stream images.
Regenerate all CentOS 8 image test cases.
[1] https://git.centos.org/centos/kickstarts/tree/master
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Move the x86_64 specific configuration from `ec2X86_64BaseTreePipeline`
to x86_64-specific image configurations for EC2 / AMI images. As a
result, remove the `ec2X86_64BaseTreePipeline` entirely and replace it
with `osPipeline`.
Regenerate image test cases. While there are changed in the manifests,
the actual image configuration didn't change at all and thus the
`image-info` report was not changed.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Move the RHSM configuration settings to `ImageConfig` structure and use
when handling subscriptions in `osPipeline`, `ec2BaseTreePipeline` and
`ostreeTreePipeline` functions.
Regenerate image test cases. While there are changed in the manifests,
the actual image configuration didn't change at all and thus the
`image-info` report was not changed.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Introduce a new data structure `ImageConfig` holding the default OS
configuration applied when building an image. The structure can be used
to hold the default image configuration on the distribution level with
possible overrides defined on the image-type level.
As a starting point, move hard-coded default values and configuration
common for `osPipeline`, `ec2BaseTreePipeline` and `ostreeTreePipeline`
to the distribution and image-type default image configuration. This is
preparing the ground for merging all of these three pipeline functions
into `osPipeline`, which will produce the appropriate OS pipeline based
on the image-type configuration and the fact if it is rpmOstree or not.
Regenerate affected EC2 and AMI manifests. There is however no change in
the resulting image configuration and image-info report.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
This test provisions a RHEL-8.6 VM locally, installs osbuild-composer on
it, upgrades the system to RHEL-9.0 and verifies osbuild-composer still
works by building a simple qcow image.
The existing test cases for `image-installer` image type were not
regenerated as part of PR #2135 which introduced 'image_type_tags'
because regenerating them using `generate-all-test-cases` failed on them
due to trying to analyze them using 'image-info'. These test cases were
most probably originally generated manually with --keep-image-info
option passed to `generate-test-cases`. And I missed that their
regeneration failed at that time.
Add the `image-installer` image type to all distros in
`distro-arch-imagetype-map.json` and (re)generate the test cases for it.
The image test case for CentOS Stream 9 is not generated, because there
are no repos defined yet for the distro. This is part of the CentOS 9
PR #2142.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
During manual cleanup of unused resources, the storage account can get
removed. The current storage account is not possible to remove
mannually, but adding this check to make it more resielient in future
scenarios.
Use image_type_tags in repo definitions used for generating image test
cases. Enhance the `generate-test-cases` script to take the
image_type_tags into account when creating a compose request for a
specific image test case.
The motivation for the change is to keep the list of repositories in the
compose request of a image test case as small as possible. Previously,
all of the defined repositories were part of each image test cases for a
specific architecture, even those that were not needed.
Regenerate affected image test cases.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
When backed by a DB, composer has no need of a queue directory.
This also addresses "Error moving artifacts for job" logging noise.
Signed-off-by: sanne <sanne.raymaekers@gmail.com>
Our workers are not named osbuild-worker but usually something like
osbuild-worker@1. Let's steal the code that determines the unit name
from other tests.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
With new weldr-client package the metadata tar archive created has
permissions set to 600 instead of 644 which causes permission failures
when interacting with it. Adding sudo to resolve that.
Add `--build-rpms` option which will make the script build osbuild-composer
RPMs on the remote runner from the sources which were copied over. These
RPMs are then installed on the system, before any image test cases are
generated.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Script is run with the image type to build as the argument.
The target / cloud service is selected based on the image type
specified. This is how the API actually works now: Only an image type
can be specified.
The script now supports all the blobby image types for testing:
- edge-commit
- edge-container
- edge-installer
- image-installer
- guest-image (qcow2)
- vsphere (vmdk)
These are image types that are uploaded to S3 and provided to the user
as an object to download rather than a VM image on a cloud provider.
To verify the cloud api compose request options for the qcow2 and vmdk
image types, download the object and inspect it using image-info.
Checks if postgresql is installed and that user1 and user2 exist in the
passwd file.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
Temporarily switch to the nightly devel composes for RHEL 9.0.
We're testing new packages and changes right now (like coreos-installer)
and it takes time to make new snapshots every time.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
Don't use the `@core` package group in image definitions, because it is
not intended as the minimal package set for virtual / cloud images. In
addition, its content is changing without us knowing, which has
consequences such as the recent discovery of the fact that TuneD is no
longer installed by default on RHEL images, while it definitely should be.
Replace the `@core` package group with the `coreOsCommonPackageSet`
package set. The content of it is based on the latest `@core` group
definition with a few modifications, so that image package sets
never end up having the same package listed in the `Include` and `Exclude`
package set at the same time. All additions have been accompanied with a
comment and all removals have been kept commented out with a comment.
The fact that the change does not have any effect on image package sets
was verified by regenerating all RHEL-9.0 image test cases. There is
however one change in the VMDK image. Specifically the
`python3-libselinux` package have been added. The reason is that the
latest `@core` group definition was used when defining the content of
`coreOsCommonPackageSet`, however the `@core` group definition in the
RPMRepo snapshot used for the image test case didn't include the package
yet.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The `@core` package group used to include TuneD package by default on
RHEL-8. It has been removed from the group in Fedora as part of [1] and
inherited into RHEL-9. As a result, TuneD is no longer installed by
default on RHEL images.
After a discussion on rhel-devel there seems to be an agreement, that
TuneD should be installed by default on all RHEL virtual images. At
least we should keep the consistency in this regard with RHEL-8.
Regenerate all RHEL-9.0 image test cases.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=2026709
[1] https://pagure.io/fork/adelton/fedora-comps/c/a5d4f1b6c9fcbe20cb0c38eac5048d7d45d1dd17
Signed-off-by: Tomas Hozza <thozza@redhat.com>
