A few recent changes in image type definitions haven't been reflected in
the test cases yet. This also acts as a check to make sure that the
changes in composer don't affect the old behaviour.
Causes for (some) changes:
- Kernel modules added to package lists:
Prior to PR #1175 image types defined the kernel package in their
package list. Some only included `kernel-core` and not the `kernel`
metapackage. Now images default to having the `kernel` metapackage
included which also adds `kernel-modules` and `alsa-sof-firmware`.
- New package source for rt kernel.
Move the container build to the same phase as the RPM builds. This does not make a huge difference, but should
shave off about two minutes of total CI runtime.
This commit adds support for uploading images directly to Azure using the
cloud API.
The UploadStatus part is currently not implemented and will be added in a
follow-up PR.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
This commit adds and implements org.osbuild.azure.image target.
Let's talk about the already implemented org.osbuild.azure target firstly:
The purpose of this target is to authenticate using the Azure Storage
credentials and upload the image file as a Page Blob. Page Blob is basically
an object in storage and it cannot be directly used to launch a VM. To achieve
that, you need to define an actual Azure Image with the Page Blob attached.
For the cloud API, we would like to create an actual Azure Image that is
immediately available for new VMs. The new target accomplishes it.
To achieve this, it must use a different authentication method: Azure OAuth.
The other important difference is that currently, the credentials are stored
on the worker and not in target options. This should lead to better security
because we don't send the credentials over network. In the future, we would
like to have credential-less setup using workers in Azure with the right
IAM policies applied but this requires more investigation and is not
implemented in this commit.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
This file contains a client for Azure Storage API. As we soon introduce the
client for Azure API, we need a distinction here.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
The UploadImage method doesn't actually create an image. It creates a Page
Blob. Blob is something like S3 object but in the Azure terminology. Page
Blob means that's optimized for random access and it's the only blob type
that can be used to create images.
This commit cleans up the terminology so it's less confusing.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
If the image size isn't aligned to 512 bytes, the Azure API returns very hard
to understand error message. Let's do this check ourselves early so we can
return a sane error.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add NEWS section documenting changes done to Cloud API related to
UploadStatus.
Fix one typo in `rhel84-grub2-saved-entry.md`.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Return GCP-specific target results form the worker, similar as it is
done for AWS.
Extend Cloud API to allow GCP-specific upload Options.
Modify Cloud API to return UploadOptions as part of the UploadStatus.
Modify Cloud API integration test to check returned upload Options and
upload Type.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The previous version referred to lorax-composer as the definition of
what osbuild-composer does. This worked fine while osbuild-composer was
considered an alternative for it. Now that osbuild-composer is the
default one, it should describe what it does without references to
lorax. Furthemore, composer is now able to build OSTree commits as well
as VM images, to the previous description was slightly incomplete.
This commit introduces description which is up-to-date and does not
refer to lorax any more.
Previously, the test merged stderr and stderr and treated it as json. This was
obviously wrong. osbuild's stderr only returns python exception that are
of course not json.
The behaviour is now different:
1) stderr and stdout are treated separately
2) json from stdout is indented to prevent long lines. If it fails the test
just prints the stdout as returned from osbuild.
3) stderr is printed as returned from osbuild
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add the TargetResult struct to OSBuildJobResult. Include the 'options'
interface on TargetResult to contain target-specific information,
for example amiID and region from AWS. Expose 'options' on a status
call as an UploadStatus field. Add logic to support AWS within this
format, which can be used as a template for other targets.
Extend the Cloud API integration test for GCP to also create a Compute
Node instance using the image, boot it and ssh to it. This brings the
GCP integration testing on par with AWS testing.
Use VHD image type for GCP integration testing, because it by default
contains `cloud-init` installed, unlike the VMDK image.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Mockbuild using systemd-nspawn currently fails on Fedora 34. The
workaround is to use "simple" isolation method - the traditional
chroot() call.
Reported as: https://bugzilla.redhat.com/show_bug.cgi?id=1931452
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Split the integration testing section into two parts. One for testing of
Weldr API and another one for Cloud API. Cloud API integration testing
part has two sections, one for testing integration with AWS and another
one for GCP.
Fix path to osbuild-composer-cli-tests tool.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Upload target type is currently not returned form the worker, but
hardcoded in the cloudapi code to always return "aws". This make testing
of the cloudapi for other cloud providers quite complicated.
Since extending the target status information returned from the
worker is currently in progress, work around the situation for now
by returning an empty string as the upload type.
This will allows other types of upload targets to be tested as part of
cloudapi test case.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Refactor test/cases/api.sh to incorporate testing of cloudapi with
multiple cloud providers as the target. Since all variables in Bash are
by default global, don't declare them as empty in advance. The only
place where underclared variables can be potentially expanded are the
cleanup functions. Ensure that there are no unbound variables expanded
inside cleanup functions. Rename all AWS-specific variables to
contain "AWS_" prefix to make their purpose explicit.
Modify provision.sh to append the GCP credentials file path to the
worker configuration.
Add GCP api.sh test case to integration tests in Jenkins and run it only
if the appropriate GCP credentials environment variable is defined. Run
the GCP test case for RHEL images.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The tools/provision.sh script is sourced by all test cases and it sets
up the system and software for running test cases. As part of the setup,
it copied over the whole content of test/data/composer/ to
/etc/osbuild-composer. However the source directory contains not only
osbuild-composer's configuration, but also configuration for the worker.
The worker however expects its configuration in /etc/osbuild-worker.
The fact that provision.sh does not copy the worker configuration to the
correct directory didn't affect the CI, because the only test case that
relied on it is koji.sh, which copies the worker configuration
explicitly.
Move osbuild-worker test configuration to a separate 'test/data/worker/'
subdirectory. Also install the osbuild-worker test configuration to its
own subdirectory in the "-test" RPM.
Move the copying of worker configuration to the correct destination
directory from koji.sh to provision.sh, so that all test cases can rely
on the system being set up properly. Do not use wildcard for copying
osbuild-{composer,worker} configuration files, but explicitly copy each
file to its respective destination directory.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add support for GCP as an upload target to the internal API.
Extend the cloudapi to allow GCP as an upload target in the compose
request. Regenerate the cloudapi go code. Added GCP-specific upload
result component in the API definition, similar to AWS. It is not yet
used, but it will be once returning a target-specific result from
worker is supported.
Add support for GCP upload target to the worker job implementation.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add new internal upload target for Google Cloud Platform and
osbuild-upload-gcp CLI tool which uses the API.
Supported features are:
- Authenticate with GCP using explicitly provided JSON credentials
file or let the authentication be handled automatically by the
Google cloud client library. The later is useful e.g. when the worker
is running in GCP VM instance, which has associated permissions with
it.
- Upload an existing image file into existing Storage bucket.
- Verify MD5 checksum of the uploaded image file against the local
file's checksum.
- Import the uploaded image file into Compute Node as an Image.
- Delete the uploaded image file after a successful image import.
- Delete all cache files from storage created as part of the image
import build job.
- Share the imported image with a list of specified accounts.
GCP-specific image type is not yet added, since GCP supports importing
VMDK and VHD images, which the osbuild-composer already supports.
Update go.mod, vendor/ content and SPEC file with new dependencies.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The openstack boot test often ruins our days with:
Waiting for instance 63ac19be-2e19-44e2-8bef-9770d68a190c to become Active
failed: A timeout occurred
I decided to investigate. It turns out the first boot of an image can take
up to 18 minutes. The subsequent ones are usually much faster (but don't rely
on this fact, I saw 15 minutes there).
This commit bumps the timeout to 30 minutes. This should be plenty of time
for the instance to spin up and get into the ACTIVE state.
Honestly, I'm not very happy with the solution but it should help with the
failing Schutzbot. As a follow up, I will reach to the PSI OpenStack team
and ask them if we could somehow speed up the process (maybe by using another
flavor, ci.m1.medium.ephemeral just might be slow for some reason, I don't
know).
Anyway, this should help us in the short term because I strongly believe that
a slow test is still better than a failing one.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
/etc/containers/registries.conf.d/rhel-shortnames.conf shipped in
containers-common-1:1.2.2-1.module+el8.4.0+10073+30e5ea69 has a wrong
shortname for ubi8-minimal:
"ubi8-minimal" = "registry.access.redhat.com/repository/ubi8-minimal"
resulting in `name unknown: Repo not found` when trying to pull the image
via its short name.
Related: rhbz#1931785
Use the new tags of the `osbuild/containers` repository. The
infrastructure was simplified a lot and the new tags are much easier to
handle without any conflicts when building other images.
Note that this change uses the `latest` tag of all images. As an
alternative, we can also switch to the `latest-<date>` tags, which would
use a pinned immutable image tagged by the given date. However, these
tags are burried somewhere deep down in the ./tools/ directory and are
easy to forget upgrading. So for now use `latest` until we have better
synchronization infrastructure in place.
However, if these images ever break and we want to get back stable CI
behavior, we can always switch back to older builds by picking those
immutable tags instead of `latest`.
Signed-off-by: David Rheinsberg <david.rheinsberg@gmail.com>
Explicitly set the kernel to boot into.
Also change the blueprint/kernenl handling:
Rather than only falling back to the default kernel name for
getting the package list, let GetKernel() always return the
correct result so we can rely on this being consistent.
Signed-off-by: Tom Gundersen <teg@jklm.no>
In order to land a PR before osbuild reaches the stable repositories
we pin the verson to test against (which has been pushed out).
This is an exception from our usual procedures as we would otherwise
not be able to land this bug fix for RHEL8.4.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Let's keep this on the same filesystem as the osbuild store, and
in particular stay away from /var/tmp and its scary semantics.
We are not aware of any issues caused by /var/tmp, but getting
rid of it means we don't have to think about that when debugging,
if nothing else.
Signed-off-by: Tom Gundersen <teg@jklm.no>
