Update Operator-Status enhancement

[awgreene]

/hold Looking for a review from @shawn-hurley

[Jamstah]

Thanks for the heads-up.

My use case for the Ready condition was more about things that OLM cannot deduce on its own - there is a growing use case for operators that don't just manage in-cluster resources, such as an operator that will provision services from the cloud in response to a CR. If that operator is configured with a cloud account, then it will only be in Ready state if that cloud account is valid and the operator can communicate with the cloud service.

This is heavily applicable to the Openshift cluster operators, which require credentials to talk to their hosting cloud to adjust machines, load balancers, etc. I can see that same concept being applied more widely in the future.

Happy to describe in a changeset if you think this use case would be helpful as part of this PR.

[awgreene]

Thanks for the heads-up. My use case for the Ready condition was more about things that OLM cannot deduce on its own - there is a growing use case for operators that don't just manage in-cluster resources, such as an operator that will provision services from the cloud in response to a CR. If that operator is configured with a cloud account, then it will only be in Ready state if that cloud account is valid and the operator can communicate with the cloud service. This is heavily applicable to the Openshift cluster operators, which require credentials to talk to their hosting cloud to adjust machines, load balancers, etc. I can see that same concept being applied more widely in the future. Happy to describe in a changeset if you think this use case would be helpful as part of this PR.

@Jamstah this provides a great deal of context - would you mind creating an issue so we can triage this at some point?

[alanconway]

This makes sense to me with the exception of the name "Status".

If I understand correctly, this CR represents the status of the operator itself as distinct from the various CRs that the operator manages. In that case it should be called "Operator" and contain a status sub-resource like any other CR. Even if the Operator CR has no spec and contains nothing but status, the name should still indicate what resource it represents. Every CRD has a status so the name "Status" for a CRD conveys nothing, it's like calling it "Object" or "Resource".

[awgreene]

/unhold

[kevinrizza]

/approve