Open ricardozanini opened 3 years ago
Some previous experience:
n
previous conditions available, appending without end here will just clutter up the output of kubectl describe
and others. We should remove older entries when adding new ones if this capacity is reached. This seems to be the behavior of native resources, at least.conditions
slice are the same (imagine a failure loop) then we can extract little information from it and its purpose is defeated.this is a bit subjective, but IMO it makes sense to simply overwrite the timestamp of the most recent condition if we're about to report the same exact condition again
Yup. The idea is to have each condition in the array with the latest status and the status set to true
for those we currently are. It's a state diagram-like implementation.
Is your feature request related to a problem? Please describe. Right now we are not keeping the entire history of the CR status in the Nexus object, what we have is:
Although is interesting to reflect the internal
Deployment
status, ideally we would carry the conditions array ourselves. See an example: https://medium.com/swlh/advanced-kubernetes-operators-development-988edad5f58a (Set Status Conditions section)Describe the solution you'd like To add the
Status.Conditions[]
field to the Nexus CR.Describe alternatives you've considered Right now we have only the latest "condition" described in our CR
Additional context This article brings a glimpse about this implementation. But we can also see Knative CRs for other references.