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)
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.