This will allow clients to display more information about a compose,
including the image type created, arch and distro, and blueprint to
customizations used to create it.
Related: RHEL-60120
This will download the build artifact from a locally saved osbuild
compose. It will set the filename to the the UUID of the build with the
artifact filename appended. eg. 1dbcc86e-745b-4061-812f-e50f06fa7cbe-disk.qcow2
Related: RHEL-60142
This adds support for listing all of the supported distributions,
their arches, the image types, and their repository details.
This returns 3 nested json objects. The keys for the first layer are the
distribution names. The 2nd layer's keys are the architectures supported
by that distribution, and the 3rd layer's keys are the image types
supported by that distribution:architecture pair. The value of the 3rd
layer is the repository information.
Resolves: RHEL-60133
The request is similar to a depsolve request, it must include the
distribution and architecture. It can optionally include a list of
repositories to search, but if they are not included it searches the
default repos for the distro:arch
Related: RHEL-60136
In order to reuse PackageMetadata with DepsolveResponse and not include
unused fields this changes the sigmd5 entry to an optional field. This
doesn't effect the use of PackageMetadata in the Compose response since
it is always set, and it allows it to be omitted in the response for
depsolving.
Also adds a basic test for stagesToPackageMetadata
Related: RHEL-60125
Add a new /sboms API endpoint, for getting SBOM documents for a given
compose ID. The endpoint returns an array of SBOM documents for each
image built as part of the compose. For each image, there is an SBOM
document for each osbuild pipeline, which installs RPM packages. This is
usually one 'buildroot' and one 'image' pipeline.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Also adds the policy id to the blueprint, this doesn't have any effect
on the openscap step, it just puts in place the rhsm fact so instances
registered to insights will appear under that policy.
Add support for RHSM customizations, which currently allow various
aspects of RHSM. Specifically enabling / disabling DNF plugins shipped
by subscription-manager package and setting a subset of options in the
rhsm.conf.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for RPM customizations, which currently allow to import RPM
GPG key from a file installed in the image. This is e.g. done for the
Azure RHUI image type.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Add support for json tailoring files in the cloudapi. Expand the tests
to check that the options returned are okay and that tailoring options
and json tailoring options can't be provided at the same time.
This allows the compose status to reflect that it was saved locally, not
uploaded to a remote service. Without this it returns an error of
'Compose has unknown upload target'
This adds a 'blueprint' section to the compose request. It also
restricts it so that only 'blueprint' or 'customizations' can be
included, but not both. The goal is to move to using 'blueprint' for all
customizations so that there is a single consistent interface for the
clients.
Where the openapi schemas are the same between the two they have been
shared, but a few are different. They are created with 'Blueprint*' as
their name.
This also re-adds the SSHKey schema removed by commit
bfad6d50e1, it is used by the Blueprint
Customization.
Allow passing module_hotfixes flag through the cloudapi.
This will enable depsolving on repositories that might be affected by modularity filtering.
Refs HMS-3202
Adds implementation of the 'fdo.di_mfg_string_type_mac_iface' dracut
variable to allow simplified installer images to pass this value to the
manufacturing-client.service.
Fix verbiage of groups customization, fields which accept an array
should be plural.
Remove the sshkey customization, sshkeys are merged into user
customizations anyway, so users should use the "users" customization
instead.
Since these customizations aren't in use yet, this edit should be fine.
See #3716
Add an upload_targets field to the image request. This lets the API
caller specify multiple upload targets and upload options to be used.
If the upload target type does not match the upload options, the request
is invalid.
For backwards compatibility, the upload targets field is optional. If
it is not specified, the default upload target and upload options for
the image type are assumed, which is the same as the old behaviour.
Adding an explicit selection to the request makes it possible to support
multiple upload targets for the same image type. We plan to support
ostree commits being uploaded to both aws.s3 and pulp.
To report on the multiple upload requests, we add an upload_statuses
field to the ImageStatus response.
Add support to the cloudapi for generating the tailoring file used
to customize the OpenSCAP remediation. This allows users to select and
unselect rules for the remediation and the `autotailor` stage generates
the tailoring file.
During development it can be very useful to store the results locally
instead of uploading to a remote system. This implements a development
only option to help with that.
To use it you need to add OSBUILD_LOCALSAVE to the server's environment.
This can be done by editing /usr/lib/systemd/system/osbuild-composer.service
and adding:
Environment="OSBUILD_LOCALSAVE=1"
You can then use an 'upload_options' object to skip trying to upload to
the default service for the type of image, eg:
"image_requests": [
{
"architecture": "x86_64",
"image_type": "guest-image",
"upload_options": {
"local_save": true
},
...
}]
The results will be saved to /var/lib/osbuild-composer/artifacts/UUID/
using the default filename for the image type.
If local_save is used without OSBUILD_LOCALSAVE being set it will return
an error with id=36 saying 'local_save is not enabled'.
This adds a 'size' parameter to the image_request object. It can be used
to specify the minimum image size in bytes
This behaves in the same way as the size parameter of the weldr API
For raw images the root partition is grown to fill the available space.
For LVM images the PV uses the available space, but the LV does not,
leaving space available for other LVs to be created after boot.
See COMPOSER-1883
This image type produces the same artifact as the current workstation
installer live media.
During the implementation of this new installer some names have been
changed to make a bit more sense in the source tree. Installer images
now always mention which installer they are (anaconda, etc).
Expose the Directory and File customizations in the Cloud API. Also
validate the provided customizations while processing the compose
request by trying to convert them to internal representations
`fsnode.File` and `fsnode.Directory`.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
