メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when an operator wants to install or deploy the rmq-vertical-scaler into a Kubernetes cluster — generating manifests from a config, ensuring the RabbitMQ credentials secret exists, applying with kubectl, and verifying the rollout.
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.
Use when a deployed rmq-vertical-scaler isn't behaving — it's not scaling RabbitMQ up or down, the pod is crashing or CrashLooping, it can't reach the RabbitMQ management API, or it logs RBAC/permission/secret errors.
| 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. |
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.
ferterahadi/rmq-vertical-scaler:1.x.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.
RMQ_*, PROFILE_*, QUEUE_THRESHOLD_*, RATE_THRESHOLD_*, DEBOUNCE_*, CHECK_INTERVAL_SECONDS, NAMESPACE, CONFIG_MAP_NAME.generate emits YAML byte-for-byte compatible with v1; existing examples/*.json configs work as-is.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.
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.
:latest instead of :2 — pin a major to avoid surprise jumps.