Full or partial osbuild schema v2 migration

[achilleas-k]

Context

• osbuild manifest schema has changed considerably: Introduce format version 2 osbuild#578.
• Initial support for the schema was added in osbuild-composer for two new image types, enabled by the new schema: Support osbuild format v2 osbuild-composer#1244.
• Changes to existing image types were already made to accommodate the new schema: Distro: replace Packages() / BuildPackages() with PackageSets() osbuild-composer#1279 and Main compose packagesets osbuild-composer#1299.

Open questions

• Migrate all existing image types to new schema?
• What is osbuild's plan for completing the migration? Will it support the old schema for long or drop it soon?

Proposed plan(s)

1. Migrate all ostree images (rhel-edge-* and fedora-iot-*) to the new schema.
   • Bugs in the current rhel-edge-commit and fedora-iot-commit image types are solved by the new schema and may not be simple to backport to the old image types using the old schema. Backporting these changes is probably not worthwhile.
     • RHBZ#1896178 is fixed by the ostree-preptree stage, which may not be compatible with the old ostree stage. (Trying to confirm this now).
2. Migrate everything to the new schema.

We could immediately start porting all existing image types to the new schema, making sure that all generated artifacts are identical between versions. Otherwise, we can start gradually by porting the ostree image types.

[ondrejbudai]

I suggest only converting new distros - let's start with RHEL 8.5 and Fedora 34. We usually don't modify the older distros.

[achilleas-k]

I know that's the general policy, but are we also planning on keeping the manifest support in osbuild until we drop RHEL 8.4 and F33?

[teg]

I think so, yes.

[gicmo]

One thing to note is that osbuild internally converts to the new format, so converting the old distros while making sure the format matches what osbuild internally would use would not be "modifying" them. I think it is ok the keep v1 support around for a while in osbuild, although all tests but the v1 unit test will slowly but surely migrate the v2. But I I am just wondering how much of a hassle it will be in composer to keep working with two manifest versions and more importantly result versions.
One thing that I find super weird though is that ostree 8.4 tarballs are using different format than ostrees in container, since that uses different code and thus might actually have slightly different behaviour and we need to keep one assembler and a stage in sync the whole time (and they are now actually out of sync, I just realised).

[teg]

My default assumption would be that we don't modify released distro definitions, and that released osbuild is backwards compatible "forever". We want people to be able to build old manifests, either because they saved them or because they are in some cache / queue somewhere. We don't really know all the ways/places osbuild is being used.
We could make some argument about transforming the manifests in a compatible way in composer, but considering the above, and the way that we cannot change behaviour (no matter how broken it currently is, unless we do a z-stream release), I doubt there would be much benefit...

[achilleas-k]

Decision through discussion in other channels:
New images will be added using the new Manifest schema starting with the Edge/IoT types for RHEL 8.5 and Fedora 34.