The builder plugin could produce a traceback when image build failed,
but it didn't contain any details.
```
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/koji/daemon.py", line 1468, in runTask
response = (handler.run(),)
File "/usr/lib/python3.6/site-packages/koji/tasks.py", line 335, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python3.6/site-packages/koji/util.py", line 271, in call_with_argcheck
return func(*args, **kwargs)
File "/usr/lib/koji-builder-plugins/osbuild.py", line 719, in handler
status = client.wait_for_compose(cid, callback=self.on_status_update)
File "/usr/lib/koji-builder-plugins/osbuild.py", line 483, in wait_for_compose
status = self.compose_status(compose_id)
File "/usr/lib/koji-builder-plugins/osbuild.py", line 454, in compose_status
return ComposeStatus.from_dict(res.json())
File "/usr/lib/koji-builder-plugins/osbuild.py", line 251, in from_dict
ImageStatus.from_dict(s) for s in data["image_statuses"]
File "/usr/lib/koji-builder-plugins/osbuild.py", line 251, in <listcomp>
ImageStatus.from_dict(s) for s in data["image_statuses"]
File "/usr/lib/koji-builder-plugins/osbuild.py", line 228, in from_dict
error = ComposeStatusError(error_id=error_id, **error)
TypeError: __init__() missing 1 required positional argument: 'details'
```
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Each 'Task id' corresponds to a 'Compose id' in case everything works as
expected. In order to be able to track both in Splunk to measure our
first service level indicator (SLI) we need to explicitly log the 'Task
id' when it is received by the plugin.
The upload options are expected to be provided as a JSON file. The same
options will be used for all image type and architecture combinations,
similarly as it is done for ostree options.
Extend unit tests to cover the newly added functionality.
While it is technically possible to build more than one image type
as part of a Koji compose in osbuild-composer, this option is not used
in reality and it also makes very little sense. If the user wants to
build more than one image type, they should submit multiple Koji builds.
Adjust affected unit tests.
Previously, the image status in the compose status uploaded to the koji
build was represented as a single string describing the overall status.
All information related to the image upload or error details were
thrown away.
Refactor `ImageStatus` to contain all the information about the image,
its upload targets and potential errors, as they are returned by
composer.
This will improve the experience when debugging compose failures. In
addition, including all the data will be important once images
will be uploaded directly to the cloud, because it will contain
information to locate the image in the cloud environment.
The status calls are sometimes failing on:
upstream connect error or disconnect/reset before headers. reset reason:
connection termination
Since all requests are going through the company proxy, I think that the
networking isn't working 100% reliably. This commit adds a retry mechanism
provided by the urllib3 library. It will retry on all networking issues and
also on some 5xx errors that makes sense to retry (like gateway failures).
A test is added that runs the compose waiting code against a mock server
that fails every second request. This is imho sufficient to mimick a flaky
networking.
The Cloud API supports passing in a variety of image customizations,
like e.g. extra packages or pre-defining users.
Add a new command line option to the client `--customizations` which
takes a path to a JSON file which contains the customziations; they
will be passed via the existing `opts` argument to the hub.
Add support for `customizations` to the `opts`/`options` arguments
to the hub plugin. No validation to the object is done. Instead we
rely in Composer for the validation of the content.
Add support for `customizations` the image `ComposeRequest` in the
builder plugin. All specified values are just passed through to
composer as-is.
Add tests for the respective plugins.
We need koji-osbuild-builder to be able to connect to composer via a proxy
because koji builders in our internal deployment cannot reach
api.openshift.com directly. This commit adds a new option `proxy` to the
builder plugin config that controls whether a proxy is used to route all
requests to composer.
We decided to do this late change to Cloud API in order to keep the field name
same for all the APIs:
https://github.com/osbuild/osbuild-composer/pull/2479
I strongly believe that gpgkeys are not used in any of the current koji-osbuild
deployments yet so this change should be safe.
Use the `self.secret` and not `self.id` for the secret. Doh. Mea culpa.
Fix the corresponding test as well, which also checked for the wrong
thing.
Reported-By: Ondřej Budai <ondrej@budai.cz>
This adds support for specifing the package sets for repositories;
on the command line this can be done via `--repo-package-set` with
and argument of `;` separated package set names. This will result
in repo information being transported via dict instead of plain
strings. Thus the hub plugin's schema was modified accordingly.
Last but not least, the builder plugin now can decode these dicts
and setup the repos accordingly.
Test were added for plugins as well as the integration test changed
to use this new feature.
The first upstream commit that supports this feature is pinned.
It similar to BuildTask - so it doesn't do much on the builder and
doesn't use a lot of resources. It makes sense to have much lower weight
for this type of task.
OStree compose requests need special options, like the `ref` the
`parent` and the `url`. Add support for those options to all three
plugins:
The command line plugin now takes `--ostree-{parent,ref,url}`
and passes it to koji via the existing options dictionary.
The JSON schemata in the hub plugin was adjusted to allow these
new options.
Finally the builder plugin will look for the new `ostree` dict
inside the options, create an `OSTreeOptions` object from it,
and attach it to each image request.
NB: since the ostree options are per image request and are thus
architecture dependent we support a "$arch" substition in the
`parent` and `ref` options that will be resolved by the plugin;
this allows to builds arch specific commits for with a single
compose request.
Add the respective unit tests.
Map the image types used by the koji API to the image types used
by the cloud api. This should allow for a smooth transition when
the plugin is upgraded, i.e. the pungi configuration can be used
unmodified. After all the plugins are upgraded the pungi config
should be changed to use the native image types and then this
mapping could be removed again.
Composer now[1] has integrated the koji API into the "cloud API"
and thus we can use this more general purpose and powerful API
instead of using the specialized koji API endpoint.
Adapt the request and response structures as well as the unit
tests to use that.
[1] PR #2214, commit 11e2ae45284bfb0d89ef1c1e0d2aa4ae230ea573
Implement support for authentication via OAuth2 using the client
credentials "Client Credentials Grant" flow (4.4 of RFC 6749).
For this a new configuration section is added to the config file,
where the client_id, client_secret and token_url have to be
specified.
The impelmention does currently not support "refresh tokens", but
does support refreshing the token if an `expires_in` is present
in the token itself.
Corresponding unit tests have been added.
[1] https://datatracker.ietf.org/doc/html/rfc6749#section-4.4
When the builder is used as an command line binary: have `repo`
be a proper command line argument. It was currently specified
before arch which can be passed multiple times, but so does
repo; hence one of them needs to be optional.
Add support for fetching manifests via the compose/<id>/manifests
API endpoint. A failure to fetch them is not critical, since it is
possible the manifests don't exist, e.g. when depsolving fails.
The manifest is attached per image request.
De-serialize the koji init and import logs, required fields in the
ComposeLogs, and if non-empty, attach them to the task.
Update the tests to check for the presence of these logs.
Instead of getting the `koji_build_id` from the direct reply of
the compose request call, use the one returned in the compose
status.
The reason behind this is that composer was changed so that the
CGInitBuild call to koji is now being done by a worker and not
composer itself. This means that once the compose request call
returns, the build id is not yet known. In composer release 24,
the compose request call internally waits for the worker that
does the CGInitBuild API call, but that will be changed, and
the koji_build_id will then not be returned from the compose
request API call anymore. This prepares for that. The tests are
also adapted to simulate the new behavior.
NB: this makes composer 24 a dependency, since the build id is
taken from the ComposeStatus, which was only added there.
Add a new command line option `--skip-tag` that will skip tagging
after a successful build. The help text is copied from the same
option of other sub-commands in the koji client. The hub plugin's
jsonschema was updated accordingly, and the builder plugin will
skip the tag if the option was requested.
Tests were added or augmented for all three plugins to test the
new option.
Instead of just uploading the compose-status.json at the very end
of the build, keep updating it every time it is fetch. This makes
it easier to follow along, especially if there are multiple image
request being built.
Upload the final compose status as JSON, so it can be inspected,
which could be especially handy if multiple image requests were
made and only one of them failed, to quickly pin down the one
that failed, without having to go through all the logs.
Add a '.as_dict()' method to ComposeStatus, which can be used to
serialize the object as JSON or properly log it. Indeed use it
in the debug log to avoid a useless message that contains:
<_koji_plugin__osbuild.ComposeStatus object at 0x7fb80172b820>
Use the new log API introduced in osbuild-composer >= 24, to fetch
the logs for the compose and attach them to the task. It is a non-
fatal error if fetching the logs fails; in that case a warning is
emitted. NB: logs are attached no matter the compose result.
Logs are per image-request, the content is JSON, but otherwise not
further specified.
Preserve the order of architectures in the image requests inside
the compose requests, i.e. don't transform 'arches' into a set,
which has random order. It is not that anyone should really
depend on it, but there is also no need to mess with the order,
potentially making it harder for humans to match requested arches
with compose request content and logs.
The builder plugin checks that all of the requested architectures
are indeed supported, which is determined via the build tag. It
does that by constructing two sets, the requested architectures
and the supported architectures, and then constructing the set
of (asymmetric) differences between the one and the other. This
difference was meant to be "requested" - "supported", which then
will contain architectures that have been requested but are not
supported, or be empty in case all requested architectures are
indeed supported (the good case). However, previously the diff
was done the other way around ("supported" - "requested"), which
will then return a set of architectures that are supported but
were not requested, which is not what we want to check for.
Invert that the argument of the difference to indeed end up with
"requested" - "supported", which results in the correct check.
Upstream composer has introduce a few changes that we need to
adapt for:
- the koji composer API is now exposed on the standard https
port (443). Thus koji hub and web need to move to a different
pair: 8080 (http) and 4343 (https). Change the scripts and
tests for that
- the koji API gained a prefix 'api/composer-koji/v1/'. Change
client and unit tests to use that prefix. Use urljoin to
create new APIs
- composer configuration format (osbuild-composer.toml) has
changed and now also includes configuration for the CA
and allowed domains
- update the composer RPM repositories to the commit for the
21 upstream release.
When a compose / build was successful, tag it with the destination
tag. This will create a sub-task and wait for it. The individual
parameter are the same used for standard "image" koji tasks.
After creating the compose request object, save it as meta-data of
the task. This should come in especially handy when a compose gets
rejected by osbuild-composer.
Instead of having the individual components for a compose request as
argument, make create_compose just take a ComposeRequest object.
This will pave the way to save the compose request as meta-data for
the task, which can be useful if something goes wrong, e.g. creating
the request.
When returning the result from the task handler function, return
a more complete and structured object in all cases. The name of
the sub-object is named after the service the item belongs to;
specifically composer is used for what belongs to (osbuild)-composer.
