# 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.