The type of the minsize parameter in the new disk customization was
meant to support both integers (size in bytes) and strings (size with
unit). However, the schema wasn't done properly, which made any input
result in an error:
GenericError: Failed to create the compose request:
{"code":"IMAGE-BUILDER-COMPOSER-30","details":"request body has an
error: doesn't match schema #/components/schemas/ComposeRequest:
Error at \"/customizations/disk/partitions/0\": doesn't match schema
due to: Error at \"/minsize\": input matches more than one oneOf
schemas
Reducing it to just support strings simplifies the schema. It's also
not an important feature reduction since sizes as integers (for
filesystems that are typically in GiB) aren't very convenient.
Expose the ${SUBJ} customization in Cloud API. Weldr API inherited it
automatically with the update of `osbuild/blueprint` to v1.6.0.
Adjust relevant test cases and unit tests to use this new customization.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Define a reusable minsize property in the cloud API schema.
The minsize type is either a uint64 or a string with data units.
Internally, this creates a union (json.RawMessage) type called Minsize
and optional uses of the property are of type *Minsize. We define an
internal decodeMinsize() function to convert *Minsize to uint64. This
is similar to the decodeSize() function in the blueprint, but made
specifically to handle *Minsize.
Fixed distribution list type, function signatures (later versions parse
uuids in the generated code), defaults actually being set and added
x-go-type where needed.
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
