plugin-deploy-pod
| Version | 2026.180.0001 |
| Repo | superproject |
| Plugin | yes — see the plugin reference |
OUT-OF-TREE charly DEPLOY plugin serving the pod deploy SUBSTRATE —
target: pod (the DEFAULT substrate: a deployment run as a container image via
quadlet/podman). A standalone Go module (go.mod + main.go) served over go-plugin
gRPC via the charly plugin SDK; charly’s loader host-builds the provider binary
and connects it OUT-OF-PROCESS (LocalTransport). The host’s plugin-side deploy
target Invokes it (OpExecute) with the deployment’s InstallPlan VIEWS + a venue
descriptor and the
host’s executor served on the broker. Unlike deploy:vm (whose plugin WALKS the
plan inside the guest), pod bakes its install steps INTO the image at BUILD time:
the host’s pod lifecycle hook (pod_deploy_lifecycle.go) drives the overlay
container image build in PrepareVenue — but P11c DISSOLVED the render OUT of
charly core INTO this candy: the host prep (hostBuildOverlay) returns the
OverlayBuildReply envelope (ResolvedProject + Plans + base-image metadata +
per-overlay-candy security + parent bind-mount volumes), and the candy imports
sdk/deploykit+buildkit+kit DIRECTLY (IMPORT-PURITY, ZERO-ALIASES), constructs the
deploykit.Generator itself (the shared NewRenderGeneratorFromProject helper — the
SAME source candy/plugin-build uses, R3), renders the overlay Containerfile in its
own code, and runs podman build + the deploy-name alias tag via its served host
executor. Each per-step Containerfile fragment is rendered HOST-SIDE over the
generic “step-emit” host-builder (deploykit.OCITarget.EmitStepOp →
HostBuild(“step-emit”,“oci-emit-step”,…) → the host’s ociEmitStep, byte-identical to
the former in-core emitStep) — so the render lives in the candy while each step
fragment crosses the reverse channel. The bed runner / charly start configs +
starts the container.
So there is NO per-step venue walk for pod: this plugin’s Invoke does NOT call
kit.WalkPlans — it returns an EMPTY DeployReply (pod teardown is charly remove +
drop overlay images, owned by the host lifecycle hook’s PostTeardown). The
pod-substrate sibling of candy/plugin-deploy-vm; the host’s pod lifecycle hook
owns the container lifecycle (overlay build + config/start/remove + the
charly update rebuild gate), this plugin serves the substrate word
out-of-process. P11 (Ruling C): the pod config-WRITE also moved here — the
OpConfigWrite Op renders the quadlet/.pod/sidecar/tunnel file CONTENTS (via the
deploykit GenerateQuadlet/GeneratePodQuadlet/GenerateSidecarQuadlet/
GenerateTunnelUnit generators) and os.WriteFiles them at the host-resolved
absolute paths + exact modes (0600/0600/0600/0644). charly config (host)
resolves the QuadletConfig + computes the paths + provisions dirs/secrets +
runs the systemctl/enc/seed side-effects, then connects this plugin on-demand
(connectPluginByWordRef, like the credential/vm/kube host out-calls) and Invokes
OpConfigWrite — so the WRITE is the plugin’s, byte-identical to the former
in-core write phase.
Acceptance plan
Section titled “Acceptance plan”This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.
| Intent | Step |
|---|---|
check |
the out-of-tree deploy:pod plugin ships a buildable Go module (go.mod + the provider main) the host can build + serve out-of-process |