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.
The commit 2435163f broke sending the logs to osbuild-composer. This was
partly because of unusual error handling in the RunOSBuild function.
This commit fixes that by creating a custom error and properly propagating
the result from it.
This commits enables the parallelism for the image tests. However, there's
a catch. Osbuild cannot be reliably run in parallel, so the code uses
a mutex to ensure there's always only one osbuild instance for now. Even
with this limitation, there's a significant speed-up of the tests:
Prior this commit, the image tests run in 40 minutes on Travis. After this
commit, the time is reduced to 32 minutes.
The speed-up will have an even bigger effect when more cloud-upload tests are
added to the test suite.
Run multiple dnf-json tests in parallel to speed up execution. The
total number of parallel tests is limited by the number of CPUs in
the machine that is running the tests.
Signed-off-by: Major Hayden <major@redhat.com>
Speed up the boot tests by allowing qemu to use all of the available
CPUs on the system. Our CI VMs have at least 2 CPUs and this shortens
the time required for a boot test.
Signed-off-by: Major Hayden <major@redhat.com>
This package does not contain an actual queue, but a server and client
implementation for osbuild's worker API. Name it accordingly.
The queue is in package `store` right now, but about to be split off.
This rename makes the `jobqueue` name free for that effort.
The osbuild-image-tests don't currently support boot test for any
alternative architecture because the qemu-system-x86_64 command is
hardcoded. This patch introduces a branch specific to aarch64, but
without a KVM support as I was unable to make it run in Beaker, which is
currently the only offering we have with ARM machines. As a workaround
the boot tests will be skipped if kvm kernel module is not found and only
image-info tests will run.
For one, this allows us to use `require` instead of `assert` and
`continue`, which was awkward to read. That works because it's ok to
fail a subtest: the remaining subtests are executed after it.
Also, this shows which test was executed, making debugging easier:
=== RUN TestCrossArchDepsolve
=== RUN TestCrossArchDepsolve/fedora-30
=== RUN TestCrossArchDepsolve/fedora-30/x86_64
=== RUN TestCrossArchDepsolve/fedora-30/x86_64/ami
...
You can now also run those sub tests in isolation:
osbuild-dnf-json-tests -test.run TestCrossArchDepsolve/fedora-30/x86_64/ami
Lastly, it enables running those tests in parallel (not part of this
patch) by calling `t.Parallel()`.
This function prints the formatted unexpected error message, instead of
the error struct in golang syntax.
It also allows to remove the error in the assertion message.
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.
It's not very clear that the constants are indeed constants. This commit moves
them to a new struct. This way it should be more clear that those values are
constants.
