What would you like to be added:
Why this is needed:
From a quick glance, seeing a ListenerStatus with Detached and Conflicted conditions on a Gateway can be a red herring leading an operator to initially think a Listener is not working properly - this may be particularly confusing for new users unfamiliar with checking for the "negative" case of Detached: {status: false, reason: Attached}, Conflicted: {status: false, reason: NoConflicts} meaning that the Listener is actually in a "good" state.
This potential confusion about whether a Listener is working as expected is slightly exacerbated by the ListenerStatus field being a child of GatewayStatus rather than being a status field directly on Listener.
I initially considered if Conflicted should be changed too, but I think just this change alone could make the status conditions for a Listener feel a bit more intuitve.
What would you like to be added:
ListenerConditionTypeAttached(or possiblyAcceptedfor parity with other objects, ref discrepancies between Accepted, Ready, and Detached condition types and reasons #1111 ), deprecateDetachedWhy this is needed:
From a quick glance, seeing a
ListenerStatuswithDetachedandConflictedconditions on a Gateway can be a red herring leading an operator to initially think aListeneris not working properly - this may be particularly confusing for new users unfamiliar with checking for the "negative" case ofDetached: {status: false, reason: Attached},Conflicted: {status: false, reason: NoConflicts}meaning that the Listener is actually in a "good" state.This potential confusion about whether a Listener is working as expected is slightly exacerbated by the
ListenerStatusfield being a child ofGatewayStatusrather than being astatusfield directly onListener.I initially considered if
Conflictedshould be changed too, but I think just this change alone could make the status conditions for a Listener feel a bit more intuitve.