Replicove roadmap¶
The portable alpha implements a declarative workflow for disposable Kubernetes environments that reproduce selected tools and configuration. See project status for evidence and the full design for longer-term acceptance criteria. This roadmap is not a release-date promise.
Implemented portable alpha¶
| Area | Available implementation |
|---|---|
| Runtime | Pinned standalone Helm provisioning, persistent or lab control plane, existing-target registration, readiness and UID ownership |
| Discovery and plan | Administrator grants, bounded read-only capture, selected Helm provenance/resources, dependency order, mappings, overrides and manual approval |
| Replication | Guest resource reconstruction, explicit refresh, drift reporting, preserved experiments and refusal to adopt foreign resources |
| Secrets and access | Explicit snapshot/follow grants, expiring guest roles, exact-Secret reader permissions, revocation and reconnecting CLI tunnel |
| Cleanup | Guest and host ownership inventory, finalizer-aware deletion, bound-volume checks and real TTL/PVC cleanup tests |
| Workloads | Functional cert-manager, Spark Pi, Trino TPCH and native admission-policy scenarios |
| Compatibility | Kubernetes 1.35.8/1.36.4 hosts with a 1.36.0 guest; chart rendering separately checks 1.35–1.37 |
| Packaging and docs | Embedded operator chart, four CLI build targets, checksums, branding and a complete first-replica quickstart |
The original implementation checklists (#1–#5) are resolved with merged code and test evidence. The unfinished version-maintenance pipeline remains tracked in #6.
Implemented v0.3.0-alpha.1 scope¶
Version v0.3.0-alpha.1 extends that workflow. It adds read-only preflight and plan evidence; reusable test recipes with provenance/JUnit reports; destination pools and durable capacity admission; scoped PostgreSQL 17 copies with approved masks and table filters; six bounded chaos fault types; namespace-scoped stdio MCP; and a local read-only dashboard. All six CRDs share the operator, and database/chaos modules can be enabled later like mirrors. See the feature map for limits.
The validation record tracks local/API and disposable feature tests by exact source revision. The release workflow also requires exact-main CI and published-artifact verification. There is no dedicated GitHub Action integration. The MCP interface has no remote certificate/CA service, and PostgreSQL masks/subsets do not promise general anonymization or an inferred tenant boundary.
Runtime version maintenance¶
Before treating a profile as certified, finish immutable image-digest pins and provenance review, automated candidate schema/resource/RBAC comparison, and retained-profile upgrade/recovery tests. Existing live replicas must keep their resolved identity, guest version, TTL and desired values. Cleanup must remain possible without fetching a chart. The current chart checksum, contract tests, read-only upstream checker and live matrix are the foundation; the maintenance guide records the current manual process.
Release qualification¶
Every alpha requires its exact main revision to pass the complete source CI suite, followed by installation, upgrade and feature tests against its published binaries, images, charts and native YAML. The public scenario catalog is updated only to verified release assets; all documented variants must pass before their qualification is recorded. Keep those source, artifact and documentation-scenario run links distinct in validation. Separate signed attestations remain future work; OCI build metadata and checksums do not establish that claim.
Additional adapters¶
- Cloud identities: IRSA, EKS Pod Identity, Azure/GCP workload identity with authenticated exchange and revocation tests.
- Data: qualify the scoped PostgreSQL 17 path and cloud CSI drivers; add broader database engines/PITR, grouped-volume adapters, non-CSI transfer, and explicit external-resource cleanup only with matching ownership and recovery tests. The optional per-volume mirror implementation and its qualification scope are described in workload mirrors.
- vCluster Platform: qualified provisioning and lifecycle integration; current requests block without falling back to Helm.
- Operators: External Secrets backend recreation, lifecycle hooks, bootstrap cycles and additional behavior tests.
Production qualification¶
Add stronger host admission/network isolation guidance and tests, per-user gateway delegation, larger encrypted capture storage, scale and recovery coverage beyond the bounded shared-worker chaos implementation, distribution-specific admission/storage adapters, and external design-partner validation.
Kubernetes versions, served APIs and required capabilities are the core compatibility axes. EKS, AKS, GKE, OpenShift and RKE2 require separate evidence for their identity, storage, admission and networking behavior. Cloud labs are deferred; current validation uses disposable CI clusters.
Have a concrete test-environment problem? Describe it in Discussions or propose a feature.