Unsupported
Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program
The server serves a control-plane contract outside the operator's range; the operator's pod is not ready, and a resource it reconciles is Ready=False, Pending.
Meaning
The probe got an answer, and the server's control-plane contract is older or newer than the
range this operator works with. The message names the server's version and contract, the
operator's version and range, and which side to upgrade. Nothing is written to such a
server, since an older one would ignore fields it does not know rather than refuse them.
An OIDCClient taking its secret from spec.secret.secretRef reports it alone, with the
pod ready, when the server is in range but older than contract 8, the first that takes a
supplied secret: an older one would register the client without it.
Impact
No manifest is applied, no secret is delivered and no deletion under Delete completes
until the versions agree. Registered clients keep working for their applications and end
users. It usually follows an upgrade of one side without the other.
Diagnosis
kubectl -n <ns> describe oidcclient <name>for both versions and the side to upgrade.kubectl -n <release-ns> exec deploy/prints the supported range.<release>-operator -- / nauthera-operator --version kubectl -n <release-ns> get deploy -o widefor the server and operator images.
Mitigation
- Upgrade the side the message names: the server first when it is too old, the operator first when the server is newer. Both ends of one chart release support the same contract.
- Pin
operator.image.tagand the server'simage.tagto the same release. Resources are sent again within five minutes, or on the next probe that finds the server changed.
Escalation
Escalate to whoever runs upgrades of the release. If both ends come from the same release
and still disagree, open an issue with both --version outputs and the condition message.
Operator failure reasons · Generated from operator/ in nauthera-server.