operator-sdk: Standardised Status Blocks

Feature Request

Problem Statement

When provisioning a product via it’s operator, the most common flow is:

  • Install the operator
  • Create a CR
  • Wait for the product to be ready

Currently, the final step is performed in a unique way for each operator, this could be as low-tech as checking if an end-point is responding correctly, or as automated as watching the status of the CR for something like “Status: Ready”.

Describe the solution you’d like

The ideal scenario would be for each CR to contain recommended fields (could be included in the boilerplate generation) including a “ready” field, a “version” field, a “phase” field, a “message” field.

Ready

This is best consumed, by humans and computers as a boolean, every status block that results in a system that can be consumed would have a

Status
  Ready: true|false

Version

It should be trivial to find out what version of an operand was provisioned, as a result of the creation of a CR, this would be kept up to date after upgrades to the product, every status block that results in a running product would have:

Status
  Version: x.y.z

Phase

This should show the current status of the operation triggered as a result of the CR, values for this should be one of:

  • Pending
  • Progressing
  • Complete / Reconciling
Pending

The operator has not yet started processing this CR, maybe it is blocked by other actions.

Progressing

The operator has now begun to process this CR, but has not yet completed the required actions.

Complete / Reconciling

This implies that the service is ready for use, if the configuration of the service is not maintained by the operator, then it should be “complete”, if the operator will continue to check and reconcile values, then the value should be “reconciling”, this phase should coincide with the ready field being set to true.

Message

This is used in conjunction with status to give a human-readable idea of what the operator is currently doing with the CR (e.g. “waiting for API server to start”, “service is active”).

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 5
  • Comments: 20 (9 by maintainers)

Most upvoted comments

Also related to managing conditions. Some new helpers are just added to the upstream API machinery. See: https://github.com/kubernetes/kubernetes/pull/92717/files#diff-96c14496c795cdcef80eed40c124f70a

I have removed my note from the agenda, as I am on PTO this afternoon and away from my computer. I notice you have a weekly triage call on Mondays, so I will attend this meeting next week to discuss there. I hope this is OK.