85 lines
7.1 KiB
Markdown
85 lines
7.1 KiB
Markdown
# Deferred ideas / future enhancements (orchestrator-tracked)
|
|
|
|
Post-DONE or "revisit later" ideas that are intentionally **out of scope** for the current build
|
|
(§2 Definition of Done). Not active work — parked here so they aren't lost. The loops may pull an
|
|
item into the project `BACKLOG.md` as `[idea]` if/when it becomes relevant.
|
|
|
|
- [ ] **ALT infra-app model: deploy traefik / warm-keycloak / drone the normal Co-op Cloud way,
|
|
updated outside Nix via abra by maintainers.** *(operator-flagged 2026-05-29, alternative to the
|
|
current Phase-2w design — return to later)*
|
|
The **current** design Nix-*reconciles* the infra/warm apps: NixOS systemd oneshots run `abra` to
|
|
deploy traefik/keycloak/drone, and a nightly `nixos-rebuild` auto-updates them to latest with a
|
|
pre-deploy major/manual-migration gate (WC1.2) + post-deploy health-gated rollback (WC1.1).
|
|
**The alternative:** treat the CI server like a normal Co-op Cloud host — traefik, the warm
|
|
keycloak, and drone are **plain abra deployments managed by maintainers**, deployed once and
|
|
**upgraded by a human via `abra app upgrade`** (using abra's own release-notes / major-bump
|
|
caution), with **no Nix reconciler and no nightly auto-update** for them. Nix would provide only
|
|
the host substrate (OS, docker/swarm, the harness, secrets), not the infra-app lifecycle.
|
|
- *Pros:* simpler — no reconciler/rollback/nightly machinery; idiomatic Co-op Cloud ops (maintainers
|
|
manage these exactly like any other coop-cloud app); updates are normal human abra actions; lower
|
|
cognitive load (no "infra is special / Nix-driven" layer).
|
|
- *Cons:* the infra apps are **no longer reproducible-from-git** — a VM recreate (the D8 throwaway
|
|
rebuild) would NOT re-establish traefik/keycloak/drone; they'd need manual redeploy after a
|
|
rebuild (D8 then covers only the host + harness, not the infra apps). Loses the automated
|
|
nightly-latest + health-gated auto-rollback; infra updates + rollback become manual/operator
|
|
discipline. Drifts from the project's "declarative, rebuildable from scratch" ethos.
|
|
- *Note:* it's essentially one-or-the-other for the **update path** — a hybrid where Nix bootstraps
|
|
them but maintainers also `abra app upgrade` them creates the dual-ownership conflict (the Nix
|
|
reconciler would fight/redeploy over the maintainer's version on the next activation).
|
|
- *When to revisit:* if the reconciler + rollback + nightly machinery proves high-maintenance or
|
|
brittle, or if maintainers strongly prefer normal coop-cloud workflow over the Nix layer — weigh
|
|
that against how much we value full reproducibility (D8) + hands-off auto-updates. *Added:* 2026-05-29.
|
|
|
|
- [ ] **Docker Hub pull-through registry cache (`registry:2` proxy) — deferred; single-host makes it marginal.**
|
|
Considered as a Phase-2pc perf win, then **dropped (operator, 2026-05-29):** on a **single host**,
|
|
Docker's own local image store already caches pulled images (re-deploys reuse local layers), so the
|
|
prune-policy fix (Phase 2pc PC1) recovers ~all the benefit. A separate pull-through cache's
|
|
distinctive wins don't apply here — multi-node fan-out (one node), surviving prune/VM-rebuild on
|
|
*separate* storage (ours would be co-located, lost on recreate), cache-miss auth (daemon already
|
|
PAT-authenticated). **Revisit ONLY if:** (a) cc-ci goes **multi-node**, OR (b) Phase-2b measurement
|
|
shows **cold-cache / fresh-deploy pull time** (D8 throwaway-rebuild, fresh-canonical seeding) is a
|
|
real bottleneck **AND** the cache lives on **recreate-surviving storage** (Incus volume / host-b1
|
|
path, not the VM's ephemeral disk). Otherwise it's complexity without payoff. *Added:* 2026-05-29.
|
|
|
|
- [ ] **Optional `--extra` flag for heavy / operational tests (opt-in heavy suite).**
|
|
Some recipe tests are "more than needed" for the default CI signal — state-management /
|
|
long-running-instance / load / helper-script operational tests that don't fit the ephemeral
|
|
per-run-deploy model cheaply but are useful occasionally. Today they're deferred to
|
|
`cc-ci/machine-docs/DEFERRED.md` (e.g. matrix-synapse `compress_state.sh`,
|
|
`test_complexity_limit.sh`, `test_purge.sh`) and don't run.
|
|
*Idea:* add an **opt-in `--extra` flag** (e.g. `!testme --extra` on a PR comment, or
|
|
a `STAGES=extra` / `EXTRA_TESTS=1` Drone build parameter) that the orchestrator passes through;
|
|
recipes declare an `extra/` test dir or mark tests with `@pytest.mark.extra`; on opt-in the
|
|
orchestrator runs them **alongside** the default tiers (still one deploy, still teardown). Default
|
|
off so default CI stays fast; the operator can ask for the heavy suite when reviewing a PR that
|
|
touches an extra-covered area (e.g. matrix-synapse's abra helpers). When implemented, each
|
|
matching DEFERRED entry can be CLOSED by porting its test into the recipe's `extra/` and noting
|
|
the commit in DEFERRED.md. *Why deferred for now:* default coverage is sufficient; this is a
|
|
later breadth/depth knob, not a critical-path feature. *Added:* 2026-05-28.
|
|
|
|
- [ ] **Optional webhook self-registration (admin-access environments).**
|
|
We deliberately made **polling the primary trigger** and require the CI server/bot to run on
|
|
**read-level** access only — so the server does **not** auto-register Gitea webhooks (that needs
|
|
repo-admin), and webhook setup is a documented manual admin task (§4.1, `docs/enroll-recipe.md`).
|
|
*Later*, for environments where the CI server **does** hold admin on the recipe repos (or an
|
|
org-level admin token is available), consider adding an **opt-in, off-by-default** feature
|
|
(e.g. `WEBHOOK_AUTOREGISTER=1`) that auto-registers and **idempotently reconciles** the
|
|
`issue_comment` webhook (URL, events, HMAC secret) on enrolled repos — matching our
|
|
declarative-reconcile pattern (§9) — giving low-latency push triggering with zero manual setup.
|
|
Must stay off by default and fall back to manual-doc + polling when admin isn't available, so the
|
|
least-privilege (read-only) default is preserved. *Why deferred:* polling already satisfies D1 and
|
|
the read-only posture is the goal; this is a convenience optimization for a different deployment
|
|
profile. *Added:* 2026-05-27.
|
|
|
|
- **Docker Hub `registry:2` pull-through cache (deferred from Phase 2pc).** A local registry in
|
|
proxy/pull-through mode, daemon `registry-mirrors`-wired, so all `docker.io` pulls are cached
|
|
locally across recipes/runs/prunes. **Deferred (operator, 2026-05-29):** on the current
|
|
**single, PAT-authenticated, non-pruning** host, Docker's own local image store already IS the
|
|
cache (redeploys reuse local layers — proven in Phase 2pc), so a separate registry adds a service +
|
|
mirror config + cache GC for marginal gain; its distinctive wins (multi-node fan-out, surviving
|
|
prune/VM-rebuild on *separate* storage, cache-miss auth) don't apply here. **Revisit ONLY if** (a)
|
|
cc-ci goes **multi-node**, OR (b) Phase-2b measurement shows **cold-deploy pull time is a real
|
|
bottleneck** (e.g. D8 throwaway-rebuild / fresh-canonical seeding) **AND** the cache lives on
|
|
**recreate-surviving storage** (an Incus volume / a path on host b1, not the VM's ephemeral disk).
|
|
Otherwise it's complexity without payoff. See DECISIONS.md "Phase 2pc". *Added:* 2026-05-29.
|