Feat/oci entrypoint cmd split

[jochumdev]

oci.entrypoint only ever stored the merged runtime Process.Args
(Entrypoint+Cmd concatenated), so there was no way to recover the image's
real, unmerged ENTRYPOINT. This adds oci.cmd, the image's raw Cmd,
alongside it — additive, oci.entrypoint keeps its existing meaning
unchanged. Callers recover the real entry point via
oci.entrypoint minus oci.cmd.

• client: capture the image's own Cmd from the local OCI layout at
  download time (via casext, same as umoci itself — no extra registry
  round-trip or subprocess), bundled into the metadata tarball.
• incusd/instance: populate oci.cmd at instance-create time, read
  straight from the image's stored metadata blob (not the per-instance
  unpacked volume, which doesn't reliably re-extract new tarball contents
  across instances sharing the same cached image).
• New API extension: instance_oci_cmd.

Verified against real registry pulls (single-ENTRYPOINT, CMD-only, and
both-set images).

❯ just incus create docker.io:library/mariadb:latest mariadb
❯ just incus config show mariadb
Using remote 'ict-daily':
incus config show mariadb
architecture: x86_64
config:
  environment.GOSU_VERSION: "1.19"
  environment.HOME: /root
  environment.LANG: C.UTF-8
  environment.MARIADB_VERSION: 1:12.3.2+maria~ubu2404
  environment.PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  environment.TERM: xterm
  image.architecture: x86_64
  image.description: docker-registry.jochum.dev/library/mariadb (OCI)
  image.id: library/mariadb:latest
  image.type: oci
  oci.cmd: mariadbd
  oci.cwd: /
  oci.entrypoint: docker-entrypoint.sh mariadbd
  oci.gid: "0"
  oci.uid: "0"
  volatile.apply_template: create
  volatile.base_image: e353ac2cffcdc087af1bae56dc817c60833588d5258be7d1f700701de794c2c2
  volatile.cloud-init.instance-id: d7fb5e08-0d06-42bb-a2bf-cc52d966a8f8
  volatile.container.oci: "true"
  volatile.eth0.hwaddr: 10:66:6a:2e:e1:70
  volatile.idmap.base: "0"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.uuid: 5558ca00-5c51-4c66-b7f3-d4daead82325
  volatile.uuid.generation: 5558ca00-5c51-4c66-b7f3-d4daead82325
devices: {}
ephemeral: false
profiles:
  - default
stateful: false
description: ""

[stgraber]

So I'm kinda confused here, why are you doing all that? As far as I can tell, the code never actually uses the new configuration entry, it just gets set but has no effect.

What's the problem you're trying to solve? Is it only about introspection by a 3rd party tool (incus-compose)?

[jochumdev]

Thanks for looking into this.

entrypoint and command are 2 different things used in many scenarios with tools like incus-compose.

In the end we need it to forward the right exec from compose files where the user can override one of both or both.

Biggest pain point is incus-compose run which executes entrypoint with a custom command.

I didn't change the oci.entrypoint handling at all for backward compatibility, would love too.

[jochumdev]

As you know incus-compose is meant as drop-in-replacement for docker compose.

[jochumdev]

umoci merges Entrypoint and Cmd into Process.Args before Incus sees the image
config, so the split is lost at import. From the output above:
oci.entrypoint: docker-entrypoint.sh mariadbd — nothing in Incus says whether
mariadbd is entry point or default command. Editing oci.entrypoint by hand
means guessing where the boundary is.

The only way to recover it today is pulling the image from the registry
outside Incus. incus image export doesn't carry it either.

Nothing in incusd consumes oci.cmd, agreed. It's descriptive.
oci.entrypoint stays as-is because people set it as the full command.

[stgraber]

Descriptive keys should be image metadata/properties, so image.XYZ, not oci.XYZ.

[jochumdev]

The rest of the patch looks good?

Then I'll name the key image.oci_cmd and the api extension ?

The api extension is important for the future me :)

[stgraber]

image.XYZ is automatically generated from image properties, so you just need the client logic to set a oci.cmd property in the image metadata and you'll get a image.oci.cmd property through Incus without having to change anything in Incus.

[jochumdev]

May I put oci.uid, oci.gid, oci.entrypoint (the unjoined one), oci.cwd as well as the new oci.command there?

That would help me a ton to get rid of my temp instances on image creation.

EDIT: the unjoined oci.entrypoint as image.oci.entrypoint might be confusing.

[stgraber]

uid, gid and cwd all already exist as actual oci.XYZ config key on the instance so the duplication doesn't make too much sense. If you need to record the original value because of the changes you're making, just set some user.incus-compose.XYZ config key to record them prior to making any change.

[jochumdev]

I need oci.uid and oci.gid for initial.xyz of custom storage volumes and I create the volume before the instance.
Thats why I need a temporary instance to have the volume and real instance with the "right" values.

Also oci.entrypoint and the future oci.command I need them before actually creating an instance.

[stgraber]

I need oci.uid and oci.gid for initial.xyz of custom storage volumes and I create the volume before the instance. Thats why I need a temporary instance to have the volume and real instance with the "right" values.

Also oci.entrypoint and the future oci.command I need them before actually creating an instance.

Hmm, that's starting to get too hackish for my taste. It's actually going to be pretty expensive to set those image properties and it's going to very confusing to users when they see the same values twice but only one of the two have any concrete impact on their instance.

At this point I'm thinking it just makes more sense for incus-compose to go get the stuff it needs from the registry and then just tell Incus what to run afterwards.

[jochumdev]

There is no need to set them to the image at the end I NEED oci.command nothing else temp instance is no problem at all.