No description
4c40faebe6
Conceptually, we used to insert the high-level packages and package groups into the pipeline together with the expected repository metadata checksum. osbuild, using the dnf stage, would then fetch the metadata, verify that its checksum is correct, compute the dependencies, and install the packages. Among the problems this has is that it made it impossible to cache and share the resolved metadata as well as the rpms. Moreover, as the checksum was at the repository-level, rather than at the package level, it meant that we would refuse to build a pipeline as soon as there were any changes at all to the repository, as we could no longer guarantee the installed packages would be the same. As of this patch, all repository and metadata handling is done by composer, rather than osbuild. This means that the resolved metadata can be cached between runs, which and it means that we can now pin individual packages, rather than the entire repository. Meaning, that as long as the rpms are still available, we are able to build a pipeline. The downloading of rpms is now done by a source helper in osbuild, which means that they can be cached and shared between runs too. One consequence of this change is that we resolve the location of each rpm in composer, and pass that to the worker. As the worker may not be in the same location, we do not want to use metalinks in composer for this, as it would pin the repository closest to composer, rather than the runner. Instead, we now manually select a baseurl for each repository, which should be generally the most useful one. Fedora helpfully provides such baseurls, so this should work ok. The most important thing to verify when checking this commit, is that the image info in our test-cases remains unchanged. Signed-off-by: Tom Gundersen <teg@jklm.no> |
||
|---|---|---|
| .github/workflows | ||
| cmd | ||
| distribution | ||
| docs | ||
| internal | ||
| osbuild@c8465ce06f | ||
| repositories | ||
| test | ||
| tools | ||
| vendor | ||
| .gitignore | ||
| .gitmodules | ||
| .golangci.yml | ||
| .packit.yaml | ||
| .travis.yml | ||
| dnf-json | ||
| go.mod | ||
| go.sum | ||
| golang-github-osbuild-composer.spec | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
osbuild-composer
An HTTP service for building bootable OS images. It provides the same API as lorax-composer but in the background it uses osbuild to create the images.
You can control it in Cockpit or using the composer-cli. To get started on Fedora, run:
# dnf install cockpit-composer golang-github-osbuild-composer composer-cli
# systemctl enable --now cockpit.socket
# systemctl enable --now osbuild-composer.socket
Now you can access the service using composer-cli, for example:
composer-cli status show
or using a browser: http://localhost:9090
API documentation
Please refer to the lorax-composer's documenation as osbuild-composer is a drop-in replacement.
High-level overview
Frontends
osbuild-composer is meant to be used with 2 different front-ends. The primary one, which is meant for general use, is cockpit-composer. It is part of the Cockpit project and unless you have a strong reason not to use it, you should use it. composer-cli is a command line tool that can be used with osbuild-composer.
Compose
- Compose is what the user submits over one of the frontends
- It contains of one or more image builds
- It contains zero or more upload actions
Image build
- The resulting image has a type: https://github.com/osbuild/osbuild-composer/blob/master/internal/distro/fedora30/distro.go#L19
- Running build in osbuild-composer is referred to as a "job" (internal terminology, not related to end-user experience)
Job
- What composer submits to a worker
- Is a unit of work performed by
osbuild(internally it is a single execution ofosbuild) - Consists of one image build and zero or more Upload actions
Image type
- In the cockpit-composer, for examples these are image types:
- Openstack
- Azure
- AWS
- As of now, we name them internally by their file format: vhd, ami, etc.
- You can see a list of types by executing:
composer-cli compose types
Upload action
- Each image can be, but does not have to be, uploaded to a remote location
- One image can be uploaded to multiple locations
Testing
See test/README.md