Operator definitions seem to vary based on audience and context.

The ask from the TOC was about the sort of operators that the operator framework and KUDO enable. The essence of the pattern described by Brandon Philips.

You are absolutely right that this has to do with context. When I talk about operators to the local construction workers they have an entirely different idea. It's the people driving the heavy machinery.

Here are some equally valid (in my opinion) definitions of operators, but they address different audiences for different purposes:

1. The operator concept; the abstract notion that automating human operational tasks is the way to operate services at scale. The SRE book persuasively makes the case for the right amount of this kind of automation. The defining feature is the ability to access and modify the underlying infrastructure on which the application is running to provide automation.

I could do this with a function in a FaaS that runs at set intervals (i.e. cron). Does this count as a operator in the sense of the ask from the TOC?

2. The kubernetes operator “pattern”, the specific instantiation of the operator concept in kubernetes, which looks like a controller. These are also typically level-based as a best practice, and typically extend the control plane with CRDs.

What's the difference between the operator pattern and a controller? What distinguishes the Crunchy Data PostgreSQL operator from the core deployment Kubernetes controller? Why is one a controller and the other an operator? If we can't answer this question in a repeatable manner the term operator will not have much meaning.

3. A classification of software that attempts to provide cloud-like service experiences without being tied to a specific vendor.

The first thing that comes to mind is the Kubernetes service catalog. Is that an operator?

4. Various tools’ definition of an operator, such as OLM or KUDO or Metacontroller. There are natural variations in these and they need to be communicated to users of these projects.

Is Metacontroller an operator? Or, is it a tool you can use to build controllers that might happen to be operators? The different matters.

While I enjoy a good philosophical conversation, I hope the goal is to be useful to end-users, project creators, and the TOC who ultimately asked for a definition. How can a useful definition be created for them?

- Matt Farina

On Thu, Apr 23, 2020, at 11:03 PM, Evan Cordell wrote:

Operator definitions seem to vary based on audience and context.

Here are some equally valid (in my opinion) definitions of operators, but they address different audiences for different purposes:

1. The operator concept; the abstract notion that automating human operational tasks is the way to operate services at scale. The SRE book persuasively makes the case for the right amount of this kind of automation. The defining feature is the ability to access and modify the underlying infrastructure on which the application is running to provide automation.

2. The kubernetes operator “pattern”, the specific instantiation of the operator concept in kubernetes, which looks like a controller. These are also typically level-based as a best practice, and typically extend the control plane with CRDs.

3. A classification of software that attempts to provide cloud-like service experiences without being tied to a specific vendor.

4. Various tools’ definition of an operator, such as OLM or KUDO or Metacontroller. There are natural variations in these and they need to be communicated to users of these projects.

On Thu, Apr 23, 2020 at 7:12 PM Omer Kahani <kahaniomer@...> wrote:

Do we have a list of things that call themself operator? I agree we don't need to stretch the definition to include all of them, but it will be a good starting point. From a list, we could find common elements.

Omer Kahani

On Wed, Apr 22, 2020 at 8:17 PM Matt Farina <matt@...> wrote:

There are some parts of the operator definition working doc I was hoping to discuss between meetings. Some things are not clear.

The document starts with a goal and a concept but not a definition. If we are targeting if for a reader looking for a definition might I suggest we write it that way. Is there a reason we don't have the modified form of the original CoreOS definition at the top? For quick reference it's in the definition doc I wrote up for myself.

The discussions have brought up two harder questions.

1. Is this a greenfield effort to treat creating a definition for operators as a new thing or does it rely on the existing definitions? I would suggest we are documenting what's already defined and exists but some of the conversations act more like we can create the definition rather than find it as it already is.
   
2. There are many cases of things being labeled as operators that are not the CoreOS definition. I think part of that is because the name operator is marketable. Is this definition trying to make all of the things currently labeled as an operator fit the definition? Even if they go outside the simple CoreOS based definition? If we go that route a lot of things could easily call themselves an operator even if they don't fit what we think. I would suggest we don't do that and that it's ok saying something that calls itself an operator does not fit.
   

Then there is the capability model. We talked about some things on the call that are useful to have but not part of the definition. I would suggest a capability model fits there. It's something else that can come later. But, a definition of an operator can be known and discussed without one.

Definitions aren't full white papers. They aren't encyclopedia articles or how-to guides. I ask that the definition stay at a high level. Then other useful things can be created alongside the definition.

Regards,

Matt Farina