+1 for workload and for a concise definition like Devdatta proposed. I found that most people get it when I explain operators as "runbooks as code". Especially when I talk to folks that don't know

+1 for workload. I think application will eventually have a definition we can all get behind, and it will be different.

After reading thru the thread, I tend to agree "workload" reads more accurate than "application" in Operator Framework's case. The difference here seems to be: "how to run" vs "what to run". --- Lei

I agree with Matt and Doug that the scope of the definition need not be specific to Kubernetes. Given this SIG is at the CNCF level, aren't we responsible for defining these things broadly across the

@Matt, @Doug, I definitely see your points. I just think that we have a good opportunity here to start with a clean slate and come up with a definition that is generic as well as precise. In fact,

I think Doug brings up an excellent point. Where I started from when I put the CoreOS definition out there assumed Kubernetes. But, technically you could have a Nomad operator and maybe even a Cloud

I also want to track these discussions in issues: I created one for the operator definition https://github.com/cncf/sig-app-delivery/issues/15 and one for the Operator Framework/Hub submission

I don’t want Matt to feel alone :-) so I’ll agree with his concern about the latest proposed wording being a bit too.... low-level/geeky for a non-insignificant number of people who will read

The point about ‘whom’ the definition is targeted towards is valid. As pointed out below there is a wide variety of personas who need to refer to ‘Kubernetes Operators’. Key focus needs to be

For a moment can we consider who will read this and need to understand it. I think the language that's chosen should be useful to them and not just us. Many of the people who need to understand it are

That's part of the traditional definition, yes, so I'm all for it - but a lot of the definitions seemed to be moving more generically. Could an aggregate API, while not a CRD, be included in the

Second Devdatta's concise definition. Please correct me if I misunderstood, but I thought Operators allowed accessing/managing CRDs through the API Server (i.e. using kubectl).

I like Devdatta's description a lot about domain + workflow + declarative - though I wouldn't call it an API extension, as that may potentially imply aggregate APIs. It's still a controller first and

Another nit... I personally prefer to use the word 'application' for more user-facing stuff. vs system software like Etcd, Redis, Kafka etc.

Hello, I agree with Marc and Nicolas. The definition of an Operator should not be restricted to stateful systems or applications. Here is another more generic definition option: "An Operator is a

For the purposes of a definition, I would remove "complex" and "stateful" as requirements. It's both possible and advantageous to make an operator for a simple application and for a stateless

The qualification of "Stateful application" feels restrictive to me also. We've built operators that don't manage any state, but still call them "operators" because they codify and package a domain or

Thanks for the feedback Nicolas. If I understand you right ... you would like to drop the work stateful from the definition. Is that right?

Hello, Why would this only be for 'stateful' applications, or even 'applications' in general? Some cases I have in mind: Non-stateful applications: - An operator that deploys some application which

In the TOC meeting yesterday (11/5) there was a question about the definition of an operator that was kicked back to SIG App Delivery. In the app delivery call today, at least before I had to drop, no