Desired state of an operator

[Vatsal__Balde]

Every standard operator have some capability levels attached to it such as like (Basic install, seamless upgrades, full lifecycle, deep insights, auto pilot etc) depending on which an operator can have a desired state depending on which a system will be drawn to that state in case of a malfunctioning.

My question is from where we can dig out more details about these desired state of operators?

[joelbirchler]

There are two essential components of an operator: one or more custom resource and a control loop.  The control loop's job is to make sure that the state declared in the custom resource (the "desired state") is the current state.

For example, a PostgreSQL operator might have a Database Custom Resource Definition (CRD). If a user creates a Database resource, the control loop will check to see if the a database is deployed with the defined number of replicas and other settings. If it isn't, it will make the changes until the reality matches the declared state.

You might find the OpenShift documentation on operators helpful: https://docs.openshift.com/container-platform/4.2/operators/olm-what-operators-are.html

If you want to dig deep into how an operator works, check out the Operator SDK: https://github.com/operator-framework/operator-sdk/blob/master/doc/user-guide.md

[beelandc]

Additionally you may want to take a look at the Operator Maturity Model, which generalizes the scale of the maturity of an Operator’s encapsulated operations for certain set of capabilities that most Operators can include:

If you're looking to find more details about how to implement operators at each phase, you might start by looking at existing operators in operatorhub and navigating to their source code from there.