[Explore]: Ready status condition on all Korifi objects
#2098
Labels
Comments
danail-branekov
added a commit
that referenced
this issue
May 27, 2024
The `Ready` status condition is becoming the standard for Korifi resources, therefore let's get rid of the `Valid` and `Invalid` conditions in favour of the `Ready` one. Thus the CFRoute status reconciliation code could be significantly simplified as we already have the readyConditionBuilder utility in place. Noone seems to care about `Valid`/`Invalid` status conditions, noone cares about the `Ready` condition as well. However, having a standard `Ready` condition is good (see #2098) While being here, `CFRoute.Status.Description` and `CFRoute.Status.CurrentStatus` are removed (as again, noone cares) - hopefully this is not an incompatible change. If anyone ever gets interested whether the route is OK, they should check the `Ready` condition instead. issue: #3304
tcdowney
pushed a commit
that referenced
this issue
May 29, 2024
The `Ready` status condition is becoming the standard for Korifi resources, therefore let's get rid of the `Valid` and `Invalid` conditions in favour of the `Ready` one. Thus the CFRoute status reconciliation code could be significantly simplified as we already have the readyConditionBuilder utility in place. Noone seems to care about `Valid`/`Invalid` status conditions, noone cares about the `Ready` condition as well. However, having a standard `Ready` condition is good (see #2098) While being here, `CFRoute.Status.Description` and `CFRoute.Status.CurrentStatus` are removed (as again, noone cares) - hopefully this is not an incompatible change. If anyone ever gets interested whether the route is OK, they should check the `Ready` condition instead. issue: #3304
danail-branekov
added a commit
that referenced
this issue
May 29, 2024
The `Ready` status condition is becoming the standard for Korifi resources, therefore let's get rid of the `Valid` and `Invalid` conditions in favour of the `Ready` one. Thus the CFRoute status reconciliation code could be significantly simplified as we already have the readyConditionBuilder utility in place. Noone seems to care about `Valid`/`Invalid` status conditions, noone cares about the `Ready` condition as well. However, having a standard `Ready` condition is good (see #2098) While being here, `CFRoute.Status.Description` and `CFRoute.Status.CurrentStatus` are removed (as again, noone cares) - hopefully this is not an incompatible change. If anyone ever gets interested whether the route is OK, they should check the `Ready` condition instead. issue: #3304
github-project-automation
bot
moved this from 🔄 In progress
to ✅ Done
in Korifi - Backlog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
This explore is a follow up from #1721
Generally, Korifi resources' controllers should ensure that referenced resources (such as jobs that backup a task workload, or secrets that are referenced by apps) a) exist, b) are in the state controllers expect them to be, and c) own them if created by the controller
However, if reconciling those referenced resources cannot be done (e.g. the controller wants to patch an immutable field, of a job with a different command is found for a task workload), we need to propagate this error to the API and the kubectl user.
Therefore, can we introduce a generic
Readystatus condition on all Korifi resources so thata) kubectl users can easily check it
b) API awaits that condition to become true
c) in both cases users would be aware that there is something wrong going on with those Korifi resources
Acceptance Criteria
ADR/proposal on how such a generic condition can be introduced and how it should be consumed
Timebox
No timebox
Dev Notes
No response
The text was updated successfully, but these errors were encountered: