In the future remote workers will be introduced. Obviously, the remote worker
cannot support the local target. Unfortunately, the current implementation of
storing the osbuild result is dependant on it.
This commit moves the responsibility of storing osbuild result to the
composer process instead of the worker process. The result is transferred from
a worker to a composer using extended HTTP API.
Generating a SHA-1 based on time is not safe. A collision can easily be
generated, and if parallel operations are used they will eventually
collide. This reads random bytes and uses them for the SHA-1 hash. It
will return an error if the rand.Read() fails.
Otherwise if there is an error creating result.json or if the Run
command failed it will remain owned by root.root and cannot be deleted
via the API.
Closes#204
In the current state, osbuild-pipeline exits with random golang error,
such as goroutine failed, which is not at all helpful. This PR
introduces CLI arguments validation and helful error messages that use
the newly introduced types so that we don't waste time guessing what
was the right way to invoke this tool.
We currently use strings for passing arches and image types around,
which is not ideal. We should have a finite set of supported image types
and architectures as well as upload targets. This PR introduces custom
types to make the code base more readable and possibly also more
correct.
I considered some alternatives like a struct with private fields, but struct cannot
be const, so that does not help either. Eventually I think this is the "get s**t done"
solution.
The package also includes unit-tests which try to convert string to
structure and the other way around to make sure it all works properly.
Our current crypt implmentation requires glibc to be available on the
developer's system. But it is not strictly necessary, because I'd like
to run at least unit tests on mac. This PR makes it possible to compile
and run unit-tests on mac, but it will panic if someone tries to run
osbuild-composer on mac.
When creating a compose the desired image size can be set. If the image
type is a VHD the image size is rounded up to the nearest MB since all
VHDs on Azure must have a virtual size aligned to 1 MB.
When creating a pipeline the assembler includes an image size. This
image size can be set when creating the pipeline but if it is 0 then a
default image size will be used. The default is 2 GB except for ami
images which are 6 GB.
It contains two basic endpoints:
* POST /v1/compose
* GET /v1/compose/<uuid>
It passes all the tests, but cannot be used for the intended use case
because the store API does not (yet) support distributions and
architectures as a parameters.
During development of a new distro, we need to test composer against
nightly or beta repositories, but we cannot ship composer itself
with the nightly repository information hardcoded in. At the same
time, we want to distinguish between the system repositories of the
host and the repositories we use to generate images (the host may not
use the same distro/version/architecture as the target, and it may
include custom repositories that the target should not).
We therefore ship per distro repository information that can be
overriden (typically in testing) by dropping files in /etc.
For now use the latest nightlies for RHEL-8.2, we may want to
replace these with the official mirrors for GA eventually.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We were using fedora-30 as a test-distro and tar as test-output, but
that causes lots of churn in the tests when we refactor things. Use
the test distro instead, when generic functionality is being tested
and restrict testing of the individual distros to the distro-specific
tests.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Introduce a DistroRegister object. For now this does not introduce
any functional changes, as the object is always instantited to be
the same. However, in follow-up patches it will get options.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Commit b1c5ef2a introduced support for retrieving logs from osbuild.
This commit finishes the second part - actually returning the logs
from /compose/logs route.
dnf-json relies on dnf's ability to cache repository metadata. This is
important, because the API calls it quite often to serve requests for
package lists and depsolves.
However, osbuild's dnf stage always fetches new metadata, because it
doesn't have access to the host's cache. Since metadata is valid for
some time, even after a repository changed, the checksum we put in
the pipeline might be old.
Force a new metadata download when producing the pipeline. This is still
not perfect, but greatly reduces the probability of putting stale
metadata into the pipeline.
When restarting composer, we were not handling the compose states
correctly.
This resolves that as follows:
* any running composes are marked as failed,
* any waiting composes are put back in the pending jobs queue
As a consequence of needing the ability to reinitialize the job
queue, we must include the depsolved pipeline in the compose object.
This is the correct thing to do, as the semantics we currently
adhere to is that pipelines are depsolved when the compose is
started (and restarting composer should not affect this by for
instance re-depsolve the pipeline).
Resolves rhbz#1784062.
Signed-off-by: Tom Gundersen <teg@jklm.no>
When group names are passed on to dnf, they must be prefixed with an
ampersand, or they are treated as a regular package, potentially
causing the build to fail.
Add a testcase to verify this behavior.
This resolves rhbz#1784035.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Right now, there is no way to get at the name from a Distro instance.
We will need this to include the distro's name in the job we pass to the
worker, for instance.
On architectures that require EFI, we must create the ESP partition
and use a GPT partition table. We must also install either the UEFI
or the legacy version of GRUB2 in the image.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Move to the new options format, allowing more flexible partition
tables. The pipeline changes, but the result should be the same.
This requires a yet-to-be-released version of osbuild.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Allow bootloader specific packages to be defined per architecture,
and allow repositories to depend on the architecture.
This does not altert he pipelines we produce, part from the ami
image now contains the grub2-pc package, rather than the grub2
package. This should make no difference.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We must make sure not to depend on the modules loaded in the host
kernel. This makes the initrd the same between different hosts.
Signed-off-by: Tom Gundersen <teg@jklm.no>
