The enabled bool is now being used so the cli should only show the types
actually available on the architecture.
Also modifies the test in test_compose_sanity.sh
Related: rhbz#1751998
when testing downstream snapshots this makes sure that
lorax-composer and composer-cli are coming from the host OS.
We also make 100% sure that there are no other repositories inside
the VM other than what has been configured on the host!
Make it possible to override where repo files are copied from by
defining the REPOS_DIR variable. By default the value is
/etc/yum.repos.d
This adds cloud-init support to the vhd image.
Also limits the cloud-init datasource to Azure, and includes
cloud-utils-growpart to expand the filesystem to fit the available
space.
Resolves: rhbz#1754711
The callers, and the documentation, all expect int 0/1 to use as the
exit status for the program. Not True/False, even though that works most
of the time.
Graft them from tmpdir instead of trying to use the source iso for some,
and tmpdir for the ones needing changes. This will prevent problems with
trying to remove files likes TRANS.TBL from a read-only filesystem.
These use beakerlib to download a Fedora boot.iso and run mkksiso on
it. It currently does not try to boot the resulting iso, it mounts it
and checks that the expected config files have been modified and the
extra files have been added.
This tool will add the kickstart to the boot.iso, edit the kernel boot
arguments so that the kickstart is used when the iso boots, as well as
allow adding extra files and directories to the / of the iso which can
then be used by the kickstart (they are found under /run/install/repo
while Anaconda is running).
This builds a boot.iso in the vm, copies it out, and boots it.
The tests that run inside the boot.iso
(/tests/lorax/test_boot_bootiso.sh) cannot use beakerlib so it needs to
be a simple shell script returning 1 on failure along with a descriptive
message.
The cockpit tests assume logging in as non-root, but that isn't always true
when testing things like boot.iso images. So this checks for ssh login without
checking for /run/nologin
Also sets default image to testvm.DEFAULT_IMAGE so that testvm doesn't
need to be imported by users of the class.
to help with running the tests by hand on downstream snapshots.
In that scenario we want TEST_OS/VM_IMAGE to look as closely as
possibly like the snapshot that we'd like to test.
bcl: The mirrors are not very good at staying in sync, and if
composer hits one mirror and anaconda hits a different mirror,
you will see depsolve fail. The safest thing is to not use mirrors
in Fedora.
/var/log/audit/audit.log isn't always available (eg. tar liveimg
install), but it is logged to the journal, which can be grepped with
'journalctl -g' so use that instead.
Note: use podman-docker to avoid changing tests too much. This
is also what we have on the RHEL branches.
There's no service to be started/restarted so remove everything
related to docker service.
On Fedora 31 passworless root login is no longer working. We already
install a ssh key, may as well use it.
This also reduces the live boot timeout to 2s from 60s, which should
help with timeout problems when booting.
This splits out the lorax-composer specific execution so that the built
image can be downloaded from the build vm and booted by the host instead
of using nested virt to try and boot it inside the build vm.
Also adds copying the ssh key from the build vm so that it can log into
the image and run the test_boot_* scripts.
Nested virt is not reliable enough, especially on other arches, to rely
on for testing the created images. This moves the test code into
test_boot_* scripts to be run from inside the booted images.
It also adds copying the results of the build into
/var/tmp/test-results/, and includes the generated ssh key so that
whatever boots the image can also log in.
The tests/test_image.sh script has been added to handle running the
test_boot_* scripts without any of the extra lorax-composer specific
setup.
These are two sides of the same variable (domacboot) so sphinx-argparse
generated docs are a bit confusing. Override the docs for them to clear
things up.
The 'enabled' field in the /compose/types output now reflects whether or
not the type is supported on the current architecture. Disabled types
are not allowed to be built, and will raise an error like:
Compose type 'alibaba' is disabled on this architecture
