Add an additional integration test, which builds a fedora-32 image via
the newly moved composer API.
This adds a new certificate for clients to authenticate, with
CN=client.osbuild.org.
Also stop allowing certificates with `CN=worker.osbuild.org` in the
`osbuild-composer.toml` used in tests and amend `osbuild-auth-tests` to
use `CN=client.osbuild.org` for accessing the koji API.
Heavily based on an earlier version of this test in `test/cmd/aws.sh` by
Sanne Raymaekers.
Base these on https://osbuild.org/rpmrepo.
Install those repository files when deploying in schutzbot and include
them in tools/deploy/test for local testing.
Also remove copying overrides from deploy.sh, because it copied the
wrong files. We probably want to add this back properly in the future.
This removes the osbuild-composer-cloud package, binary, systemd units,
the (unused) test binary, and the (only-run-on-RHEL) test in aws.sh.
Instead, move the cloud API into the main package, using the same
socket as the koji API, osbuild-composer-api.socket. Expose it next to
the koji API on route `/api/composer/v1`.
This is a backwards incompatible change, but only of the -cloud parts,
which have been marked as subject to change.
Instead, call it osbuild-composer-api.socket, but provide a symlink for
backwards compatibility. Change `schutzbot/provision.sh` to only enable
osbuild-composer-api.socket.
In the future, this new socket is the only API socket, which provides
both the "cloud" API and the one for koji.
This means that the koji API is always enabled.
s3cmd from pip doesn't work with Python 3.9. Fortunately, s3cmd in Fedora has
a downstream patch to fix it.
See rhbz#1884607 and https://github.com/s3tools/s3cmd/pull/1137
Fedora 33 ships the new API so let's do the switch now.
But... this would break older Fedoras because they only have the old API,
right?
We have the following options:
1) Ship xmlrpc compat package to Fedora 33+. This would mean that we delay the API switch till F32 EOL. This would be the most elegant solution, yet it has two issues: a) We will surely not be able to deliver the compat package before F33 Final Freeze. b) It's an extra and annoying work.
2) Downstream patch. No.
3) Use build constraints and have two versions of our code for both different
API.
I chose solution #3. It has an issue though:
%gobuild macro already passes -tags argument to go build. Therefore the
following line fails because it's not possible to use -tags more than once:
%gobuild -tags kolo_xmlrpc_oldapi ...
Therefore I had to come up with manual tinkering with the build constraints
in the spec file. This is pretty ugly but I like that:
1) Go code is actually clean, no weird magic is happening there.
2) We can still ship our software to Fedora/RHEL as we used to
(no downstream patches)
3) All downstreams can use the upstream spec file directly.
Note that this doesn't affect RHEL in any way as it uses vendored libraries.
Fedora 33 ships kolo/xmlrpc with a different API. This commit extracts the
affected code so we can use build flags in the future allowing us to use
both API versions.
Currently, we have osbuild-image-tests binary committed in the master branch.
IMHO the root cause is that we don't have it in .gitignore. Actually, I think
that it is pretty hard keep .gitignore in sync with the build target.
This commit solves the situation by putting all the built binaries into bin
directory and adding this directory into .gitignore. This way, it's much
harder to actually commit a new Go binary into repository.
This commit doesn't remove the binary as #1017 already does that.
The issue comes from the fact that the PR introducing it was very old
and meanwhile the variable used for image name creation has changed.
This patch makes sure both functions are the same.
%gotest ./... was failing on ELN because it couldn't find the vendored
dependencies.
Let me explain why this worked before:
In Fedora, we don't use vendored deps, therefore we had no issue.
In RHEL8, we use vendored deps and -mod=vendor with GO111MODULE unset.
In this case, vendored deps were indeed used.
However, ELN added GO111MODULE=off. When modules are disabled, -mod=vendor
is ignored[1]. It turns out that go with disabled modules uses vendor directory
only in case when $(pwd) is inside GOPATH. Don't ask me why.
Therefore, this fix uses cd to ensure that pwd inside GOPATH (even though
technically we're still in the same directory).
Note that in %build we already had this magic cd command, therefore it wasn't
an issue there.
[1]: Actually `GO111MODULE=off go build -mod=vendor` returns an error. However,
`GO111MODULE=off GOFLAGS=-mod=vendor go build` just ignores the go flag from
env.
Fixes #rhbz1884383
Add a simple unit test for the koji API.
This adds a Handler() method to the koji.Server struct, which made
writing the test easier. This is a direction we want to go in anyway in
the future.
In case the job fails completely, resources might leak. This patch
together with the one introducing predictable names for CI artifacts
will make sure we wipe all resources after each CI run.
Lorax-composer won't be shipped into Fedora 34. To upgrade users from it to
osbuild-composer we need to obsolete it in our spec file.
Fixes RHBZ#1886405
tools/gen-user-data generates a cloud-init user-data file from a
configuration directory. It is mostly useful to embed files in the
user-data.
tools/deploy-qemu uses above tool to make a user-data file and spins up
a virtual machine with it. This is useful to locally run, test, and
debug osbuild-composer.
A simple user-data directory for running tests locally is included in
tests/deploy-user-data. It expects a repository with osbuild-composer
rpms to be served on the host's port 8000.
The -test subpackage should depend on all that it needs, and we should
never need to install anything explicitly from the test scripts.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Deployment is specific to CI, but the provision script is needed to be
run to execute tests locally too.
This should be called from each test, rather than from deploy. For now
this change is a noop.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This was made a weak dep, so we need to be explicit about it:
```
Author: Jonathan Lebon <jonathan@jlebon.com>
Commit: Lokesh Mandvekar <lsm5@fedoraproject.org>
spec: make podman-plugins a weak dep
That way someone who wants just podman doesn't also get dnsmasq. This is
a point of contention in FCOS currently:
https://github.com/coreos/fedora-coreos-tracker/issues/519
(cherry picked from commit 217f4344ec796dd1134a5ba54a8ce2fb5a32a5b6)
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
```
Signed-off-by: Tom Gundersen <teg@jklm.no>
Our snapshots are currently broken, so until they are fixed revert back
to using an internal RHEL nightly. We choose a slightly older one,
in the hope that it is not going to be deleted anytime soon.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Also install it is part of he tests subpackage. This a helper-tool, not
golang code, so should not live in `internal`. We need access to this
from the integration tests, so install it onto the tests system.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is obviously not a good long-term solution, but at least the fedora
version of the binary has a build-id so RPM will not complain.
Signed-off-by: Tom Gundersen <teg@jklm.no>
No tests should be run directly from git, but should rather be installed
onto the test system using rpm and run from there. This moves towards
unifying our two types of test cases.
The new structure of is now:
`test/cmd`: the executors, one for each test-case. This is installed
into `/usr/libexec/test/osbuild-composer`.
`test/data`: data and config used by the tests. This is installed into
`/usr/share/tests/osbuild-composer`.
`schutzbot`: configuration of the actual test run. In particular, this
is where the distros and repositories to test against are
configured.
This is very much still work-in-progress, and is only the first step
towards simplifying schutzbot. Apart from moving files around, this
should be a noop.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We already have something called image-tests, so this naming was
confusing. This is a collection of generic integration tests, so name
them accordingly.
Signed-off-by: Tom Gundersen <teg@jklm.no>
These had the generic name osbulid-tests, rename the binary to more
closely describe what is under test: weldr API as composed by
composer-cli.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Fedora 33 images can now be built and test cases are added for the new
images. The fedora 33 qcow2 and vmdk images are based off of the
official images and their kickstarters found here:
https://pagure.io/fedora-kickstarts. The fedora 33 iot image is based
off of the the config found here: https://pagure.io/fedora-iot/ostree.
The openstack, azure, and amazon image types have changes made to them
based off of the changes made to the qcow2. The changes between fedora
32 and fedora 33 are as follows:
Grub now loads its kernel command line options from
etc/kernel/cmdline, /usr/lib/kernel/cmdline, and /proc/cmdline instead
of from grub env. This is addressed by adding kernelCmdlineStageOptions
to use osbuild's kernel-cmdline stage to set these options. Alongside
`ro biosdevname=0 net.ifnames=0`, we also set `no_timer_check
console=tty1 console=ttyS0,115200n8` per what is set in the official
qcow2. For azure and amazon, the kernelOptions are still set as they
were in fedora 32.
The timezone is now set to UTC if a user does not set a timezone in the
blueprint customizations. Also, the hostname is set to
localhost.localdomain if the hostname isn't set in the blueprint.
Finally, the following packages have been removed:
polkit
geolite2-city
geolite2-country
zram-generator-defaults
Split the actual service into its own type `Composer` in composer.go.
main.go now (more or less) contains only collecting configuration from
the environment and the file system, as well as activation file
descriptors.
Aside from making the code easier to grok, this is a first step towards
running composer in a different environment than the one set up by
systemd.
The default values of fields in both ComposerConfig.Koji and
ComposerConfig.Worker are well-suited for how they're used.
The nil-checks in main.go only checked that the sections exist. This is
quite a weak check for validity, because the sections could be empty. If
anything is required for composer to function, we could add proper
validation in the future.
Do the same for the CA fields, which contain file names. Go has lots of
precedent for using empty strings to denote "no value" in the standard
library. Use it for CA files, too, instead of pointers.
