| name | rmq-upgrade-from-v1 |
| description | Use when an operator is running the Node.js v1 rmq-vertical-scaler and wants to move to the Go v2 — confirming the drop-in image-tag swap, env-var parity, and that scaling decisions and generated manifests stay identical. |
Upgrade rmq-vertical-scaler v1 → v2
Overview
v2 is a behaviour-identical Go rewrite of the Node.js v1: same env-var contract, byte-identical scaling decisions, byte-for-byte compatible generated manifests. The upgrade is a drop-in image-tag swap — no config or manifest changes required.
When to use
- "Upgrade the RabbitMQ scaler to v2 / Go version"
- "Is v2 safe to roll out?"
- They're on
ferterahadi/rmq-vertical-scaler:1.x.
The upgrade (existing Deployment)
Just change the image tag:
kubectl set image deployment/rmq-vertical-scaler \
rmq-vertical-scaler=ferterahadi/rmq-vertical-scaler:2 -n <ns>
kubectl rollout status deployment/rmq-vertical-scaler -n <ns>
A Deployment generated by v1 drives v2 unchanged — the env-var contract is identical.
Why it's safe
- Same env vars —
RMQ_*, PROFILE_*, QUEUE_THRESHOLD_*, RATE_THRESHOLD_*, DEBOUNCE_*, CHECK_INTERVAL_SECONDS, NAMESPACE, CONFIG_MAP_NAME.
- Same decisions — engine makes byte-identical scaling choices given the same metrics + config (enforced by a parity test).
- Same manifests —
generate emits YAML byte-for-byte compatible with v1; existing examples/*.json configs work as-is.
- Smaller footprint — distroless static binary, ~10–15 MB idle RSS vs Node's ~50–80 MB.
Verify after rollout
kubectl logs deployment/rmq-vertical-scaler -n <ns> --tail=50
Confirm it reports the same current profile it held on v1 — the state ConfigMap (rmq-vertical-scaler-config) carries over, so there should be no spurious scale event.
Rollback
v1 stays published — revert the tag:
kubectl set image deployment/rmq-vertical-scaler \
rmq-vertical-scaler=ferterahadi/rmq-vertical-scaler:1 -n <ns>
v1.x images and v1.x git tags remain available.
Common mistakes
- Regenerating manifests "to be safe" and diffing against a hand-edited v1 Deployment — unnecessary; the tag swap is enough.
- Pinning
:latest instead of :2 — pin a major to avoid surprise jumps.
