Major Feature Request Overview
Introduce a project-scoped Key/Value “Parameter Store” for OpenStack that mirrors the core semantics customers rely on in AWS SSM Parameter Store: hierarchical paths, typed values (String, StringList, SecureString), versioning, labels/aliases, atomic updates (CAS) and short-TTL locks, and high-throughput, low-latency reads/writes. Secure values should leverage Barbican/Castellan for crypto and backends (Vault/KMIP/HSM) without requiring every parameter to be modeled as an individual Barbican secret. This is distinct from Nova’s instance metadata (per-instance scope) and fills the gap of project-level configuration.
Business justification
- Cloud-parity & migration velocity: Hyperscaler users expect an account/project-level parameter store; lacking this forces ad-hoc use of Barbican or external KVs and slows migrations to RHOSO.
- Operational safety: Versioned parameters, labels, and CAS/locks enable safe rollouts/rollbacks and eliminate multi-writer races—behavior teams already use with Parameter Store or Vault KV v2.
- Performance transparency: Set clear, documented throughput goals to support distributed apps at scale (use AWS’s published higher-throughput guidance as a directional target).
- Security posture: Use Barbican/Castellan for key management and optional Vault/KMIP/HSM backends; keep plaintext configs encrypted at rest and enforce Keystone-scoped RBAC.
- Right abstraction: Barbican is a secrets manager (CRUD of secrets/keys/certs) rather than a hierarchical KV with list-by-path and optimistic concurrency; overloading it degrades usability and scale.
Functional requirements
Model & Scope
- Namespaces: ** /{domain}/{project}/[app]/[env]/key with list-by-path/prefix. Default scope = project; SRBAC for cross-project read/share.
- Types: String, StringList, SecureString, and bounded JSON. SecureString encrypted via Barbican/Castellan (optionally backed by Vault/KMIP/HSM).
- Versioning & labels: Every update creates an immutable version; support reads by version or label (e.g., current, blue, green).
- Concurrency & safety: CAS (match on current version) + short-TTL locks/leases for “single-writer at a time” updates; batch GET and by-path GET. (Mirror Vault KV v2 CAS semantics.
- Performance SLOs (per region): Documented envelope targeting ≥ 5k read TPS and ≥ 1k write TPS (p99 read < 50 ms), with stretch goal aligned to AWS “higher throughput” order of magnitude.
- Quotas/limits: Per-project caps on parameter count, value size, and request rate; explicit throttle responses and guidance similar to AWS docs.
- Audit & security: TLS in transit; encryption at rest for all data; per-operation audit trails; Keystone SRBAC on paths; SecureString key lifecycles via Barbican/Castellan.
- APIs & tooling: REST API + SDK/CLI: put-parameter (with CAS), get-parameter(s), get-by-path, label, history, delete, acquire/release-lock. Native consumers in Heat, Ansible, cloud-init/user-data. (Note: Nova metadata remains instance-scoped and out of scope for project KV.)
- Availability/consistency: Multi-AZ quorum replication; strongly consistent writes/reads within region.
Backend
- Primary: New microservice backed by a strongly consistent store (e.g., etcd or PostgreSQL+row locks/JSONB), fronted by Keystone.
- Secure values path: Store SecureString payloads in Barbican; store non-secret values in the KV datastore to avoid Barbican bloat/HSM bottlenecks.
- If Barbican alone isn’t sufficient: Support Vault KV v2 as an alternative backend via existing Barbican/Vault integration patterns to inherit versioning & CAS.
Describe the customer impact
- Simplified architecture: One OpenStack-native endpoint for configs and secrets; no more misusing Barbican for thousands of micro-secrets or grafting third-party KV just to ship app settings.
- Safer, faster rollouts: Versioned params, labels, and CAS reduce outages from config races; easy rollbacks are first-class.
- Clear scaling story: Published throughput and limits prevent “surprise throttles” seen when leaning on the wrong subsystem. AWS’s 10k TPS precedent sets expectations for high-scale designs.
- Security & compliance: Secrets remain under Barbican/Castellan/Vault management with auditable access and SRBAC; plaintext configs still encrypted at rest.
Point of contact