NVKE M2 inputs and customer choices
The M2 Definition selects 69 named outputs, including independent
linux/amd64 and linux/arm64 plain and public-bootstrap FDE disks. FDE publication carries build provenance
without inspected-content or deployed-confidentiality claims; see the candidate’s FDE scope.
The catalog owns producer commands, material edges and
component-exposed Packer variables. The Environment owns runner, runtime, registry and signing choices.
There is no generic Definition overrides field or arbitrary Packer/HCL rewriting.
Input evidence map
The M2 input guide records the detailed source paths and remaining acceptance gaps. Catalog/graph validation authenticates selections, not installed containment, build compatibility or publication acceptance.
Replace a supplier without changing NVKR
- Copy the Definition into your project and copy or re-point its referenced catalogs and overlays: relative catalog base and overlay paths are resolved from the Definition’s directory. Select your catalog explicitly. Retain every required disk material, or deliberately change the disk producer’s complete material contract and selection together.
- Pin sources and acquired bytes with
catalog pin/catalog pin-artifacts. Do not edit lock hashes or replace them with floating tags. These commands maintain a catalog directory’s lock, not supplier-overlayprebuilt.digests. Those inline digests are reviewed, authored values for the exact supplier bytes, as shown in the authoring lab. A source release update is not a producer override. - To keep a logical component name but change how it is supplied, use a whole-producer catalog overlay.
A source-built
nvke-cni-calicocan become a digest-pinned acquired tarball with the same output type and supported platforms. Its contents must still satisfy NVKE’s image-input composition interface. - Apply the supplier overlay after
native-toolchains.yaml. Its predecessor is the resulting native catalog snapshot, not the earlier base snapshot. Changing any OS-catalog pin changes its snapshot: reissuenative-toolchains.yamland each later overlay against its new exact predecessor through a reviewed decision. The current predecessor digests do not survive a repin; admission rejects them. Omitting or reordering an overlay fails admission. - Put that catalog stack on only the outputs that should use it. ARM64 and AMD64 are independent output selections, so a customer can retain the original supplier for one and substitute the other.
Use the existing runnable authoring lab for schema-exact complete
Definitions, supplier overlays, per-output stacks and retained before/after Plans. It works offline after
building nvkr; its supplier is explicitly a fixture, not a production NVKE package. It avoids inventing
an unverified package URL or digest in this guide.
The M2-specific TestMaintainedM2CustomerMaterialReplacement applies catalog stacks and compiles both
native disk graphs with fixture source and acquired Calico suppliers. It checks changed Build identity
and exact material dependency edges. Its negative cases check Resolve selection errors for a missing
material, an unknown component and a platform mismatch; they do not test supplier downloads, missing
supplier digests, overlay reordering or the complete public document-loading path. These are graph
contracts, not container or image-build tests.
Validate the complete maintained graph
With authorized access to the exact private source objects:
The complete test invokes public factory.CompileDocuments, including production’s ordered overlay
loader, Environment admission and cross-output packaging relationships. A local Git insteadOf mapping
may supply identical pinned source bytes without changing any catalog identity; the
deploy guide shows invocation-scoped configuration.
Regenerate the bundle from the same Definition and Environment and check drift.
Neither graph compilation nor regeneration proves a successful hosted delivery.