Because of the way json encoding works in golang we haven't run into any
issues. But if we add automated validation based on the spec it will
break, the image-builder-crc client for instance doesn't specify these
fields.
Remove commented out lines and some comments, kept only as a reference
when we moved away from using the `@core` group.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Don't use the `@core` package group in image definitions, because it is
not intended as the minimal package set for virtual / cloud images. In
addition, its content is changing without us knowing, which has
consequences such as the recent discovery of the fact that TuneD is no
longer installed by default on RHEL images, while it definitely should be.
Replace the `@core` package group with the `coreOsCommonPackageSet`
package set. The content of it is based on the latest `@core` group
definition with a few modifications, so that image package sets
never end up having the same package listed in the `Include` and `Exclude`
package set at the same time. All additions have been accompanied with a
comment and all removals have been kept commented out with a comment.
The fact that the change does not have any effect on image package sets
was verified by regenerating all RHEL-9.0 image test cases. There is
however one change in the VMDK image. Specifically the
`python3-libselinux` package have been added. The reason is that the
latest `@core` group definition was used when defining the content of
`coreOsCommonPackageSet`, however the `@core` group definition in the
RPMRepo snapshot used for the image test case didn't include the package
yet.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Listing a single package per line in the package set definitions makes
it much more easier to review diffs in code changes and spot potential
issues.
Align EC2 package set functions to use the structure's `.Append()`
method as it is used by all the other package set functions.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The `@core` package group used to include TuneD package by default on
RHEL-8. It has been removed from the group in Fedora as part of [1] and
inherited into RHEL-9. As a result, TuneD is no longer installed by
default on RHEL images.
After a discussion on rhel-devel there seems to be an agreement, that
TuneD should be installed by default on all RHEL virtual images. At
least we should keep the consistency in this regard with RHEL-8.
Regenerate all RHEL-9.0 image test cases.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=2026709
[1] https://pagure.io/fork/adelton/fedora-comps/c/a5d4f1b6c9fcbe20cb0c38eac5048d7d45d1dd17
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Related to: https://github.com/osbuild/osbuild/pull/866/
Introduce new fields and move structure validation into the constructor.
This will fail faster and hopefully provide less space for programming
errors. Another advantage is simplified code with less type aliases and
lines.
We have been actually unmarshalling into a wrong datatype for a year, by
fixing this, we should get much more logging in Brew.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add TuneD package to the base package set for all EC2 image types,
including the `ami` image type. In addition to installing the package,
also enable the service by default. TuneD will by default auto-detect
the environment in which the image is running and set the most
appropriate TuneD profile, with exception of the `ec2-sap` image, which
explicitly sets a specific TuneD profile.
This change affects the `ami`, `ec2`, and `ec2-ha` image types on all
supported architectures.
Regenerate affected image test cases.
Related to RHELPLAN-102615
Fix#1972
Signed-off-by: Tomas Hozza <thozza@redhat.com>
This was added in osbuild: https://github.com/osbuild/osbuild/pull/875
Introduce the same option in composer and make it optional by specifying
it as a pointer to bool value. It would work the same even if it was
there every time, but as it should be an edge case, don't use it
everywhere. Also osbuild doesn't require it to be present, so it seems
like the right thing to do.
The `compat-sap-c++-9` package no longer exists on RHEL-9. It has been
removed from the RHEL-9.0 Beta EC2-SAP image's package set, but then got
readded as part of adding the RHEL-9.0 distro and merging package sets
code with RHEL-8.6.
This issue have been found by the test case which tests manifests from
mage test cases, including the package set depsolving.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The commit adding distro-specific package set to RHEL-8.6 [1] introduced
a bug in the `image-installer` image type due to a typo. The
`insights-client` package have been removed from the
`bareMetalPackageSet` and moved to `distroSpecificPackageSet`. However
the `distroBuildPackageSet` got appended to `bareMetalPackageSet`,
instead of `distroSpecificPackageSet`, which caused `insights-client` to
be removed from the image's package set.
This issue have been found by the test case which tests manifests from
image test cases, including the package set depsolving.
[1] ed0cb5ea24#
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Generated image test case manifests for all supported distros, arches and
image-types are being tested as part of distro unit tests. However due
to time constrains, the unit test does not depsolve the image's default
package sets and thus does not check if they changed in the internal
osbuild-composer's representation, compared to the generated image test
case.
Extend the `TestDistro_Manifest()` function used by the unit test to
allow depsolving image's package sets.
Introduce a new test case binary `osbuild-composer-manifest-tests`
allowing to check the manifests generated by composer for all supported
combinations of images against generated manifests, including depsolving
image's default package sets.
Introduce a new CI test case `manifest_tests.sh` executing the
`osbuild-composer-manifest-tests` binary and testing all existing image
test cases. Run it in CI on RHEL-9 runner.
Modify SPEC file to ship the newly added test case.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The stage now allows for customizations specific to YUM or DNF. So far
it is just an alias to the same definition, meaning that composer can
use exactly the same structures for both.
Ref: https://github.com/osbuild/osbuild/pull/876
Before dereferencing the method receiver in Write(), check if the object
is nil and return early.
Fixes#2002
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
Rework the stage options data validation to be done in constructor
methods, instead of when being marshalled to JSON.
Add validation of values passed to constructor methods for modprobe
command structures.
Add validation of the configuration filename based on stage schema.
Related to issue #1785.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add support for the 'install' modprobe command in the modprobe osbuild
stage implementation.
Extend unit tests to verify marshalling the stage options into JSON.
Related to https://github.com/osbuild/osbuild/pull/867.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Two new tests, one for OSBuild and one for Koji jobs. Both follow the
same flow:
- Enqueue a job that doesn't specify PipelineNames (oldJob)
- Enqueue a job that does specify PipelineNames (newJob)
- Read the job data for the oldJob and check that the default
PipelineNames were added
- Read the job data for the newJob and check that it's unchanged
- Finish oldJob and add results without specifying PipelineNames
- Finish newJob and add results with PipelineNames
- Read the oldJob result and check that the default PipelineNames were
added
- Read the newJob result and check that it's unchanged
This is meant to test several scenarios that can occur when upgrading
the service:
1. The existing jobqueue has old jobs in it that were queued before the
PipelineNames were part of the data structure. The worker should be
able to read these and add the fallback data.
2. New jobs are added while old jobs still exist in the queue and the
worker can read both types.
3. The existing jobqueue has old finished jobs in it that were finished
and had results written before the PipelineNames were part of the
result data structure. The worker should be able to read these and
add the fallback data.
4. New jobs are finished and results are written while old jobs still
exist in the queue and the worker can read both result types.
When worker reading data into the job and result types, check if the
PipelineNames are populated and, if not, add the fallback values from
distro.
This makes it simpler to work with job queues that contain old data
before the introduction of the PipelineNames. In any situation where the
job or result data are read, the reader can assume that the
PipelineNames are non-nil and that if they belong to an old job, they
have the fallback names.
This assumption goes hand-in-hand with the change in v2 format for
osbuild results, since old jobs that don't have PipelineNames set *must*
contain results in the old format for the names to be valid.
Pipeline names are added to each job before adding to the queue. When a
job is finished, the names are copied to the Result object as well. This
is done for both OSBuild and Koji jobs.
The pipeline names in the result are primarily used to separate package
lists into build and payload/image packages in two cases:
1. Koji builds: for reporting the build root and image package lists to
Koji (in Koji finalize).
2. Cloud API (v1 and v2): for reporting the payload packages in the
metadata request.
The pipeline names are also used to print the system log output in the
order in which pipelines are executed. This still isn't used when
printing the OSBuild Result (osbuild2.Result.Write()) and we still rely
on sorting by pipeline name
(see https://github.com/osbuild/osbuild-composer/pull/1330).
The names of the pipelines that make up a Manifest for a job are
attached to the job data that is stored in the queue. The pipelines are
separated into Build and Payload.
This information is useful for identifying the build pipeline results
and metadata and for the order of the pipelines as they appeared in the
manifest.
