System repos cannot be overridden by users, return an error if they try
to push a source with the same name/id as a system source.
Resolves: rhbz#1915359
The last imagefactory nightly did not contain dnf-plugin-spacewalk,
fwupd, nss, or udisks2. These packages are now excluded. The
udisks2.service and mdmonitor.service are no longer enabled. Also, the
fwupd-refresh, mdcheck_continue, mdcheck_start, and mdmonitor-oneshot
timers are no longer listed as disabled services.
The packages in the last imagefactory nightly differ from ours. The
following packages are now added:
oddjob
oddjob-mkhomedir
psmisc
authselect-compat
rng-tools
dbxtool
Also, the rngd and nfs-convert services are enabled.
Adding the tag called `Name` to the AMI ensures that the name appears in
the *Name* column inside AWS' web console.
Fixes#1171.
Signed-off-by: Major Hayden <major@redhat.com>
An image only had a systemd stage added if its blueprint contained
services or if its image type contained enabled services. The systemd
stage is now also added if the image type contains disabled services or
a default target.
The RHEL 8.4 qcow2 image type now specifies the multi-user default target.
In order to test this the image-info tool now includes the default
target in its output. Image test manifests are updated to include this
change.
Send requests to the compose/{id}, compose/{id}/logs, and
compose/{id}/manifests using job IDs for non-finalize type jobs to test
the type verification.
The type verification introduced in the previous commit is now also used
when retrieving the job status (GET /compose/{id}) and the logs (GET
/compose/{id}/logs).
In these cases, job retrieval needs to be performed twice:
1. First the job parameters are retrieved (Job()) to check the type.
2. Then the job result is retrieved (JobStatus()) for the status or
logs.
This makes it unlikely (essentially impossible) that the retrieval will
fail with "not found" on the second retrieval (JobStatus()), but it's
still a good sanity check for the system.
Verifies the Koji job types when retrieving Init and Build jobs as well.
When a job's arguments are retrieved (for the /manifests API endpoint),
the incoming ID should correspond to a Finalize Job. The new
worker.Job() method helps us verify the type and produce an error if the
wrong type is found.
Similarly, the dependencies of a Finalize Job should be in order (Init
Job first followed by Build Jobs). The types are validated while
iterating the dependency list.
Added convenience functions that check the retrieved job type and return
the initialised struct or an error if the ID is not found or does not
match the type.
Currently the getInitJob() function isn't used but it will be useful
later.
JobArgs() function replaced with more general Job() function that
returns all the parameters used to originally define a job during
Enqueue(). This new function enables access to the type of a job in the
queue, which wasn't available until now (except when Dequeueing).
1. Test retrieving the job arguments from the worker using an
OSBuildJob.
Very basic test with an empty manifest.
2. Test retrieving job manifests through the Koji API. Uses the existing
TestCompose test. The returned manifests are empty for all cases.
Add and implement an API endpoint that returns the manifests for a given
osbuild-koji job. The route returns an array of manifests, one for each
image in the request.
Retrieves the arguments of each Build Job to extract the Manifest.
Wraps jobqueue.JobArgs() method and unmarshals data into the provided
concrete struct value. The struct should match the requested job type of
the given ID.
JobArgs() returns the arguments submitted with a job in raw form.
Since the structure of the args are opaque to job queue, it's the
responsibility of the caller to deserialize the arguments.
Args retrieval is added to the existing TestArgs() function.
With our limited number of machines in OpenStack, we cannot run unlimited jobs
in parallel. When there's a lot of activity in the repository, there's a high
probability that a job must wait for a free VM for quite a long. In these cases,
tests commonly fail due to the timeout.
I decided to prolong the timeout to 12 hours. This should lower the amount of
these kinds of jobs.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add the latest information about the intended use of this type of
image. Also add note about the most common way to consume Red Hat
content using this type of image.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The majority of pull requests do not fix a downstream issue. In
practice, people usually delete the whole suggested content.
Move it into a comment, so that this step is unnecessary.
RHEl 8.4 guest images need to have the default timezone of EST/EDT
unless the user specifies one in their blueprint. New York is a major
location for this timezone.
The directory with image-tests test cases has been renamed from `cases`
to `manifests`. This has not been previously reflected in the test/README.md
and osbuild-image-tests code. osbuild-image-tests hardcodes the test
cases directory path and uses it in case no test case are passed
to it on the command line. Since the image_tests.sh CI test case looks
for image-tests test cases in the correct directory and passes the
relevant ones to osbuild-image-tests, the CI didn't detect this issue.
Running osbuild-images-tests without any argument and let it run all
test cases from the default test cases directory as part of CI probably
does not make sense. Due to this reason, I'm not adding any new test.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
testjobqueue did not implement the JobQueue interface correctly (noted
in its package comment), making it impossible to write tests for
JobQueue itself.
Replace its use everywhere with fsjobqueue operating on a temporary
directory.
When the deploy-qemu script is run with less than 2 arguments, it ended
with error, instead of printing usage. This was due to using 'set -u' and
trying to expand unset variables "$1" and "$2" as part of checking if
they were provided. The issue has been fixed by checking number of
provided arguments, instead of their content. The same approach is used
in 'deploy-openstack' script.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
When rpmmd's Depsolve function is called we need to pass in the image
type's excluded packages. These excluded packages are retrieved when we
get the packages we include from each image type.
Fedora 33 and rawhide got an updated version of the azblob library. Sadly, it
introduced a non-compatible API change. This commit does the same thing as
a67baf5a did for kolo/xmlrpc:
We now have two wrappers around the affected part of the API. Fedora 32 uses
the wrapper around the old API, whereas Fedora 33 and 34 (and RHEL with its
vendored deps) use the wrapper around the new API. The switch is implemented
using go build flags and spec file magic.
See a67baf5a for more thoughts.
Also, there's v0.11.1-0.20201209121048-6df5d9af221d in go.mod, why?
The maintainers of azblob probably tagged a wrong commit with v0.12.0 which
breaks go. The long v0.11.1-.* version is basically the proper v0.12.0 commit.
See https://github.com/Azure/azure-storage-blob-go/issues/236 for more
information.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
This changes the following:
- Only produce one container. There is no particular benefit to
supporting several different base containers, so unify on ubi
as that is what we need ourselves.
- Build directly from git. Now that the RPM we include in our
container does not have any dependencies and only contains a
couple of executables, the indirection via RPM has less value.
Eventually the value will be reduced even further as we merge
the entrypoint into the main binary and move dnf-json into the
worker, leaving us with only a go binary. The only potential
benefit might be that the build environment of RPMs is more
clearly defined, but there is no real reason to believe that
our mockbuild is any better than using the UBI golang build
container.
This simplifies the container builds, and brings us more in line
with what is done in image-builder, and what is needed to deploy
to openshift.
We do not yet build all our packages for aarch64, so this would
fall back on the RPMs in the repository. In `main` that seems to
work, as osbuild-composer exists in the base repositoires. Though
we obviously want to test the most recent commit, not the released
RPM, so this is maksing the problem.
As of this PR, the build would fail though: We are now build
UBI containers, where osbuild-composer does not exist, and we have
split the RPM into the new osbuild-composer-core, which does not
yet exist in any base repository.
This no longer pulls in systemd/worker, saving space and makes it
suitable for use in a UBI container, where qemu-img is not available.
This drops support for --inbuilt-worker from entrypoint.py. The script
could be simplified further in a future commit, or folded into the
main binary.
koji and ansible are not in RHEL repositories. Depending on them breaks RHEL
gating (see OSCI-1541): It tries to build a custom image with -tests package
in it but in the build environment there's no EPEL.
This commit makes the RPM independent from EPEL. However, we still need koji
and ansible, so the provision script now enables EPEL and installs the packages
from there. This is not nice but we have to live with that until OSCI-1541 is
solved.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
koji-osbuild-tests depends on koji which is not available in RHEL. As we need
to get rid of EPEL from deploy.sh (see the following commit), we need a
mechanism to preinstall EPEL before koji-osbuild-tests is installed. This
commit introduces pre_install_packages to Schutzfile - a simple way to
install packages before ${PROJECT}-tests is installed.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
