Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

OrganizationChanged

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

A namespaced resource is held by the server in one organization and its namespace now configures another; it is Ready=False, Error, and nothing is sent.

Meaning

The resource's status.organization records the organization the server holds it in. Since then the Organizations' spec.namespaces changed so that the namespace now configures a different one. The server keys the resource by its organization and does not move it, so the operator refuses rather than write it elsewhere.

Impact

The resource stays as the server last held it in its first organization, and changes to the manifest are not applied.

Diagnosis

  1. kubectl -n <ns> get oidcclient <name> -o jsonpath='{.status.organization}' is where it is held.
  2. kubectl get organizations -o custom-columns=NAME:.metadata.name,SLUG:.spec.slug,NAMESPACES:.spec.namespaces shows which organizations admit the namespace now.

Mitigation

  • If the change was meant to move the resource, delete it (its deletion policy decides what happens to the server's copy) and apply it again.
  • If not, restore the namespace to the organization that held it, or set spec.organization to it on a recreated resource.

Escalation

An unexpected change of the organization a namespace configures is a change to tenant boundaries; involve the platform team and check the cluster's audit log for who edited the Organizations.

Operator failure reasons · Generated from operator/internal/runbook/conditions.yaml in nauthera-server.