/capacity

name: openstack-capacity
description: "OpenStack capacity planning operations skill for resource planning, quota management, and scaling decisions. Covers compute capacity (allocation ratios, vCPU/RAM utilization, host aggregates, availability zones), storage capacity (Cinder pool sizing, thin provisioning, Glance storage, Swift rings), network capacity (floating IP pools, port quotas, subnet sizing), project quota management (templates for small/medium/large profiles), flavor sizing strategy, utilization analysis with placement service, growth forecasting from historical metrics, and right-sizing recommendations for underutilized resources."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-23"
      triggers:
        intents:
          - "capacity"
          - "quota"
          - "scaling"
          - "resources"
          - "utilization"
          - "allocation ratio"
          - "flavor"
          - "sizing"
          - "growth"
          - "density"
        contexts:
          - "capacity planning"
          - "managing quotas"
          - "scaling openstack"
          - "resource utilization analysis"

OpenStack Capacity Planning -- Resource Management Operations

Capacity planning is proactive operations -- the discipline of preventing outages before they happen by ensuring the cloud has sufficient resources to serve its users. A reactive operator discovers capacity problems when `openstack server create` returns "No valid host found." A proactive operator sees the trend weeks before and plans accordingly.

The three capacity domains are **compute** (vCPU, RAM, local disk), **storage** (volume GB, snapshots, images, objects), and **network** (floating IPs, ports, subnets, bandwidth). Each domain has its own exhaustion symptoms, its own metrics, and its own expansion procedures.

Allocation ratios create overcommit flexibility -- a host with 16 physical cores and a 4:1 CPU allocation ratio offers 64 vCPUs. This works because most workloads are idle most of the time. The art of capacity planning is setting ratios high enough to maximize density but low enough that contention does not degrade performance.

This skill maps to NASA SE Phase E sustainment and resource management. In NASA terms, capacity planning is the operational activity that ensures the system continues to meet its Measures of Performance (MOPs) throughout its operational life.

Deploy

Capacity Management Tooling

**Placement service** -- the authoritative source for resource inventory:

# List all resource providers (one per compute node)
openstack resource provider list

# Show resource inventory for a specific provider
openstack resource provider inventory list <provider-uuid>
# Shows: VCPU, MEMORY_MB, DISK_GB with total, reserved, min_unit, max_unit, allocation_ratio

# Show current allocations (what is consumed)
openstack resource provider usage show <provider-uuid>

**Quota system** -- per-project resource limits:

# Show default quotas
openstack quota show --default

# Show quotas for a specific project
openstack quota show <project-name>

**Allocation ratios** (in `globals.yml`):

# Compute overcommit ratios
nova_cpu_allocation_ratio: 4.0     # 4 vCPUs per physical core
nova_ram_allocation_ratio: 1.5     # 1.5x physical RAM
nova_disk_allocation_ratio: 1.0    # No disk overcommit (recommended)

# These translate to placement inventories:
# VCPU: total = cores * ratio
# MEMORY_MB: total = ram_mb * ratio
# DISK_GB: total = disk_gb * ratio

**Initial resource survey** -- baseline capacity before entering operations:

# Compute capacity
openstack hypervisor stats show
# Key fields: vcpus, vcpus_used, memory_mb, memory_mb_used, local_gb, local_gb_used

# Storage capacity
openstack volume service list
cinder get-pools --detail  # Shows per-backend capacity

# Network capacity
openstack floating ip list --long  # Count used vs available
openstack network list             # Count networks

Configure

Compute Capacity

**Allocation ratios** -- when to overcommit vs reserve:

| Workload Type | CPU Ratio | RAM Ratio | Rationale | |---------------|-----------|-----------|-----------| | Dev/test | 8:1 to 16:1 | 1.5:1 | Workloads mostly idle, density matters | | Web servers | 4:1 to 8:1 | 1.0:1 | CPU bursty, RAM steady-state | | Databases | 1:1 to 2:1 | 1.0:1 | CPU and RAM sensitive to contention | | HPC / ML | 1:1 | 1.0:1 | No overcommit; dedicated resources |

**Host aggregates** for workload separation:

# Create host aggregates for different workload types
openstack aggregate create --zone general-az general-compute
openstack aggregate create --zone database-az database-compute

# Add hosts to aggregates
openstack aggregate add host general-compute compute01
openstack aggregate add host database-compute compute02

# Set metadata for flavor targeting
openstack aggregate set --property workload=general general-compute
openstack aggregate set --property workload=database database-compute

**Availability zones** for fault domain separation:

# List availability zones
openstack availability zone list --compute

Storage Capacity

**Cinder backend pool sizing:**

# Check backend pool capacity
cinder get-pools --detail
# Key fields: total_capacity_gb, free_capacity_gb, provisioned_capacity_gb
# provisioned_capacity_gb can exceed total_capacity_gb with thin provisioning

**Thin provisioning ratios:**

# In Cinder backend config (LVM example)
# lvm_max_over_subscription_ratio: 1.5  # Allow 50% overcommit
# Thin provisioning only works with LVM thin pools or Ceph

**Glance storage limits:**

# Check image storage usage
openstack image list --long -c Name -c Size
# Sum all image sizes; compare against storage backend capacity
# Images are stored in /var/lib/glance/images/ (default) or Swift

**Swift ring siz