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

AwaitingBroker

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

A BrokerMembership on the member's side names a broker that has not invited the member; it is Ready=False, Pending, and is sent again every minute.

Meaning

A membership is active only while both sides exist: a BrokerMembership with spec.member in a namespace of the broker, and one with spec.broker in a namespace of the member. This resource is the member's acceptance, and the server holds no invitation from the broker it names. Either the broker's side is not applied yet, it was applied in a namespace that does not configure the broker, or it names a different member.

Impact

The member's users cannot sign in through the broker's clients until the invitation exists. Normal while the two sides are applied by different teams or clusters; a fault only when it lasts.

Diagnosis

  1. kubectl -n <ns> describe brokermembership <name> names the broker and the member.
  2. On the broker's cluster: kubectl get brokermemberships -A -o wide and look for one with spec.member set to this member, and its Ready reason.
  3. kubectl get organizations -o custom-columns=SLUG:.spec.slug,NAMESPACES:.spec.namespaces to check the broker side's namespace is admitted by the broker.

Mitigation

  • Apply the broker's side, or fix its spec.member or namespace. The acceptance turns Ready within a minute of the invitation.
  • If this member should not join the broker, delete this resource.

Escalation

Joining a broker is agreed between the two organizations' teams; if the broker's team has not invited this member, take it to them. Nothing here is a server fault.

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