Previously, the worker was determining the GCE image guest OS Features
on its own, based on the OS name. This caused problems, in case the
osbuild-composer was of a newer version than the worker.
Example:
osbuild-composer contained support for c10s GCE image type and its
implementation also contained the proper guest OS Features list for it.
However, when the worker got the osbuild job, it built it and tried to
fetch the guest OS Features for the distro. Since its implementation was
too old, it didn't contain the code that added the actual support for
c10s GCE images and got no guest OS features list (which is the default
for unsupported distros). The image was successfully uploaded and
shared, but it does not boot in GCP, because it does not know that it
should use UEFI to boot it.
This behavior could be considered a bug. The worker should be dumb. It
should not be making decisions about the image features, but instead it
should take them from the upload target options. And composer should be
the authoritative source of truth for this. Because otherwise, we
basically have two components that need to be updated in sync to add
support for GCE images on a new distro.
Move the GCE image guest OS features to the GCP upload target options.
The worker will just take what is specified there and use it when
importing the image to GCP. As a compatibility layer for the case when
the composer would be older than the worker (unlikely, but still),
worker will try to determine the image guest OS features in case the
list in the upload target options is empty.
Extend the GCP functional tests to check that the imported image has at
least some guest OS features set.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Enable testing of GCE image type on el10 / c10s. The el10 / c10s image
type temporarily uses cloud-init, because there are no GCP guest tools
for el10 / c10s yet and el9 version can't be installed. This implies
that we need to set the SSH key in the instance metadata and use SSH
directly.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for RHSM customizations, which currently allow various
aspects of RHSM. Specifically enabling / disabling DNF plugins shipped
by subscription-manager package and setting a subset of options in the
rhsm.conf.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for RPM customizations, which currently allow to import RPM
GPG key from a file installed in the image. This is e.g. done for the
Azure RHUI image type.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Extend the `api.sh` to allow testing compose requests with distro name
which does not use dot-notation (specifically when the dot is removed
from the distro name as it used to be in the past). In addition to that,
allow also testing the distro alias using distro name without the minor
version in compose requests.
Enable these two new test variants in the CI.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Run a basic check to see that the tailoring file has been created when
adding tailoring rules to the OpenSCAP config. Since the OpenSCAP scan
requires more memory and breaks some of the API tests, a full scan is
not run in the cloudapi tests.
- remove `custom-repos.sh` integratoin test
- add custom repositories check to `api` tests for supported
images
- verify custom repositores are added to /etc/yum.repos.d
- verify gpg key is saved to /etc/pki/rpm-gpg (for inline keys)
Use directories and files customization in the compose request for image
types that support this customization (only ostree installer and raw
image do not support it).
Extend the instance verification to check for the custom directories and
files.
Extend the ostree commit verification to check for the custom
directories and files.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Previously, the `--format=json` was always set in the `$GCP_CMD`. This
was working OK in general, but it is creating issues when using
`$GCP_CMD compute ssh` to execute commands on the provisioned VM. In
such case, an extra `[]` is added to the output, which then causes
various checks to fail, since the captured stdout is different than
expected.
Instead remove the `--format=json` by default from `$GCP_CMD` and use it
explicitly only in cases when `jq` is used to parse the command's
output. In all other cases, it should be OK to not set the output format
to JSON and it is very much desirable to do so when SSH-ing to the VM.
Also by default pass the `--quiet` option to `gcloud` when using it from
the container. This was previously done only when using the tool
installed on the system.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
GCP Bucket to use can be now configured in the worker configuration.
Make the `Bucket` optional in the Cloud API when uploading image to GCP.
Adjust the Cloud API test case to configure GCP Bucket on the worker and
not provide it in the API request.
Extend the `koji.sh` test case to allow also testing the upload to
cloud, in addition to the testing that it supports currently (building
of multiple images in one Koji compose request).
The script now reuses some common functions used by the `api.sh` test
case. Once the Koji compose succeeds, the script verifies that the image
is present in the appropriate cloud environment using a CLI tool. No
additional testing of the image is done, it is not booted.
- 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>
