Repository navigation
Conversation
🦋 Changeset detectedLatest commit: 622e2ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
da7ac54 to
df40b32
Compare
Document post-image update steps for single-relay and HAProxy stacks; link deploy README to the runbook without duplicating health/HAProxy setup.
df40b32 to
4baf9b9
Compare
|
Capture the running relay image before deploy, document script install path, use compose exit-code-from for migrate, and add SKIP_MIGRATE for rollback.
| HAProxy: run migrate only when moving **forward** on a new image. For rollback, | ||
| retag the old image to `:main`, then replace relays with | ||
| `rolling-relay-recreate.sh` (it does not re-run `nostream-migrate`). |
There was a problem hiding this comment.
Rollback cannot restore stopped green
If nostream-green fails after replacement, these instructions tell the operator to stop it and run rolling-relay-recreate.sh. The script starts with the still-running nostream-blue and exits because its peer is stopped. Neither backend gets restored.
Document how to recreate the stopped backend on the old image first, then replace the other backend.
| ## Shared steps (both stacks) | ||
|
|
||
| ### 1. Refresh release-managed files (when release notes say so) | ||
|
|
||
| ```bash | ||
| ./deploy/bootstrap.sh /opt/nostream | ||
| ``` |
There was a problem hiding this comment.
The shared refresh step tells both stacks to run bootstrap.sh, but that script only copies the single-relay Compose file and postgresql.conf. It does not refresh docker-compose.haproxy.yml, rolling-relay-recreate.sh, or the HAProxy files.
If a release changes those files, an HAProxy host keeps the old copies despite following this step. Add separate HAProxy refresh commands so operators do not have to discover the missing steps themselves.
| if curl -sf "$READYZ_URL" >/dev/null; then | ||
| echo "ready: $READYZ_URL" | ||
| curl -s "$READYZ_URL" |
There was a problem hiding this comment.
Neither readiness request has a timeout. If the relay accepts a connection but never finishes responding, curl can wait indefinitely. READYZ_RETRIES cannot advance the loop, and the operator never gets the final failure diagnostics.
Add a request timeout to both readiness requests.
Description
Document the manual post-pull migrate and recreate flow, rollback steps, and /readyz verification. Closes the gap where the webhook pull stack loads images but does not restart the relay.
Related Issue
closes:- #767
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: