rmq-upgrade-from-v1

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.