-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"good" state for ListenerStatus feels logically inverted, difficult to understand #1110
Comments
Agreed, we should have the same |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
GEP-1364 has been approved, deprecating This GEP also addresses the confusion with the |
What would you like to be added:
ListenerConditionType
Attached
(or possiblyAccepted
for parity with other objects, ref discrepancies between Accepted, Ready, and Detached condition types and reasons #1111 ), deprecateDetached
Why this is needed:
From a quick glance, seeing a
ListenerStatus
withDetached
andConflicted
conditions on a Gateway can be a red herring leading an operator to initially think aListener
is 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
ListenerStatus
field being a child ofGatewayStatus
rather than being astatus
field directly onListener
.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.The text was updated successfully, but these errors were encountered: