This patch contains refactoring of the part where we handle
customizations. Previously customizations were considered an "image
type" which is not obvious. Now it is a command line switch.
Add Fedora 32 test cases with the base OS + updates (to work around
aarch64 bugs in the original release). Add updates for Fedora 31 for
consistency.
Fixes#861.
Signed-off-by: Major Hayden <major@redhat.com>
Although the vhdx format is smaller than raw, AWS often has some issues
booting instances from an imported vhdx snapshot. The raw format seems
to boot consistently at AWS.
Fixes#754.
Signed-off-by: Major Hayden <major@redhat.com>
Add one test-case per distro that tries to cover all the customizations
we support.
For now omit firewall customizations, as there are open questions about
how to support that on all image types.
Signed-off-by: Tom Gundersen <teg@jklm.no>
The fact that we have two scripts and one captures output of the other
makes it hard to use in scenarios where the test case generation often
fails. This output capturing results in subtle bugs like described in
issue: https://github.com/osbuild/osbuild-composer/issues/769
This patch merge these two scripts and use class to organize it
instead of files.
This patch introduces support for s390x architecture. It has some
specific requirements like using kernel-cmdline stage before the RPM
stage because RPM scriptlets require these values to be present in the
system already. It also uses zipl stage and bootloader as opposed to all
the other architectures.
Also allow a list of them to be passed. Generating 'all' image types
makes less sense now that different distros/arches support different
ones.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Allow individual test-cases or sub-sets of test-cases to be generated
more easily.
We allow explicit skipping of image-info generation (and hence the
osbuild run), and also individual image types to be specified.
Also drop distros and image types that are no longer supported.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Allow a test case to be generated for a specific image type, rather than
for all at once.
This is useful when adding additional image types, rather than
regenerating the existing ones.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is a very minimal image type, which is not expected to do anything
with an empty blueprint. It is documented as a way to install RHEL for
Satellite.
This fixes#720.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Commit 8dd4554491 introduced a bug because
the output from osbuild is not captured. The problem is that osbuild
itself writes JSON document to STDOUT so two different JSON documents
are written to STDOUT: osbuild output and generated test case. The
generate-test-cases script then fails because it cannot json.loads() the
test case.
This patch simply supresses the output which fixes the issue.
As it turns out, the default expectation is not to distinguish between
these. We will now produce whatever is the most recent minor release by
default, and image tests will still be pinned at a given snapshot to be
reproducible.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Previously, vhd images were tested using QEMU. This commit changes that to
boot them in the actual Azure infrastructure.
Azure VMs have quite a lot of dependencies - a network interface, a virtual
network, a network security group, a public ip address and a disk. Azure CLI
and Azure Portal handle the creation of all these resources internally.
However, when using the API, the caller is responsible to create all these
resources before creating an actual VM.
To handle the creation of all the resources in the right order, a deployment
is used. A deployment is a set of resources defined in a JSON document.
It can optionally take parameters to customize each deployment. After the
deployment is finished, the VM is up and ready to be tested using SSH.
Sadly, the deployments are a bit hard to clean-up. One would expect that
deleting a deployment removes all the deployed resources. However, it doesn't
work this way and therefore it's needed to clean up all resources "manually".
For this reason, our deployment sets a unique tag on all the resources created
by the deployment. After this test is finished, the API is queried for all
the resources with the tag and then, they're deleted in the right order.
Requests to download.fedoraproject.org are redirected to a regional
mirror that is fairly close to the system that is making the request.
This could speed up downloads slightly since it avoids using the
Fedora proxies.
Signed-off-by: Major Hayden <major@redhat.com>
Prior this commit the ami image type produced raw.xz images. This was bad for
two reasons:
- The upload was broken because AWS doesn't support tar.xz format
- XZ compression is terribly slow
This commit changes the format to vhdx, which is supported by AWS and also
quite quick. See https://github.com/osbuild/osbuild-composer/issues/257
why vhdx was chosen.
Fixes#257
In PR #400:
https://github.com/osbuild/osbuild-composer/pull/400
we changed the boot type of AWS images from qemu-extract to aws, which
resulted in a bug in the generate-test-case script. It tried to attach
xz archive using qemu-nbd which works just fine from qemu-nbd
perspective but sfdisk and blkid of course failed, because the xz
archive is not a disk image.
This patch makes sure we extract the image before attaching it to
/dev/nbdX.
The current implementation does not report any errors because it uses
the subprocess.check_output function from Python std library. The
function is convenient to use but it hides all the errors from us which
makes it very inconvenient when the test generation often fails (like
developing support for alternative architecture). This patch introduces
a wrapper around the subprocess.run function which dumps the
subprocess's stdout to stderr in case of failure and forwards it to the
caller in case of success. This way the generation code is still very
straight forward, but the errors are reported properly.
Prior this commit the ami images were tested locally using qemu. This does
not reflect at all how they're used in practice. This commit introduces
the support for running them in the actual AWS. Yay!
The structure of code reflects that we want to switch to osbuild-composer
to build the images soon.
Rather than use the round-robin mirror, use a fixe stable one.
We should not over-use this, but it seems the round-robin one is
simply too unstable for our tests.
Eventually, we want to use metalink here instead, but we need to
rework the file source first, so we can do that in a way that
does not make the tests dependent on the time/place the test
case was generated (currently the URL to a specific mirror ends
up pinned in the test-case).
Signed-off-by: Tom Gundersen <teg@jklm.no>
Require repository informaiton to be passed as input, rather than
read from the current directory.
Reading from the repository informaiton meant to be used by weldr
has several drawbacks.
- it makes it impractical to use the tool outside a git checkout
- it makes it awkward to adapt the repositories to different use
cases
- it means that the shipped repositories cannot be extended with
update repos, as the same repos are used for testing, and that
would render our tests non-reproducible.
Overall, we are moving towards making repositories something the
caller must always pass in, rather than something that composer
maintains. For the weldr API we need to keep working as before,
but for new APIs we are avoiding that.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This means that the unit tests no longer need to load the
repositories from the git repo, and in a follow-up, osbuild-composer
won't need to either.
By splitting the repositories used for testing from the system
repositories available through the weldr API we are able to extend
the system repositories without affecting the reproducibility of
the tests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This script generates json test cases for each supported output format.
It requires an architecure, distro, osbuild store, and output directory
as input. There is also a json object which maps from output format to a
test case request which includes the compose request and boot type.
The script uses these test case requests to call the generate-test-case
script and then outputs the resulting json test cases to files in the
specified output directory.
The generate-test-cases no longer maps from output format to boot
type. Instead, the boot data is passed in through the standard input
alongside the composer-request object.
The script generate-test-cases only creates a single test case per run.
Therefore, the name should be singular. Also, this script has been moved
to a directory which will contain all test case generators.
