Variants 🧬¶
How the development deploy CLI consumes per-role meta/variants.yml and iterates the resulting matrix at deploy time.
For general documentation rules such as links, writing style, RFC 2119 keywords, and Sphinx behavior, see documentation.md.
For the file format itself see variants.md.
For how a single round’s inventory is assembled (the layer this matrix wrapper sits on top of), see inventory.md.
For the contributor-facing make target / dev-CLI workflow see deploy.md.
Folder-per-round model 🎛️¶
The development deploy CLI uses a folder-per-round model that splits cleanly between the init step (which materialises the inventories) and the deploy step (which iterates them):
Round count.
total_rounds = max(variant_count for app in primary_apps). If every primary app has only one variant, both steps degrade to a single folder and the unsuffixed inventory path is used.Per-round variant selection. In round R every primary app uses variant index
R if R < its_variant_count else 0. So a single-variant app stays on variant 0 in every round, and a 3-variant app in a 5-round deploy follows0, 1, 2, 0, 0.Inventory folders. init.py calls build_dev_inventory_matrix, which creates one folder per round at
<inventory-dir>-<round>(or just<inventory-dir>when there is a single round). For each folder,build_dev_inventoryresolves the round’s per-app variant payload and bakes it into the inventory’shost_varsasapplications.<app>: <variant-payload>overrides. The inventory is therefore variant-resolved on disk; no runtime selector is needed.Deploy iteration. deploy/cli.py re-derives the same plan via
plan_dev_inventory_matrix(the planner is a pure function shared between init and deploy) and runs one deploy per folder. Every round deploys its full variant-aware include set. Round R starts from a clean host (the previous round’s include is purged before round R begins, see point 5), so every dep that round R needs MUST be redeployed.Cleanup between rounds. Before each non-first iteration the wrapper runs entity.sh for every app in the previous round’s include set. The next round therefore boots from an empty host, which guarantees cross-round state coherence: nothing the previous round deployed (whether it stays in the current round’s closure or falls out) can leak into round R, so variants are free to disagree on which deps they pull in. The final round is followed by no purge so the last state remains available for inspection or follow-up specs.
--full-cycle(async update pass). When set (orfull_cycle=trueonmake compose-deploy), the wrapper runs each round’s deploy TWICE: first the regular sync pass, then immediately a second pass with-e ASYNC_ENABLED=trueoverriding the host_var, against the SAME variant’s folder, BEFORE moving to the next round. The two passes are therefore always co-located on the same host state; the async pass never accidentally targets a host that a previous round’s variant left behind.Pinning rounds (single or bundle). Both init and deploy accept
--variant <csv>(same semantics as thevariant=make arg): a single index (1) pins one round, a comma-separated list (0,1,2) iterates that subset, and empty/unset is the full matrix. When the selection is a single round no inter-round cleanup runs (no previous round to diff against); out-of-range indices raise a clean error. Themake compose-deploy mode=updateflows honour the samevariant=arg by suffixingINFINITO_INVENTORY_DIR/INFINITO_INVENTORY_FILEto<base>-<idx>(single index), so a redeploy can target one specific variant without iterating the full matrix.CI runner-split. The deploy-matrix discovery (axes.py, wired via output_apps.sh) gives every variant its own matrix entry (runner): a 5-variant role becomes five rows
0…4, each carrying the deploy mode and tor state the sweep rotation assigned it. Each runner receives its variant through thevariantenv (consumed by--variant). Which rows a given run deploys is decided by the chunker (chunks.py), not by bundling.
The in-play loader (utils.cache.applications.get_merged_applications) uses each role’s variant-free base config (the assembled meta/<topic>.yml payload) as the default and lets the inventory’s applications.<app> overrides win via deep merge: the inventory itself is the source of truth for what variant a round runs against. Variant 0 enumerates every dynamic service-key from meta/services.yml with enabled: true, shared: true so the “all flags on” baseline is explicit and deep-merge with a non-baseline override yields the expected variant-N shape (see variants.md for the file-format rule and test_non_baseline_explicit_disables.py for the lint guard).
Credentials Generation 🔐¶
Credential generation participates in the matrix model so the shared providers a variant actually pulls in (via services.<key>.enabled+shared) receive their schema-defined credentials in the inventory before deploy time.
CI/CD Path 🤖¶
The dev-deploy CLI threads the variant index through three layers so a variant’s variants.yml overlay reaches the credential subprocess.
build_dev_inventoryreadsspec.variant_selectors()from the planner. When the round pins any variant, it appends--app-variants <JSON>to theinfinito administration inventory provisioninvocation with the per-app{app_id: variant_index}mapping.The provision CLI parses the JSON and forwards the per-app index as
--variant <N>to eachinfinito administration inventory credentialssubprocess call.InventoryManagerresolves the root role’s config viaget_variants(roles_dir)[app_id][N]soresolve_schema_includes_recursivesees the variant-mergedservicesmap and discovers every shared provider the variant enables.
The resulting snippets cover every shared provider in the variant’s closure, so the deploy stage finds the required applications.<provider>.secrets.credentials block in the inventory and lookup('config', '<provider>', 'secrets.credentials.<key>') succeeds.
The variant only affects inventory generation; the Ansible deploy itself reads applications.<app> overrides from the variant-resolved inventory and MUST NOT consult variant data at runtime.
Standalone Path 🖥️¶
Direct callers that do not run the matrix planner (manual infinito administration inventory provision, ad-hoc credential refresh, make compose-up) omit --app-variants / --variant.
The CLIs default variant to None so:
InventoryManagerskips the variants overlay and reads the role’s basemeta/<topic>.ymlpayload directly via_meta_role_config.Shared-provider discovery sees only what the base config enables.
Generated credentials cover the base config only.
Apps without a meta/variants.yml file collapse to a single empty overlay in _load_variants_overrides, so --variant 0 and the standalone path produce identical credential snippets for them.
What not to do 🚫¶
You MUST NOT introduce a parallel cache. The variants are cached per
roles_dirinsideutils/cache/applications.pyand returned as deep copies; mutating the result MUST NOT corrupt subsequent lookups.You MUST NOT skip the inter-round purge.
You MUST NOT introduce a runtime variant-selector extra-var. Variant data lives in the inventory after init; the deploy stage reads it as plain
applications.<app>overrides.
Reference files 📌¶
File |
Purpose |
|---|---|
File-structure rules for |
|
Loader and cache for |
|
Dev inventory build package. Per-submodule split: |
|
Dev CLI entry that drives |
|
Dev CLI entry that re-derives the matrix plan and iterates one deploy per folder, with per-app cleanup between rounds. |
|
Cleanup script invoked between rounds for every app in the previous round’s include set. |
|
Unit tests covering parser edge cases, deep-merge semantics, caching, and the variant-zero default path. |
|
Unit-test package mirroring the source split: |
|
Wrapper-level tests covering the per-round folder iteration and cleanup logic. |
|
Parses |
|
Issues one credentials subprocess per app, appending |
|
|
|
Loads the root role’s variant-merged config via |