b5769add2c
The store is responsible for two things: user state and the compose queue. This is problematic, because the rcm API has slightly different semantics from weldr and only used the queue part of the store. Also, the store is simply too complex. This commit splits the queue part out, using the new jobqueue package in both the weldr and the rcm package. The queue is saved to a new directory `queue/`. The weldr package now also has access to a worker server to enqueue and list jobs. Its store continues to track composes, but the `QueueStatus` for each compose (and image build) is deprecated. The field in `ImageBuild` is kept for backwards compatibility for composes which finished before this change, but a lot of code dealing with it in package compose is dropped. store.PushCompose() is degraded to storing a new compose. It should probably be renamed in the future. store.PopJob() is removed. Job ids are now independent of compose ids. Because of that, the local target gains ComposeId and ImageBuildId fields, because a worker cannot infer those from a job anymore. This also necessitates a change in the worker API: the job routes are changed to expect that instead of a (compose id, image build id) pair. The route that accepts built images keeps that pair, because it reports the image back to weldr. worker.Server() now interacts with a job queue instead of the store. It gains public functions that allow enqueuing an osbuild job and getting its status, because only it knows about the specific argument and result types in the job queue (OSBuildJob and OSBuildJobResult). One oddity remains: it needs to report an uploaded image to weldr. Do this with a function that's passed in for now, so that the dependency to the store can be dropped completely. The rcm API drops its dependencies to package blueprint and store, because it too interacts only with the worker server now. Fixes #342 |
||
|---|---|---|
| .github/workflows | ||
| cmd | ||
| distribution | ||
| docs | ||
| image-types | ||
| internal | ||
| jenkins | ||
| osbuild@245809f40d | ||
| repositories | ||
| test | ||
| tools | ||
| vendor | ||
| .gitignore | ||
| .gitmodules | ||
| .golangci.yml | ||
| .travis.yml | ||
| codecov.yml | ||
| CONTRIBUTING.md | ||
| dnf-json | ||
| go.mod | ||
| go.sum | ||
| golang-github-osbuild-composer.spec | ||
| LICENSE | ||
| Makefile | ||
| NEWS.md | ||
| osbuild-composer.spec | ||
| README.md | ||
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
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 >= 11systemd >= 244
At build-time, the following software is required:
go >= 1.12python-docutils >= 0.13
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:
mkdir build
go build -o build ./...
The man-pages require python-docutils and can be built via:
make man
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, Travis CI, 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.