-
Notifications
You must be signed in to change notification settings - Fork 77
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
kstatus does not accept booleans for conditions #596
Comments
That seems pretty non-standard. The convention is documented here: They're deliberately strings to allow for "Unknown". In this case, "Unknown" also helps improve the UX and error messages without having to hard code that nil means unknown. It's also a relatively common K8s convention to use string enums instead of booleans, to avoid needing to change the schema if you ever need to add a new enum value. I would recommend suggesting to keycloak that they follow the standard convention. That said, I'm not against adding an exception into kstatus for this weird edge case. But I consider it a feature request, not a bug. @justinsb what do you think? |
I also reported the issue on the Keycloak side as well: keycloak/keycloak#13074 Making kstatus more robust against probable variations in input would be good anyhow. |
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 |
The Kubernetes project currently lacks enough active 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 rotten |
I'd love to see either a fix on keycloak's side or this feature added to kstatus so my resources can play well together without a bunch of manual workarounds. If it helps grease the wheels of value here, Thanks. |
@karlkfi Tim suggested supporting both boolean and strings, I don't see how it really affects "Unknown". I mean, it even makes much more sense - why does it use "True"/"False" strings now, but doesn't support booleans? The check should probably be trivial:
|
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
Some resources use YAML booleans in their status conditions which are not interpreted by kstatus.
Kstatus should interpret both string and boolean representations for conditions.
For example the new Keycloak Operator uses booleans:
This leads to the resource never being considered reconciled by Flux.
The text was updated successfully, but these errors were encountered: