Stage separation in osbuild

[supakeen]

osbuild uses modules (stages, mounts, etc) to perform actions in its buildroot(s). These modules are currently tightly coupled with osbuild the library both ways, osbuild imports these modules to inspect their schema and other attributes and these modules import from osbuild to share common functionality.

This comes with a few disadvantages:

1. Modules must be written in Python.
2. Some osbuild things can't change due to them being used by modules.
3. It's hard to execute an osbuild module without also having the buildroot be set up by osbuild.

There's been some ongoing chat. I'm opening this discussion to centralize all of that and have a longer term discussion about viability.

In my perfect world any executable that implements the osbuild "protocols" should be able to be used as a stage, no matter what language it was written in. This offers us the nice ability to in some cases use libraries instead of command-line tool wrappers. It also offers us to handle SELinux more gracefully.

TODO

Modules become independent of osbuild

This step is a bit larger. Modules currently import things from osbuild to handle the communication means between osbuild and themselves. There's also other shared code (ostree, for example) living in osbuild.

I'd propose to add an osbuild_ext (name tbd) module where code to be used in modules written in Python lives. Separate from osbuild itself.

Revisit the communication

Currently arguments, services, and assorted other things are communicated with files and sockets in the buildroot. While not all of this needs to be changed we have previously ran into issues with messages being too large for the seqpacket being used.

I'd like to especially switch /run/osbuild/arguments to be passed over stdin which would make it easier to execute stages outside of a buildroot.

...

After communication has been revisited we can take a look at implementing a stage in a different language (Go, Rust, C) and deal with the issues arising from that (architecture-specifity, that sort of stuff).

Random Things

1. Module versioning would be super nice; I can use org.osbuild.noop-v0.1 and we can do deprecation on specific versions when newer versions come out?
2. Change the organisation of the stage to include a self-test, @mvo5 has been working on adding stage tests; what if each stage has a default test-executable as well?
3. ...

DONE

✅ Modules become executable (but stay Python)

As a first step the modules become executable. Instead of importing the module from osbuild we obtain the necessary information (schema, doc, etc) through other means. We've chose to provide a secondary file which contains the JSON called $stage.meta.json that lives next to the stage. This was implemented in osbuild/osbuild#1618 and ported to all stages in osbuild/osbuild#1663

[supakeen]

@mvo5 has a PR implementing the opening bits of this open here: osbuild/osbuild#1460

This allows for storing the schema outside the module and removes the need for Python importing the modules.

[supakeen]

We have merged a PR implementing the opening bits of this: osbuild/osbuild#1618 so we've completed the first step (Modules become executable (but stay Python)) in this idea. I've opened another PR here osbuild/osbuild#1663 to make all current stages use this idiom.

Let's start refining the next step (Modules become independent of osbuild).