diff --git a/docs/D-068-vault-1.8-vs-1.16-analysis.md b/docs/D-068-vault-1.8-vs-1.16-analysis.md new file mode 100644 index 0000000..7c8b402 --- /dev/null +++ b/docs/D-068-vault-1.8-vs-1.16-analysis.md @@ -0,0 +1,114 @@ +# D-068 evidence: Vault charm 1.8 (reactive) vs 1.15+/1.16 (operator) -- viability analysis + +**Backs:** D-068 item 1 ("Vault version"). **Type:** research / decision evidence. **Date:** 2026-07-05. +**Scope:** research only -- no bundle or live-deployment change is made by this document. + +## Why this exists + +D-068 item 1 recorded that live Vault is **1.8.8 (charm `1.8/stable`) -- EOL**, and that `bundle.yaml` +was pinned to **`1.16/stable`** this session as a deliberate forward-pin toward escaping that EOL +software, noting the move would be "a MAJOR operation ... rehearse before applying live." + +This analysis evaluates whether that `1.16` forward-pin is **viable** for this deployment. **Finding: +it is not a "hard upgrade" -- it is a largely-incompatible different charm.** The pin should revert to +`1.8/stable` for any deployable bundle (v1 / Roosevelt initial deploy), and the "get off EOL 1.8" +problem remains **open under D-068 with `1.16` ruled out as the path**. + +Note: an earlier bundle-version sweep mischaracterized the `1.16` pin as a Bobcat "holdover." That was +wrong -- it is a deliberate D-068 forward-pin. The technical conclusion (a deployable bundle must be +`1.8/stable`) is unchanged and is strengthened below. + +## The tension (neither option is clean) + +| | `1.8/stable` (installed) | `1.16/stable` (bundle forward-pin) | +|---|---|---| +| Integration with this reactive cloud | **compatible, working** | **incompatible** (see below) | +| Upstream maintenance | **EOL** (no security patches) | maintained | +| Licensing (Vault payload) | MPL 2.0 | **BUSL 1.1** (commercial review needed) | +| Move path from current state | already here | **no upgrade path** (rebuild + restore) | + +So the choice is compatible-but-EOL vs maintained-but-incompatible. For a *deployable* bundle, only +`1.8/stable` produces a working cloud today; EOL is a technical-debt / risk-acceptance item to carry. + +## The ripple surface (measured from bundle.yaml) + +Vault is the cloud-wide CA + barbican's secret backend -- 22 relations: +- **18x `vault:certificates`** (keystone, glance, glance-simplestreams-sync, nova-cloud-controller, + placement, neutron-api, neutron-api-plugin-ovn, ovn-central, ovn-chassis, ovn-chassis-octavia, + cinder, ceph-radosgw, openstack-dashboard, octavia, barbican, barbican-vault, magnum, + mysql-innodb-cluster) -- vault issues every service's TLS cert. +- **`barbican-vault:secrets-storage -> vault:secrets`** -- barbican's KV backend (the D-067 path). +- **`vault:shared-db -> vault-mysql-router -> mysql-innodb-cluster`** -- vault's storage backend. + +## Why 1.16 is incompatible, not just hard (Canonical's own "key differences" doc) + +Source: Canonical, "Key differences between vault-operator 1.8 and 1.15" (Charmhub Discourse). "1.16" +conflates a **charm rewrite** (reactive -> ops operator) and a **Vault software jump** (1.8.x -> 1.16.x). +The rewrite brings, for this reactive cloud: + +1. **Certificates interface V0 -> V1 [SHOWSTOPPER].** The new charm "implements the provider side of + the TLS Certificates Integration **V1** instead of **V0**." The reactive OpenStack service charms + are **V0 requirers**; the current Caracal charm-guide TLS page documents the V0 workflow + (`vault:certificates` + `generate-root-ca`/`reissue-certificates`/`get-csr` actions). A V0 requirer + cannot bind a V1-only provider -> **all 18 cert relations fail to connect -> no service gets a TLS + cert.** That is the cloud's entire HTTPS/OS_CACERT trust chain. +2. **Storage Raft-only [HIGH].** The new charm drops non-Raft backends. This deployment's vault stores + state in **MySQL** (`vault-mysql-router` -> `mysql-innodb-cluster`). Those three relations become + invalid; vault would need Raft + multiple units for HA (vs the current single-unit + MySQL model). +3. **Barbican vault-kv [HIGH].** The `secrets-storage` path (D-067 / BUNDLEFIX-007) would need + re-validation/rework; the new charm reorganises secret engines and community reports secrets + integrations not working (below). +4. **No upgrade path [HIGH].** "Upgrading from 1.8 to 1.15 is not supported" -- it is back-up-on-1.8, + restore-on-a-new-1.15-deployment: a CA-replacement migration with an all-services cert re-issue + window, not a `juju refresh`. +5. **Community-reported broken with THIS stack [HIGH].** The same Canonical thread (2025-07) notes + "New Charmed Vault + Charmed Ceph is not working for LUKS encryption" and "... Charmed Kubernetes is + not working for secrets management." **This deployment uses Ceph.** +6. **Other:** Loadbalancer integration removed; explicit snap-channel selection removed; different + unseal model (manual `vault operator init` / auto-unseal root Vault, vs the D-069 second-person + flow). Additions (intermediate-CA, auto-unseal, S3 backup/restore, COS, UI) are real but do not + offset 1-5 for a reactive cloud. + +## Licensing (commercial consideration) [FLAG -- not legal advice] + +Vault **1.15+** ships under HashiCorp **BUSL 1.1** (a change from **MPL 2.0** at <=1.14). For a +commercial multi-tenant cloud this is a material review item; **OpenBao** is the MPL-continuation fork. +The `1.8/stable` payload predates the change (MPL). Verify current terms with legal; not a conclusion +asserted here. + +## What a move to the new vault would actually require (migration cost) + +Not a channel edit -- a project: (1) confirm the Caracal service charms can be **tls-certificates V1** +requirers (today: V0 only -> if they cannot, the new vault CANNOT be the cloud CA without +re-architecting TLS); (2) re-model storage to Raft + multi-unit HA, drop `vault-mysql-router`; +(3) re-validate/rework barbican vault-kv; (4) resolve new-vault + Charmed-Ceph breakage; (5) plan a +backup/restore CA migration + cloud-wide cert re-issue window; (6) review BUSL licensing. + +## Decision (proposed as a D-068 amendment) + +- **Pin the bundle vault charm at `1.8/stable`** (the reactive, integration-compatible charm). A + deployable v1 / Roosevelt-initial bundle MUST be `1.8/stable`; `1.16/stable` would break the deploy + (no certs). This reverts the D-068 forward-pin in the bundle. +- **Rule `1.16` OUT as the vault-modernization path** for this reactive cloud, on the incompatibility + evidence above -- unless/until the OpenStack service charms gain tls-certificates V1 support. +- **Keep "get off EOL 1.8" OPEN under D-068** as a Roosevelt-durability problem. Candidate paths to + evaluate (none adopted here): (a) wait for OpenStack reactive charms to support tls-certificates V1, + then re-assess the new vault; (b) **OpenBao** (MPL fork) if it preserves a compatible interface; + (c) explicit **EOL risk-acceptance** for the VR0 rehearsal phase with a defined remediation deadline + for production. This is an operator/security call, recorded as open -- not resolved by this document. + +## Verify-live (pre-flight, before trusting any of the above) + +- `juju info --series jammy vault` -- confirm `1.8/stable` exists, publisher OpenStack Charmers, + provides `certificates`. +- Confirm the Caracal service charms' `certificates` requirer interface version (expected V0). +- Track the vault EOL / OpenStack V1-support situation for when the modernization can be revisited. + +## Sources +- Canonical, "Key differences between vault-operator 1.8 and 1.15": + https://discourse.charmhub.io/t/the-key-differences-between-vault-operator-version-1-8-and-1-15/15169 +- Vault Charms documentation (new operator): https://canonical-vault-charms.readthedocs-hosted.com/en/latest/ +- OpenStack charm-guide, Managing TLS certificates (Caracal, V0 workflow): + https://docs.openstack.org/charm-guide/latest/admin/security/tls.html +- Charmhub vault ("1.15+ fundamentally different"): https://charmhub.io/vault +- HashiCorp BUSL relicense (2023) -- verify current terms with legal.