d7e59e6eec
Previously, the worker was determining the GCE image guest OS Features on its own, based on the OS name. This caused problems, in case the osbuild-composer was of a newer version than the worker. Example: osbuild-composer contained support for c10s GCE image type and its implementation also contained the proper guest OS Features list for it. However, when the worker got the osbuild job, it built it and tried to fetch the guest OS Features for the distro. Since its implementation was too old, it didn't contain the code that added the actual support for c10s GCE images and got no guest OS features list (which is the default for unsupported distros). The image was successfully uploaded and shared, but it does not boot in GCP, because it does not know that it should use UEFI to boot it. This behavior could be considered a bug. The worker should be dumb. It should not be making decisions about the image features, but instead it should take them from the upload target options. And composer should be the authoritative source of truth for this. Because otherwise, we basically have two components that need to be updated in sync to add support for GCE images on a new distro. Move the GCE image guest OS features to the GCP upload target options. The worker will just take what is specified there and use it when importing the image to GCP. As a compatibility layer for the case when the composer would be older than the worker (unlikely, but still), worker will try to determine the image guest OS features in case the list in the upload target options is empty. Extend the GCP functional tests to check that the imported image has at least some guest OS features set. Signed-off-by: Tomáš Hozza <thozza@redhat.com> |
||
|---|---|---|
| .devcontainer | ||
| .fmf | ||
| .github | ||
| cmd | ||
| containers | ||
| distribution | ||
| docs | ||
| image-types | ||
| internal | ||
| pkg | ||
| repositories | ||
| schutzbot | ||
| templates | ||
| test | ||
| tmt | ||
| tools | ||
| vendor | ||
| .env | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitleaks.toml | ||
| .golangci.yml | ||
| .packit.yaml | ||
| .pylintrc | ||
| codecov.yml | ||
| Containerfile_golangci_lint | ||
| CONTRIBUTING.md | ||
| DEPLOYING.md | ||
| docker-compose.yml | ||
| go.mod | ||
| go.sum | ||
| HACKING.md | ||
| krb5.conf | ||
| LICENSE | ||
| Makefile | ||
| osbuild-composer.spec | ||
| README.md | ||
| rpmlint.config | ||
| Schutzfile | ||
OSBuild Composer
Operating System Image Composition Services
The composer project is a set of HTTP services for composing operating system images. It builds on the pipeline execution engine of osbuild and defines its own class of images that it supports building.
Multiple APIs are available to access a composer service. This includes support for the lorax-composer API, and as such can serve as drop-in replacement for lorax-composer.
You can control a composer instance either directly via the provided APIs, or through higher-level user-interfaces from external projects. This, for instance, includes a Cockpit Module or using the composer-cli command-line tool.
Project
- Website: https://www.osbuild.org
- Bug Tracker: https://github.com/osbuild/osbuild-composer/issues
- Matrix: https://matrix.to/#/#image-builder:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org
- Mailing List: image-builder@redhat.com
- Changelog: https://github.com/osbuild/osbuild-composer/releases
Principles
- OSBuild Composer shall only allow users to do what generally makes sense.
- Blueprints are the policy layer where we decide what to expose to end users.
- If a blueprint can be built, it should also boot.
- It should be obvious why a blueprint doesn’t build.
- The cloud API is never broken.
- In the hosted service, OSBuild Composer is an orchestrator of image builds.
- On-premises, it should be as easy as possible to run the service and build an image.
- OSBuild Composer needs to run on the oldest supported target distribution.
Contributing
Please refer to the developer guide to learn about our workflow, code style and more.
About
Composer is a middleman between the workhorses from osbuild and the user-interfaces like cockpit-composer, composer-cli, or others. It defines a set of high-level image compositions that it supports building. Builds of these compositions can be requested via the different APIs of Composer, which will then translate the requests into pipeline-descriptions for osbuild. The pipeline output is then either provided back to the user, or uploaded to a user specified target.
The following image visualizes the overall architecture of the OSBuild infrastructure and the place that Composer takes:
Consult the osbuild-composer(7) man-page for an introduction into composer,
information on running your own composer instance, as well as details on the
provided infrastructure and services.
Requirements
The requirements for this project are:
osbuild >= 26systemd >= 244
At build-time, the following software is required:
go >= 1.21python-docutils >= 0.13krb5-develfor fedora/rhel orlibkrb5-devfor debian/ubuntu`btrfs-progs-develfor fedora/rhel orlibbtrfs-devfor debian/ubuntudevice-mapper-develfor fedora/rhel orlibdevmapper-devfor debian/ubuntugpgme-develfor fedora/rhel orlibgpgme-devfor debian/ubunturpmdevtools(only formake push-check)rpmlint(only formake push-check)
Build
The standard go package system is used. Consult upstream documentation for detailed help. In most situations the following commands are sufficient to build and install from source:
make build
The man-pages require python-docutils and can be built via:
make man
Run Tests
To run our tests locally just call
make unit-tests
Before pushing something for a pull request you should run this check to avoid problems with required github actions
make push-check
Repository:
- web: https://github.com/osbuild/osbuild-composer
- https:
https://github.com/osbuild/osbuild-composer.git - ssh:
git@github.com:osbuild/osbuild-composer.git
Pull request gating
Each pull request against osbuild-composer starts a series of automated
tests. Tests run via GitHub Actions and Jenkins. Each push to the pull request
will launch theses tests automatically.
Jenkins only tests pull requests from members of the osbuild organization in
GitHub. A member of the osbuild organization must say ok to test in a pull
request comment to approve testing. Anyone can ask for testing to run by
saying the bot's favorite word, schutzbot, in a pull request comment.
Testing will begin shortly after the comment is posted.
Test results in Jenkins are available by clicking the Details link on the right side of the Schutzbot check in the pull request page.
License:
- Apache-2.0
- See LICENSE file for details.