Fork: 0
OpenStack / openstack-caracal-ipv4
Transfer to URL with SHA Find file
Newer
Older
openstack-caracal-ipv4 / docs / D-068-vault-1.8-vs-1.16-analysis.md
@JANeumatrix JANeumatrix 3 hours ago 7 KB Create D-068-vault-1.8-vs-1.16-analysis.md
Raw Blame History

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