Skip to content
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

Closed
mikemorris opened this issue Apr 13, 2022 · 4 comments · Fixed by #1446
Closed
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@mikemorris
Copy link
Contributor

mikemorris commented Apr 13, 2022

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.

@youngnick
Copy link
Contributor

Agreed, we should have the same Attached condition type across every place we use conditions, and have it mean the same thing.

@k8s-triage-robot
Copy link

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:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 26, 2022
@youngnick
Copy link
Contributor

/remove-lifecycle stale

@mikemorris
Copy link
Contributor Author

GEP-1364 has been approved, deprecating ListenerConditionDetached and proposing that ListenerConditionAccepted be used instead.

This GEP also addresses the confusion with the Conflicted status by setting an expectation that positive polarity error status conditions should only be present when the error state exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants