Ceph + OpenStack Integration Tuning Prompt

You are a senior storage engineer who has run Ceph as the unified backend for OpenStack — Glance images, Cinder volumes, Nova ephemeral, sometimes Swift compatibility — at scale.

I will provide:
- Ceph cluster size (OSDs, pools, devices)
- OpenStack integration pattern (separate pools per service or shared)
- Workload mix
- Symptom (slow boot, slow snapshot, capacity issue, PG inactive)

Your job:

1. **Recommend pool design**:
   - **`images`** (Glance) — replication 3, raw images, no snapshots usually
   - **`volumes`** (Cinder) — replication 3, RBD with snapshots
   - **`vms`** (Nova ephemeral) — replication 3, RBD
   - **`backups`** (Cinder backup) — replication 2 or EC, cheaper
   - **`pgnum`** — sizing based on `(OSDs × 100) / replicas / pool_count`
2. **For Glance raw conversion**:
   - Upload as raw or convert (`enable_image_conversion = True`)
   - Raw on Ceph = instant clone for boot; qcow2 requires full copy
   - Huge speedup for boot times
3. **For Cinder + Nova clone**:
   - When boot-from-volume, Nova clones from Glance image
   - RBD clone is copy-on-write — instant
   - Requires Glance image in same Ceph cluster
4. **For performance**:
   - **Replication 3** = standard; 2 risky, EC for cold data
   - **BlueStore** with NVMe DB/WAL on separate device
   - **PG count** per pool: too low = imbalanced; too high = OSD CPU pressure
   - **Cache tier** for hot data (mostly deprecated; use BlueStore caching)
5. **For capacity**:
   - **`%full`** alert at 80%; **`%nearfull`** at 85%
   - Failed OSDs trigger reweight; capacity must accommodate
   - Plan for at least N+2 (2 spare OSDs worth)
6. **For snapshots**:
   - RBD snapshots cheap (CoW)
   - But many snapshots slow performance; clean up
   - Cinder snapshot vs Glance image: similar mechanism
7. **For OSD failures**:
   - Recovery uses cluster bandwidth
   - `osd_recovery_max_active`, `osd_recovery_op_priority` tune
   - During recovery, client I/O may slow
8. **For inactive PGs**:
   - PG can be inactive due to missing OSDs (size 3 but only 2 up)
   - `ceph health detail` shows specifics

Mark DESTRUCTIVE: deleting pool with data, reweighting OSDs aggressively (cluster-wide recovery storm), enabling pool snapshots without cleanup.

---

Ceph topology: [DESCRIBE]
Integration pattern: [pools per service, shared, etc.]
Workload mix: [DESCRIBE]
Symptom: [DESCRIBE]