Manifest generation

[teg]

Manifests are not meant to be written by hand, but are always generated by some higher level tool. The only one we currently officially support is osbuild-composer, but there is also the MPP in osbuild as well as various ad-hoc demos and scripts.

In the future, we may also see other tools use osbuild directly based on other higher-level image descriptions that will have to be translated. One could imagine COSA being a wrapper around osbuild, or even mock. Each of which would need a way to generate manifests.

All that aside, I would like to focus this discussion mostly on serving the needs of osbuild-composer, and if we should move the manifest generation we currently do in osbuild-composer to osbuild itself.

Depsolve

Depsolving in osbuild-composer currently has two problems:

1. We may only have access to the yum repository from the worker, not from osbuild-composer itself. This is one of the blokckers for using the same osbuild-composer instance from brew as from cloud.redhat.com.
2. We are currently relying on dnf being backwards and forwards compatible across all the distributions we wish to support.

Potential solution

If we could have a depsolve stage that would allow osbuild-composer to pass the request to be depsolved to osbuild as a manifest, and the result be returned as metadata, this might solve both problems. The manifest would pin the build environment so that the version of dnf would be fixed and this would be run as a job in a worker, not in osbuild-composer itself.

Challenges

This would leave us with the old issue of pinning down the repodata to be depsolved against in the manifest, and as we know that might be troublesome on a frequently updated release. Also, the build pipeline of the depsolve manifest would itself need to be depsolved. Do we do this once and reuse the same hard-coded manifest, or do we go back to relying on the host to have dnf installed (not solving problem 2 above, but leaving that in its current state where we rely on dnf from the composer host).

Distro definitions

In addition to depsolving, the second part of manifest generation that currently lives in osbuild-compore is the distro definitions themselves. We have long struggled with the fact that the distro definitions should live (and be tested!) much closer to osbuild than they currently do. Developing a new image type / distro, would typically require much more coordination with osbuild than with the rest of osbulid-composer, and it would be useful for people to be able to consume distro definitions also outside of osbuild-composer.

A potential solution to this would be to extend the depsolve manifest outlined above to be a full manifest generation manifest, where the kind of options to pass would be similar to the current Distro interface in osbuild-composer, and the result would not be an artifact but a manifest itself. I would imagine each image type having its own stage for this purpose, so that the options they take could evolve over time.

osbuild-composer would still need to know about the various distros / image-types to pass the right arguments, but would then mostly be a glorified queue, and the actual logic would live in osbuild.

[teg]

The above was the result of a discussion with @larskarlitski, I'm curious to hear what everyone thinks :)

[achilleas-k]

Depsolve

Depsolving in osbuild-composer currently has two problems:

1. We may only have access to the yum repository from the worker, not from osbuild-composer itself. This is one of the blokckers for using the same osbuild-composer instance from brew as from cloud.redhat.com.
2. We are currently relying on dnf being backwards and forwards compatible across all the distributions we wish to support.

Potential solution

If we could have a depsolve stage that would allow osbuild-composer to pass the request to be depsolved to osbuild as a manifest, and the result be returned as metadata, this might solve both problems. The manifest would pin the build environment so that the version of dnf would be fixed and this would be run as a job in a worker, not in osbuild-composer itself.

I like the idea of moving depsolve into osbuild as a stage, though I have a few questions about how the current workflow (if left unchanged) would be affected.

Would depsolve jobs work like compose jobs do now (through a job queue)? If it does, how does it affect depsolving during a compose request creation, before it's submitted. Currently, depsolve is treated almost as a priority operation and always synchronously, so I imagine we'd have to design around it being asynchronous. This isn't a blocker, but could be a challenge (or at least a major redesign).

Challenges

This would leave us with the old issue of pinning down the repodata to be depsolved against in the manifest, and as we know that might be troublesome on a frequently updated release. Also, the build pipeline of the depsolve manifest would itself need to be depsolved. Do we do this once and reuse the same hard-coded manifest, or do we go back to relying on the host to have dnf installed (not solving problem 2 above, but leaving that in its current state where we rely on dnf from the composer host).

I think our discussion about package sets for image types in osbuild-composer is relevant here. Or more generally, the way the new manifest format generalises building and assembling as (essentially arbitrary) pipelines makes me wonder whether there's also a general solution to depsolving any package set and whether there would need to be special options for different sets—something we've discussed already, but worth considering in this context as well.

[ondrejbudai]

Would depsolve jobs work like compose jobs do now (through a job queue)? If it does, how does it affect depsolving during a compose request creation, before it's submitted. Currently, depsolve is treated almost as a priority operation and always synchronously, so I imagine we'd have to design around it being asynchronous. This isn't a blocker, but could be a challenge (or at least a major redesign).

For the local use case, I think that one solution is to have a dedicated worker just doing depsolves because the Weldr API has routes that return depsolved content.

For the cloud service use cases, I think we can switch to doing depsolves asynchronously.

[teg]

I agree @achilleas-k and @ondrejbudai, for the non-weldr case, depsolve should be done just like a compose job currently is. /compose would just queue the Depsolve() request, and when it succeeds, we would have a compos object with metadata attached to it (manifests, package sets, etc), but no actual image builds. This would also allow us to catch any errors in the compose request that we can catch before actually trying to build anything. The actual image build would be done by calling second route on the /compose/* object. This would also allow us to rebuild expired (garbage collected) images from exactly the same manifests if that's desired.

From the UI point of view, I imagine the initial /compose call could be done hen you click the last Next button before the Review screen in the wizard, and the Review screen could actually show more details about the images we are about to build as we would know things like the fully depsolved package sets etc.

[teg]

Proof of concept: osbuild/osbuild-composer#1286