Skip to content

plugin-oci

Placement compiled-in (in-process)
Source github.com/opencharly/charly/candy/plugin-oci
Version 2026.194.1200
Candy plugin-oci

This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.

The reserved words this plugin serves:

  • oci — verb class

OUT-OF-TREE charly plugin serving the oci VERB (verb:oci) — the OCI IMAGE ENGINE externalized from charly core (the P14a cutover). It OWNS the go-containerregistry stack: the layer-MERGE engine (merge.go: planMerge → executeMerge → mergeLayers with full whiteout handling, plus the podman/skopeo daemon save/load) and the remote-image adopt-user PROBE (inspect_user.go: /etc/passwd lookup at a configured uid). Both run HOST-SIDE and exec podman/skopeo themselves — the verb:libvirt precedent — so go-containerregistry lives HERE, and charly/go.mod links it NOWHERE.

It is DUAL-PLACEMENT: its importable provider package (NewProvider/NewMeta, serving verb:oci) is COMPILED INTO charly when listed in charly.yml compiled_plugins: (the DEFAULT — the merge + adopt-user probes sit on the core BUILD PATH and must resolve project-lessly and reliably, mirroring the compiled-in verb:libvirt / verb:tunnel / verb:enc profile; registered in-process via registerCompiledPlugin), and the SAME provider is served OUT-OF-PROCESS over go-plugin gRPC by the cmd/serve shim (host-built + connected via LocalTransport) when it is not. Placement is invisible above the provider registry.

verb:oci is a pure INTERNAL RPC verb — NEVER authored as an oci: check step (it declares NO InputDef and ships NO schema; the load gate waives an input-less plugin). It is keyed by an OciOp env discriminator (mirroring the vm plugin’s VmOp): oci_op=merge decodes a spec.MergeRequest and returns a spec.MergeReply (layer counts + progress Notes the host prints; a per-merge failure rides Reply.Error), oci_op=inspect-user decodes a spec.ImageUserInput and returns a spec.UserInfo. charly box merge (candy/plugin-box’s mergeOneBox, P14) and candy/plugin-build’s drive both reach it DIRECTLY via Executor.InvokeProvider (verb:oci) — the F10 peer-dispatch leg; the ONE remaining core consumer is generate.go’s adopt-user resolution, reached via the oci_plugin.go shim (still core-side, K1-gated — see that file’s own migration-inventory note). The MERGE engine’s byte-identical relocation is locked by the candy’s TestMergeEngineGoldenParity (the merged-layer DiffID golden).


See also the candy reference for this candy’s install surface.