Re: [meta-virtualization][PATCH 1/2] image-oci: add OCI runtime bundle output

[Bruce Ashfield <bruce.ashfield@gmail.com>]

Hi Tanguy,

Sorry for the slow reply, I've been busy since getting back from
OSSEU.

Dropping the postprocess-hook half clears the architectural concern,
and the real gap you've identified (runtime-spec fields with no
OCI_IMAGE_* equivalent) is worth addressing properly.

Context first, because it probably isn't in anyone else's memory
but mine (as it deals with the historcal path I took to the
current support and bundling):

Some is obvious, some isn't, but I'm stating it for the mailing
list archive.

image-oci already produces a runnable OCI runtime bundle during the
build. The umoci backend creates ${IMAGE_NAME}-oci-bundle/ with a
flat rootfs/ and config.json as a working intermediate (see
classes/image-oci-umoci.inc, the image_bundle_name variable). The
final rm at the end is the only thing that stops it being a
first-class output. The top-of-file docstring in
classes/image-oci.bbclass has walked through this flow since 2021,
including "runc run -b container-base-oci-bundle ctr-build" as the
canonical runnable form -- the capability has been there, it just
hasn't been exposed as a shippable artifact when using umoci.

So what I'm going to do:

1. Reinstate the historical dual-form tar convention described in the
   umoci backend's comment block at classes/image-oci-umoci.inc.  The
   .tar form (not -dir.tar) carries blobs/, oci-layout, index.json AND
   top-level rootfs/, config.json together, so extracting it gives
   both the OCI layout and a runnable bundle side by side. The current
   code only tars the layout contents; the comment is accurate for the
   intent, the code drifted. Fix: preserve $image_bundle_name through
   the tar step and include its contents in $image_name.tar.

   Both backends (umoci and sloci) will honor the same convention.
   Multi-layer squashing is a free consequence of umoci's own
   unpack-after-each-layer-repack flow -- the final bundle rootfs
   already reflects the full stacked tree flat.

   Rather than making this opt-in, this becomes the default output
   going forward for new builds, with the layout-only -dir.tar form
   preserved so existing users don't break.

2. Make bundles cross-installable, parallel to how
   container-cross-install.bbclass already treats docker and podman
   images. New BUNDLED_CONTAINERS flavor along the lines of
   "name:crun[:autostart]" (and/or ":runc" / ":bundle" -- naming
   TBD). The install step extracts rootfs/ + config.json from the
   .tar on-host at build time, lands them in the target rootfs at a
   stable path (/usr/share/oci-bundles/<name>/ or similar), and the
   first-boot generator writes a systemd unit that calls
   "crun run -b <path> <name>" ... similar to the existing
   generate_docker_service_from_bundle / generate_podman_service_
   from_bundle paths. Runtime (crun or runc) gets added to RDEPENDS
   when any BUNDLED_CONTAINERS entry uses the new flavor, same
   mechanism docker/podman use today.

3. First-class runtime-spec recipe variables for the fields you
   actually need to configure: mounts, capabilities, namespaces,
   readonly rootfs, no-new-privileges, resource limits as they
   surface, etc. These live in image-oci as regular recipe
   variables that control what gets emitted into config.json during
   the umoci / sloci build, so the recipe fully describes the
   container's identity end-to-end. We already have OCI_IMAGE_* for
   the image-spec fields (env, cmd, entrypoint, workingdir, user,
   labels, ports); the runtime-spec additions are the natural
   extension. Naming (keep OCI_IMAGE_* for coherence vs. introduce
   OCI_BUNDLE_* for strict spec-family hygiene) is still something
   I need to decide.

If this plan matches what you need, can you send a list of the
variables that you've identified as needed ? Along with expected
runtime results (if any) .. and with that, I can test what I've
pulled together in my WIP branches.

Cheers,

Bruce