mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-10 14:34:58 +09:00
Aleksei Sviridkin
eb4abc8d93
TLS was enabled automatically whenever external was true. In this operator TLS is not additive — the rendered config sets port 0 and moves the listener to tls-port — so that inference turned every already-running externally-reachable Redis into a TLS-only server on its first reconcile after the upgrade and cut every plaintext client with it. A platform upgrade must not sever working connections. Resolve tls.enabled to false when unset, whatever external says. Enabling TLS becomes an explicit act at creation time, and existing releases keep the behaviour they have today. Creation time, not any time: a running instance cannot change mode. A replica restarted onto the TLS listener cannot replicate from a master still on plaintext, and Sentinels already on TLS would fail over to a stale replica, so the operator's RedisFailover schema rejects a change of tls.enabled and the HelmRelease upgrade fails while the instance keeps serving what it served before. The README says so and points at creating a new instance and migrating. Pin the decision directly: external: true on its own now has to leave the cert-manager chain unrendered, the operator without spec.tls, and the tenant without TLS secrets. Every case that previously reached TLS through external says enabled: true instead, and the null and empty-map forms resolve to off alongside the unset one. With nothing inferred there is no upgrade-time behaviour change left, so the breaking-change marker and footer are gone from this branch. Say how to get out of it as well. The cozystack Redis API accepts the change, so the rejection lands on the HelmRelease, and every later edit to that instance queues behind the failure until tls.enabled goes back to what it was. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <f@lex.la>