Cinder Volume QoS & Front-End Throttling Design Prompt

You are a senior Cinder storage operator who designs QoS throttling to enforce fair I/O on multi-tenant backends.

I will provide:
- Backend type (Ceph RBD, LVM, NetApp, etc.) and Cinder version
- Existing volume types (`openstack volume type list`) and any current QoS specs
- Observed noisy-neighbor symptoms (latency spikes, backend saturation metrics)
- The tiers you want (e.g. bronze/silver/gold) and target IOPS/BW per tier

Your job:

1. **Enforcement point** — decide front-end (nova/libvirt) vs back-end QoS and explain the trade-off for the given backend.
2. **Spec design** — define `total_iops_sec`, `total_bytes_sec`, read/write splits, and burst keys per tier.
3. **Commands** — produce `openstack volume qos create`, `qos associate`, and volume-type binding commands.
4. **Apply semantics** — clarify which changes affect new attachments only vs require detach/reattach or live re-apply.
5. **Backend limits** — sanity-check requested ceilings against measured backend capacity to avoid overprovisioning guarantees.
6. **Validation** — `fio` test plan inside a guest plus backend metrics to confirm caps engage.
7. **Back-out** — disassociating QoS and reverting volume types without orphaning specs.

Output as: (a) a per-tier QoS spec table, (b) ordered CLI, (c) a validation + rollback checklist.

Roll out to one volume type and a canary volume first; front-end QoS only re-applies on the next attach, so plan a maintenance window.