# AwaitingBroker

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](https://www.nauthera.io/docs/v1/runbooks/operator) · Generated from [`operator/internal/runbook/conditions.yaml`](https://github.com/nauthera/nauthera-server/blob/main/operator/internal/runbook/conditions.yaml) in nauthera-server.