A build pipeline now tracks all its dependents, and each pipeline
now implements a `getBuildPackages()` method. For now those
return the empty slice, but will be extended by each pipeline in the
future.
`getPackageSetChain() of the build pipeline simply collects all the
build package sets of its dependents.
This returns the package set chains for a given manifest. A package
chain is a list of depsolve requests (include, exclude, repos) to be
performed in sequence as if packages were incrementally installed
to the same image. Each pipeline has its own package set chain, and
the manifest returns a mapping from pipeline name to their
respective chain.
So far this is not used, and always returns the empty chains.
The intention is to eventually make each pipeline (and hence
manifest) self-describing, so they can return exactly the depsolve
requests needed to serialise them, rather than relying on that
information being maintained externally.
Name it `getPackageSpecs()` instead so we can introduce a new
function `getPackages()` that is about package names rather than
full specs, in a follow-up commit.
Panic in case two pipelines with the same name are added to the
manifest. In the future we should deal with allocating fresh names,
but that is not yet needed.
Make it the responsibility of each pipeline to track its required
sources, and use this to generate a manifest from its pipelines.
This removes the dependency on osbuild2 from distro.go, and the
only other uses of osbuild2 are to specify parameters in
ImageConfig, which will eventually go away too.
As a consequence, this only attaches the required sources for a
given manifest, rather than all known packages in the package set
map.
Add a plain `rhel-8` alias as the default distribution name and version
for the `rhel8` package. The `rhel-86` distro is still available via
the NewRHEL86() constructor. These two distributions are identical.
Repositories
------------
The rhel-8 repositories (repositories/rhel-8.json) are now set to the
CDN repositories with no minor version:
https://cdn.redhat.com/content/dist/rhel8/8/...
The rhel-8 test repositories (test/data/repositories/rhel-8.json) were
already set to the plain `8` repositories. The Google repos have been
added.
The test case generator repositories used for `rhel-8` are the rpmrepo
snapshots as for rhel-86.
With 8.3 support dropped, the rhel86 package defines all the supported
RHEL 8 versions except 8.4.
RHEL 8.4 will be merged into the rhel8 package soon.
The rhel8 package represented RHEL 8.3, which is EOL.
The current rhel86 package will be renamed to rhel8 and be responsible
for building all RHEL 8 minor versions.
Drop the fallback to the `assembler` export if no is specified in the
job and return Job Error in this case.
Remove the constraint to support only a single osbuild export. The job
is now able to use multiple osbuild exports and each target may use a
different one.
The osbuild export is specific to the upload target and different
targets may require using a different export. While osbuild-composer
still does not support multiple exports for osbuild jobs, this prepares
the ground for such support in the future.
The backward compatibility with older implementations of the composer
and workers is kept on the JSON (Un)mashaling level, where the JSON
message is always a super-set of the old and new way of providing the
exports to osbuild job.
Weldr API already does not rely on this code and nothing else uses it.
Since the code has been used only on-premise, where we expect the
composer and workers to be always of the same version, there is no need
to keep backward compatibility in the worker.
Stop relying on the server interpreting the set `ImageName` in the
`OSBuildJob` as a signal to upload the image back to the worker server
and add an explicit "Worker Server" upload target to the job.
The uploading of artifacts back to the worker server for the on-premise
(Weldr) use case was signaled to the worker by setting the `ImageName`
in the `OSBuildJob` definition. The code also relies on the osbuild
exports being specified in the `OSBuildJob`, instead of in the target
(this is not implemented yet).
Prepare the ground for moving osbuild export definition from
`OSBuildJob` to `Target` by introducing an explicit `Worker Server"
upload target. This target will signal to the worker that it should
upload the image back to the worker server. The new target is not yet
used by any API implementation.
Extend the worker osbuild job implementation to handle the new upload
target.
The `TestKojiJobTypeValidation` unit test used the `OSBuildJob` and
Koji Target fields in the wrong way, however without any impact on the
testing itself. The reason is that no actual images were built as part
of the test nor the created jobs were ever picked up by a worker.
This change was forgotten in PR#2758.
[1] https://github.com/osbuild/osbuild-composer/pull/2758
The filename of the image as produced by osbuild for a given export is
currently set in each target options type in the `Filename` struct
member. However, the value is not really specific to any target type,
but to the specific export used for the target. For this reason move the
value form target type options to the `Target` struct inside a new
struct `OsbuildArtifact` under the name`ExportFilename`.
The backward compatibility with older implementations of the composer
and workers is kept on the JSON (Un)mashaling level, where the JSON
object is always a super-set of the old and new way of providing the
export filename in the Target.
The `Filename` previously set in the `gcpUploadSettings` does not
provide any value. It is the filename of the image as produced by
osbuild for a given export. It may not correspond with the object name
when the image is uploaded to GCP storage and may not even correspond
with the image name after it is imported to GCE. Stop setting the value
and remove the variable from data structures.
This change should not have any impact on backward compatibility,
because the field will be ignored when (Un)Marshalling.
Some variable names used in the `OsBuildJob` `Run()` method were not
very self-explanatory, which made the code harder to understand and
navigate. These were `args`, `options`, `t`. Rename them to be more
self-explanatory of their purpose.
Completely remove the use of `local` target from all code, which is not
required to keep backward compatibility. The target has not been used in
composer for some time already, but some unit tests still used its data
structures. Mark the target as deprecated and adjust all unit tests that
depended on it.
The backward compatibility is kept mostly to enable long running
osbuild-composer instances, which were upgraded to still read old jobs
from the store.
While a target with the same intention will be reintroduced, the current
`local` target data structures contain many fields which would not be
relevant for the new target.
In addition, while the "local" target will be ever used only by Weldr
API, the name would be a bit misleading. Although the worker usually
runs on the same system when using Weldr API, there is no hard
requirement enforcing this setup. In reality, the worker will be
uploading the image back to the worker server, so there is room for a
better name.
A backward compatibility code handling the conversion of VMDK image to
stream-optimized sub-format has been kept in the implementation since
PR#2529 [1] merged on May 4th 2022. Since this change, no API
implementation is submitting jobs, which would hit this conversion code,
because VMDK images are already being produced in the desired
sub-format.
On-premise deployments are expected to use the same composer and worker
versions. There are no composer / worker instances in production, which
are not running the modified code.
Delete the backward compatibility code.
[1] https://github.com/osbuild/osbuild-composer/pull/2529
Modify the `OsBuildJob` implementation to handle multiple upload targets
in a cycle. However, there is still no API implementation, which would be
adding `OsBuildJobs` with multiple targets to the job queue.
The limitations are that only a single osbuild export is supported, and
the same artifact will be used for each target.
At the end of the job, errors from all targets are gathered. In case
there are none, the job succeeds. In case at least one target failed,
the job fails as well. In such a case, a slice of errors from all failed
targets is added to the job error as details.
Add a new worker client error type `ErrorTargetError` representing that
at least one of job targets failed. The actual target errors are added
to the job detail.
Add a new `OSBuildJobResult.TargetErrors()` method for gathering a slice
of target errors contained within an `OSBuildJobResult` instance. Cover
the method with unit test.
Ensure that a target result with a proper error is added to the Job
result, in case the there was any error encountered. This error is not
used at all for now. Keep setting the `JobError` to the same error set
in the target result for now.
This is a step towards job results containing multiple target results
with each or them having potentially an error set as well.
Do not pass the `worker.OSBuildJobResult` to `uploadToS3()`, but instead
return target errors from the function. This will make the error
handling of all upload targets consistent and easier to modify to
support multiple targets.
Ensure that `UnmarshalTargetResultOptions()` is called only when there
are any options to unmarshal in the JSON object.
Since results of some Targets don't have any options defined, mark
`TargetResult.Options` as optional in the JSON tag.
This will enable reporting of target-specific errors from jobs, once
they'll support multiple targets.
Target errors are currently reported via `JobResult.JobError`.
The `TargetErrors` is not used any more since PR#2192 [1] and there is
no need to keep the backward compatibility any more, because there are
no composer / worker instances in production, which are not running the
modified code.
In addition, delete unit tests covering this legacy error handling.
[1] https://github.com/osbuild/osbuild-composer/pull/2192
This was a stop-gap until the actual rhel 9 distro was created. It
is in a sad state, quite broken and shout not be used by anybody.
Put it out of its misery.
Define the distribution strings for RHEL 8.5 in distro/rhel86 and add
constructors. Remove the old 8.5 from the distro registry and use the
new constructors.
Composer can now build RHEL 8.5 image-installer on aarch64, which wasn't
supported before.
RHEL 8.5 manifests have changed to minimise the differences from 8.6.
Some changes are fixes made in 8.6 but never backported to 8.5 because
of our (older) policy of not changing definitions after the release of a
distro.
Other changes are non-functional (e.g., stage or package order).
See the list below for the source of each change.
Manifest changes:
- Stage order changed for org.osbuild.systemd-logind and
org.osbuild.rhsm.
- org.osbuild.grub2 options: config.default = "saved"
Reverted 111cd8871f
- Partition sizes: RHEL 8.5 had extra arbitrarily sized padding for the
header. Now all partitions are sized to fit headers exactly.
Original change at b7abef54e8.
- SELinux set to permissive in Anaconda. This was changed in RHEL 8.6
and 9.0 but never backported to 8.5.
See a7fbe916b7.
- Installer isolevel set to 3. Like above, this was changed in
8.6 and 9.0.
Original change at d8d161480e.
- Specify a remote for edge deployments.
Original change at b18b4e80a0.
Added utility function for comparing RHEL version strings.
Conditions added:
- greenboot subpackages were changed between RHEL 8.5 and RHEL 8.6.
- fido client packages aren't available in RHEL prior to 8.6.
- the ec2 SAP image type is not supported in RHEL prior to 8.6.
- the edge-simplified-installer and edge-raw-image image types are not
supported in RHEL prior to 8.6.
- They were previously supported in 8.5 without FDO support, but now
it's dropped from 8.5 completely.
