Skip to content

update how status management is handled during reconciliation #86

@tylerslaton

Description

@tylerslaton

Per at @joelanford's advice, we should reconsider how we are handling status management in Combo. Currently we are overwriting the status to be the current phase of the process. Instead we should have all status' present in that field and update each one individually as progress is made. For more information:

Lots of good detail here: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

To me, this is one of the harder things to get right. The general pattern I try to follow is:

Ensure every single condition supported by the operator is set before you return from reconcile.
Every single condition should be set based on the latest known state for that condition.
If you can't derive a definitive True/False status of a particular condition, it should be set to "Unknown" with a description message about why it could not be determined (usually from an error that occurred somewhere)
Don't update a condition more than once during a reconcile method. Generally this can be interpreted as "there should be exactly one Status().Update() call in the reconcile method." Updating more than once results in unnecessary chatter with the apiserver, noisy eventing to any watchers, and unnecessary changes of the last transition time.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions