When `go install` is called, go tries to get the git commit hash and embed it
into the built binary. Internally, go just calls the git executable.
The newer go-toolset seems to be based on RHEL 9.2 that ships a newer version
of git (2.39.1). This version contains the safe directory patch that
disallows git from operating on repositories owned by different users.
Thus, we need to chown the files when copying.
See
https://git-scm.com/docs/git-config/2.35.2#Documentation/git-config.txt-safedirectory
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Fedora 35 is going EOL on Tue 2022-12-13. At the time of writing this commit
message, that's the next day. As we do releases on Wednesdays, the next
release will never find its way to F35 and thus, there's no point in keeping
support for it.
Let's delete everything that relates to Fedora 35. If there's something that
cannot be deleted (e.g. CI containers based on F35), let's upgrade it to F37.
TestCrossArchDepsolve now uses CentOS Stream 8 because RHEL 8.4 cannot read
F37 repository metadata. This is a similar issue to
https://bugzilla.redhat.com/show_bug.cgi?id=2004853 . Basically, newer
repositories can be only read by libmodulemd >= 2.11.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
The go package `proglottis/gpgme` a dependency of `containers/image/v5`
package uses `libgpgme`. In the near future `internal/container`, which
depends on `containers/image/v5`, will be used directly in composer and
thus we need to install the `gpgme` devel package and its build deps.
Additional packages are required to build the
docker worker. This fix updates the builder
container to install the required libraries
and then create the worker binary.
entrypoint.py
-------------
Allow the user to set the port number also for the remote worker
Allow the user to set the binding address for the composer api or remote worker api
Set the default port of the composer API to 8080
Dockerfile-ubi
--------------
Remove setting the port for the composer API since the default is
already 8080
Integrate the dev container into docker compose with the aim
of making test-case generation work as well as composer-cli.
This also makes docker-compose self contained, and no setup or configuration is required beyond running `docker compose up --build`.
The service is started via systemd activation sockets.
The service serves http POST requests, the same json as before is
expected as the body of the request, and the same json as before is sent
as the response of the request.
Since the depsolving has been moved to the worker,
the Dockerfile for the worker needed to have the
dnf-json executable. Additionally there was a missing
cache directory.
The main changes are:
- Kind, Href, Id fields for every object returned
- Attach operationIds to each request, return it for errors
- Errors are predefined and queryable
There is no need for osbuild-composer to wait until the whole multi-user
target is completed. It can be started earlier as it doesn't have any
dependencies in the target.
This can be a problem if there is a unit in the target that is not starting
and still is unrelated to osbuild-composer. There was a bug like this
with Plymouth where the service didn't finish and it was hanging. That
prevented osbuild-composer from starting and the user was left with
working SSH connection and shell, but composer-cli and systemctl start
osbuild-composer.service were both unresponsive.
Replace After=multi-user.target with After=network.target to start
osbuild-composer earlier.
The base url for the osbuild-worker container was
missing the `https` protocol in the docker-compose file.
This commit adds this to prevent the worker from exiting
Because the state directory, which is still currently used, only allows
for a single pod to mount it, allow for 0 available pods when updating
the deployment. Otherwise it will block updating until the state
directory is available for mounting, which will be never.
Container configuration directory can be set in the .env file which is
automatically used by docker-compose. The default value is the one used
previously (containers/config).
The HACKING.md guide is updated to describe how to set this and how it
affects other commands.
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.
It should be totally possible to run osbuild-composer without the Weldr API
and local worker socket. This commit accomplishes this task!
In cloud environments where we don't want the Weldr API, it's now totally
possible to run osbuild-composer without it. If you also want to get rid of
the local worker, this command still works:
systemctl mask osbuild-worker@1.service
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Everybody hates the local workers. The first step of getting rid of them
is to split their socket out of osbuild-composer.socket - we need to keep
this one to support the Weldr API but the local worker socket can live in
its own file.
The behaviour should be the same for now: osbuild-composer.service always
starts the local worker socket.
However, this split allows the osbuild-composer executable to be run without
the Weldr API activated. The following commit explores this option more
in depth.
Note that the new socket can be used by root only because workers are always
run as root.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Remove both the package osbuild-composer-koji, and the only file it
shipped: osbuild-composer-koji.socket.
It's been deprecated since 835b556, but the backwards-compatible
solution in that commit never worked, because osbuild-composer only
checks for "osbuild-composer-api.socket" when starting up.
Since this has been meant to be deprecated for a while, just remove it
outright.
Add an "Obsoletes:" for the package, so that it gets uninstalled on
existing systems.
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.
Rather than using the arbitrary port 8701, use the standard 443. The
worker API will remain on a separate port, and as long as the two APIs
are exposed by the same binary that will have to remain separate at
8700.
Move the test instance of koji on localhost from 443 to 4343, to avoid a
conflict.
In a follow-up we should also give this API a prefix, so the cloud API
can share the same port with it.
Signed-off-by: Tom Gundersen <teg@jklm.no>
