kstatus does not accept booleans for conditions

[tim-jagenberg-piscada]

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:

status:
  conditions:
    - message: ''
      status: true
      type: Ready
    - message: ''
      status: false
      type: HasErrors
    - message: ''
      status: false
      type: RollingUpdate

This leads to the resource never being considered reconciled by Flux.

[karlkfi]

That seems pretty non-standard. The convention is documented here: https://github.com/zecke/Kubernetes/blob/master/docs/devel/api-conventions.md#typical-status-properties

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?

[tim-jagenberg-piscada]

I also reported the issue on the Keycloak side as well: https://github.com/keycloak/keycloak/issues/13074

Making kstatus more robust against probable variations in input would be good anyhow.

[k8s-triage-robot]

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-triage-robot]

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:

• 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 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 rotten

[thezanke]

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, eksctl is the official AWS-suggested way to spin up new EKS clusters. Also, eksctl now ships with partial support for setting up GitOps with Flux2 out of the box; so you'll only be hearing/seeing more of this from EKS users.

Thanks.

[nick4fake]

@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:

• If bool: return status ? "True" : "False"
• else return status

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted