This makes it easier to use the test binary with the `-run` argument.
Instead of the full path:
-test.run TestImages//usr/share/tests/osbuild-composer/cases/rhel_8.2-x86_64-openstack-boot.json
this only requires the actual name:
-test.run TestImages/rhel_8.2-x86_64-openstack-boot.json
When edd7b37ea added `--output-directory` to the invocation of osbuild,
it also removed `--store`.
This was a mistake: osbuild's default store is `.osbuild`, which is not
what we want. Restore the old behavior of passing a temporary directory,
but use the same for each test run.
Treating stdout and stderr separately makes it hard to match what
happened when. It's also easy to miss when `-v` is passed to the test
binary.
Print the output to stdout when osbuild fails, because the test
framework we're using does not print errors if they're too large.
Also, don't special-case exec.ExitError. Output might be useful in any
case.
Previously, all the osbuild-composer tools must be run from a directory with
dnf-json. This was often confusing, especially with the dnf-json-tests. This
commit changes the path to be absolute, so this is no longer an issue.
RPMMD had hardcoded path to dnf-json helper. This required all executables
using RPMMD to be run in the directory where dnf-json was located. This commit
makes RPMMD take the path to dnf-json as an argument. This allows its
consumers to specify whichever path they want.
Not a functional change
qcow2, unlike ami, is guaranteed to exist on all the architectures we
support.
Also, now that we preserve the cache, make two composes, rather than
just one. This verifies that nothing breaks horribly just because the
cache not being cold. The fact that we have a cache at all should make
this tolerably fast.
This should fix#693.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Schutzbot currently runs all the same tests an all arches/distro
combinations. This will not work as we introduce image types only on
some distro/arches.
In the future we should make the image-test binary more clever, so
Schutzbot won't have to tell it which cases to run at all. For now,
simply don't fail if the specified test-case does not exist.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is not a functional change, just helps to make the output more
readable to indicate which sub-command is being tested.
Signed-off-by: Tom Gundersen <teg@jklm.no>
most invocations of composer-cli do not need to parse JSON so use
the canonical invocation instead. I've left existing functions
which assert on the returned results intact.
'quiet' parameter has been removed b/c it was never used
Until osbuild-14, the images were unconditionally kept in the cache,
meaning the cache could grow very large. Now only the downloaded RPMs
are saved, which greatly limits how big it can grow.
Having the RPMs cached should speed up all but the first image build a
lot, so we should take advantage of that by not flushing the cache
between each build.
The cache is still flushed when the worker is stopped / restarted.
This moves the cache from /var/tmp/osbulid-worker* to
/var/cache/osbulid-worker/osbulid-worker-*. This means that each worker
gets a dedicated cache, in case there are several on one machine. In the
future we may want to combine them and only ever have one cache, but for
that we need improvements in parallel access and cache-cleanup.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This commit changes the store.PushSource function to take the key as
well as the SourceConfig so that it can be used for v0 or v1.
It adds helper functions for decoding the toml/json into a new
SourceConfig interface type which lets the core source/new code be
shared between the versions.
It also adds tests for the new API behavior.
The new tool osbuild-store-dump saves store.json to the current working
directory, with more or less arbitrary data in it.
This has been executed on osubild-composer-{12,13} (mutatis mutandis),
and the results are saved in `internal/store/test`. A new test is added
which loads these stores and does very basic verification on them having
been loaded correctly.
This is mostly meant to catch regressions that means old stores are able
to make composer crash, or lose all its data. It would not catch minor
errors that leave the stores syntactically correct.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Rather than Manifest() returning an osbuild.Manifest object, introduce a
new distro.Manifest object which represents it as an opaque, JSON
serializable object. This new type has the following properties:
1) its serialization is compatible with the input to osbuild,
2) any valid osbuild input can be deserialized into it, and
3) marshalling and unmarshaling to and from JSON is lossless.
This means that even as we change the subset of valid osbulid manifests
that we support, we can still load any previous state from disk, and it
will continue to work just as before, even though we can no longer
deserialize it into our internal notion of osbuild.Manifest.
This fixes the underlying problem of which #685 was a symptom.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This is how it is used in the rest of the code, as a name to represent
the repository in the weldr API. Rename to match its use, and avoid
confusion with the ID passed to dnf-json, which is not the same.
Signed-off-by: Tom Gundersen <teg@jklm.no>
When fdd753615 added `--output-directory` to the invocation of osbuild,
it also removed `--store`.
This was a mistake: osbuild's default store is `.osbuild`, which is not
what we want. Restore the old behavior of passing a temporary directory.
The `jobs/:job_id/builds/:build_id/image` route was awkward: the
`:jobid` was actually weldr's compose id and `:build_id` was always `0`.
Change it to `jobs/:job_id/artifacts/:name`, where `:job_id` is now a
job id, and `:name` is the name of the artifact to upload. In the
future, it could support uploading more than one artifact.
This allows removing outputs from `store`, which is now back to being a
pure JSON-store. Take care that `weldr` returns (and deletes) images
from the new (or for backwards compatibility, the old) location.
The `org.osbuild.local` target continues to exist as a marker for the
worker to know whether it should upload artifacts.
When generating an osbuild manifest for an image type, we take a
customizations struct, which specifies the image-type-independent
customizations to apply. We also take the size argument, which is
specific to the image build and not part of the blueprint.
Introduce a new argument ImageOptions, which for now just wraps the size
argument. These options are specific to the image build/type, and
therefore does not belong with the other customizations.
For now this is a non-functional change, but follow-up commits will
introduce more types of image options.
Signed-off-by: Tom Gundersen <teg@jklm.no>
see this comment from @teg:
https://github.com/osbuild/osbuild-composer/issues/356#issuecomment-630766947
Most of the calls within these tests should be converted to
use the plain text version. However some functions need the
JSON b/c they parse it and return a response, e.g. startCompose(),
getComposeStatus().
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>
Our current tests cannot currently check if the logs can reach all the way
from the worker to the weldr API. This commit adds a simple check that
the /compose/log route returns at least something.
Also the logs are printed when the compose fails.
This does not yet actually upload the image, and it only supports empty
images. You need to place a an empty file named <filename>, with a valid
extension (e.g., .qcow2) in /mnt/koji/work/<directory>/.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This reduces the amount of resolving and error checking we have to do.
This exposed a bug in weldr's ComposeEntry type, which will be fixed in
a follow-up commit.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This results in better output. Output before this swap can be
seen at https://github.com/osbuild/osbuild-composer/issues/611.
It looks like we wanted a compose to FAIL and it FINISHED instead
which is making the error log confusing.
RHEL 8 doesn't have qemu-system-x86_64 in PATH. Instead, it is in
/usr/libexec/qemu-kvm. This commit fixes that by detecting the host
distro and choosing the right binary.
t.Parallel() makes defer weird. This commit moves the temporary dir setup
and teardown to the parallel subtest, so the teardown gets called after
the tests are finished.
More detailed explanation:
Consider this code:
```go
t.Run("group", func(t *testing.T) {
setUp()
t.Run("parallel test1", parallelTest1)
t.Run("parallel test2", parallelTest1)
t.Run("sequential test", sequentialTest)
cleanUp()
})
```
When the group subtest is started, firstly parallelTest1 is run. When
t.Parallel() in the parallelTest1 is hit, its execution is suspended and
parallelTest2 is started. Once again, t.Parallel() is hit and the
parallelTest2 is suspended. Now, sequentialTest is started. It doesn't
contain t.Parallel() so it's run without any interruptions. The group subtest
continues its execution and calls the cleanUp method. After the cleanup is
done, the group subtest returns and it's time for the important part:
The parallelTest1 and 2 are resumed and run in parallel. In other words,
the code after t.Parallel is run when the PARENT subtest returns.
The important (and weird) part is that the parent subtest of the parallel
subtests returns before its parallel children finish. However, just the inner
anonymous function returns. The containing t.Run("group", func(){...})
function does not return until all the parallel subtests are finished.
How to solve this? One solution is to move the cleanup out of the group
subtest:
```go
t.Run("group", func(t *testing.T) {
setUp()
t.Run("parallel test1", parallelTest1)
t.Run("parallel test2", parallelTest1)
t.Run("sequential test", sequentialTest)
})
cleanUp()
```
How does this work? The group subtest is not marked as parallel, so it just
runs from its beginning to its end (including the parallel subtests). After
it finishes, then the cleanUp is called.
In this commit I chose a different method: I just moved the clean up into each
parallel subtest. I think this is clearer than all that parallel magic I
tried explaining in previous paragraphs.
See the section "Run a group of tests in parallel":
https://blog.golang.org/subtests
and this paragraph:
https://golang.org/pkg/testing/#hdr-Subtests_and_Sub_benchmarks
This makes the queue more type safe and allows to get rid of the
`pendingChannel` and `pendingChannels` helpers, which only existed to
create not-yet-existing pending channels.
Since 2 releases `osbuild` accepts an `--output-directory=DIR` argument
which lets us decide where to place generated artifacts. Switch over to
it, rather than digging into the store, to make sure we will not access
the osbuild store when parallel cleanups are ongoing (which are not yet
a thing, though).
The store is responsible for two things: user state and the compose queue. This
is problematic, because the rcm API has slightly different semantics from weldr
and only used the queue part of the store. Also, the store is simply too
complex.
This commit splits the queue part out, using the new jobqueue package in both
the weldr and the rcm package. The queue is saved to a new directory `queue/`.
The weldr package now also has access to a worker server to enqueue and list
jobs. Its store continues to track composes, but the `QueueStatus` for each
compose (and image build) is deprecated. The field in `ImageBuild` is kept for
backwards compatibility for composes which finished before this change, but a
lot of code dealing with it in package compose is dropped.
store.PushCompose() is degraded to storing a new compose. It should probably be
renamed in the future. store.PopJob() is removed.
Job ids are now independent of compose ids. Because of that, the local
target gains ComposeId and ImageBuildId fields, because a worker cannot
infer those from a job anymore. This also necessitates a change in the
worker API: the job routes are changed to expect that instead of a
(compose id, image build id) pair. The route that accepts built images
keeps that pair, because it reports the image back to weldr.
worker.Server() now interacts with a job queue instead of the store. It gains
public functions that allow enqueuing an osbuild job and getting its status,
because only it knows about the specific argument and result types in the job
queue (OSBuildJob and OSBuildJobResult). One oddity remains: it needs to report
an uploaded image to weldr. Do this with a function that's passed in for now,
so that the dependency to the store can be dropped completely.
The rcm API drops its dependencies to package blueprint and store, because it
too interacts only with the worker server now.
Fixes#342
-cpu host cannot be used with anything else than kvm. This commit removes
hvf and tcg because it doesn't make any sense with -cpu host.
If this causes some issues for anyone, we can revert back and remove -cpu
host.
Running qemu with -accel accel= results in the following error:
qemu-system-x86_64: -accel accel=kvm:hvf:tcg: Don't use ':' with -accel,
use -M accel=... for now instead
Qemu 4.2 deprecated the -accel accel= argument. When the arg is passed in,
qemu exists status code of 1.
This commit changes the qemu command to use the recommended way of specifying
the acceleration options.
See:
3d5e90a50b
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.
The cmd/osbuild-image-tests package is becoming bigger than I would like to.
It will be nice to split it to some smaller pieces at some point.
This commit does the first step - splits off the first subpackage containing
all the constants.
