rmq-generate-config

name	rmq-generate-config
description	Use when an operator needs to create or revise an rmq-vertical-scaler config.json — when they describe their RabbitMQ workload (queue depths, message rates, burst patterns, node count) and want scaling profiles, thresholds, and debounce settings chosen for them.

Generate an rmq-vertical-scaler config

Overview

The scaler is driven by a JSON config (validated against schema/config-schema.json) that the generate command turns into Kubernetes manifests. This skill interviews the operator about their workload and produces a valid config.

When to use

• "Help me set up / configure the RabbitMQ scaler"
• "What scaling profiles should I use for my workload?"
• They have an existing config and want it tuned for new traffic.

Do NOT use for deploying — that's rmq-deploy. This skill only produces the config file.

Interview first

Start from rmq-vertical-scaler init (writes my-config.json) instead of hand-copying a template when the CLI is available. Ask only what you can't infer. Map answers to config:

Ask	Drives
Typical vs peak queue depth (messages)?	queue thresholds
Typical vs peak publish/consume rate (msg/s)?	rate thresholds
How many RabbitMQ nodes? (need 3+ quorum)	safety warning if <3
How bursty? (steady / spiky)	debounce values
CPU/memory budget at idle vs peak?	profile cpu/memory
Namespace + RabbitMQ service name?	kubernetes, rmq.host

Config rules (must hold)

• profiles: keys must match ^[A-Z_]+$. Each needs cpu + memory. queue/rate optional.
• First profile is the floor — it gets NO queue/rate (idle baseline). Every other profile needs at least one threshold.
• Selection: engine scans highest profile to lowest, picks the first whose queue OR rate is exceeded. Order thresholds ascending across profiles.
• cpu: ^[0-9]+(\.[0-9]+)?(m)?$ (e.g. 330m, 2). memory: must end Mi/Gi/Ti (e.g. 2Gi).
• rmq.host = Kubernetes service DNS: <service>.<namespace>.svc.cluster.local. port default 15672.
• Bursty workloads → longer scaleDownSeconds (e.g. 300) so it doesn't thrash on dips.

Example output

{
  "$schema": "https://raw.githubusercontent.com/ferterahadi/rmq-vertical-scaler/master/schema/config-schema.json",
  "profiles": {
    "LOW":    { "cpu": "330m",  "memory": "2Gi" },
    "MEDIUM": { "cpu": "800m",  "memory": "3Gi", "queue": 2000,  "rate": 200 },
    "HIGH":   { "cpu": "1600m", "memory": "4Gi", "queue": 10000, "rate": 1000 },
    "CRITICAL": { "cpu": "2400m", "memory": "8Gi", "queue": 50000, "rate": 2000 }
  },
  "debounce": { "scaleUpSeconds": 30, "scaleDownSeconds": 120 },
  "checkInterval": 5,
  "rmq": { "host": "rabbitmq.production.svc.cluster.local", "port": "15672" },
  "kubernetes": { "namespace": "production", "rmqServiceName": "rabbitmq" }
}

Start from examples/template-config.json, basic-config.json, or production-config.json if available — adapt rather than build from scratch.

Validate before finishing

• Confirm it parses and matches the schema. Run rmq-vertical-scaler generate --config <file> -o /tmp/check.yaml (or the docker equivalent) — generate now enforces the schema (non-zero exit with a violation list), so a clean generate is authoritative.
• Warn loudly if node count <3 or single-node: scaling restarts cause message loss (README safety note).

Common mistakes

• Putting a threshold on the first (floor) profile → it should be unconditional.
• Thresholds not monotonically increasing → a lower profile shadows a higher one.
• memory without a unit suffix → fails schema validation.
• rmq.host set to a bare service name instead of the full cluster DNS.