Improved operator status introspection through additional events and conditions

[viveklak]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

While #235 provides some starting points for stack status introspection through events, the experience, especially on the open source backends is less than ideal. We should externalize details about the current state of the stack through extensive use of the events and condition API instead to avoid having users drop to debug logging to track status.

Affected area/feature

Operator usability

[squaremo]

All else being equal, I think it's wise to work with the conventions assumed by kstatus: https://pkg.go.dev/sigs.k8s.io/cli-utils/pkg/kstatus#section-readme

This amounts to:

• have a field observedGeneration that is updated to be equal to .meta.generation by the controller when it reconciles an object
• use the condition Ready to indicate a "gross" status -- it's either True meaning "up to date with respect to the .spec" or False meaning "not up to date"
• use the conditions Reconciling and Stalled to indicate fine status when Ready is not True; Reconciling meaning an update is in progress, and Stalled meaning an update will not succeed without intervention (the spec changing, or the source changing).

[EronWright]

Good news everyone, we just released a preview of Pulumi Kubernetes Operator v2. This new release has a whole-new architecture that uses pods as the execution environment. A lot has been improved in logging and status reporting, but the Stack API is largely unchanged and so further improvement may be warranted. The observedGeneration field is now handled correctly.

Please read the announcement blog post for more information: https://www.pulumi.com/blog/pulumi-kubernetes-operator-2-0/

Would love to hear your feedback! Feel free to engage with us on the #kubernetes channel of the Pulumi Slack workspace.