Confirmed live: /var/log/tinode.log-only redirection meant Loki never
received a single real tinode runtime log line (election, rehash,
connection, error output) since the container started -- Promtail
collects standard container stdout/stderr, not files written inside
the container. Every Pod's collected log was just this script's own
"NO_DB_INIT=true: skipping..." init line, nothing from tinode itself.
Now more consequential with native Cluster enabled: failover/rehash
state transitions were completely invisible to the normal Grafana/Loki
monitoring path, visible only via manual kubectl exec.
tee mirrors to both stdout (collected) and the file (still readable via
kubectl exec). PIPESTATUS[0] is required since a bare $? after a pipe
would report tee's exit status, not tinode's -- which also let this
drop the now-redundant "tail last 200 lines to stderr on crash" block,
since the full live stream already went to stdout throughout the run.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
StatefulSet's RollingUpdate replaces Pods one at a time in strict
sequence (unlike a Deployment, and unaffected by podManagementPolicy:
Parallel, which only governs initial scale-up/down) -- confirmed live:
run #152 restarted correctly (2/3 pods updated, then the 3rd) but hit
the old 120s ceiling before the last pod turned Ready, so CI reported
"failure" for a rollout that actually completed successfully seconds
later. 300s gives enough headroom for three sequential pod cycles
(image pull + start + native-Cluster rejoin) instead of tuning it to
the exact observed timing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
im-server moved from Deployment to StatefulSet in im-deploy-config
(native Cluster enablement) -- this workflow's kubectl commands still
targeted the old resource type, so every deploy since the migration
failed at the final step with "deployments.apps im-server not found"
(image built/pushed fine, just never got rolled out).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Old VM's blue-green im-server is decommissioned. App config
(MySQL/Redis/API key/admin-internal secrets) now lives in the
cluster's own Deployment manifest, not injected through CI --
this workflow's job is just build (from source, via
docker/tinode/Dockerfile.build as before), push under :test,
and roll the deployment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Your Name