there were a bunch of questions in the last SIG call in regards to Operators that did not get answered - I am running through the ones from the chat log below. Feel free to chime in, if there was anything else you'd like to see covered!

---

Q: You mention stateful services hand-in-hand with The Operator Framework, however AFAIU, Operators can be controllers of stateless services as well, yes? In other words, The Operator Framework doesn't require a stateful design of the Operator, right?

A: Correct. While most use cases for Operator involve stateful applications it's not a requirement. Operators also provide a single resource to manage/represent an instance of an application using a CRD. This resource also is the basis for RBAC so certain users/roles can be allowed/denied access to a managed application. Finally, the Operator reconciles in a loop so any configuration drifts of the managed resources are reverted automatically. This all applies to stateful applications, too.

---

Q: Can you talk a bit about the relationship between OLM and the Open Service Broker project?

A: There is no direct relationship. IMHO Operators provide an evolution to Service Brokers and 

we see most of the community as well as vendors move towards Operators.

---

Q: Perhaps also discuss the relationship between kubebuilder and Operator Framework

A: There is collaboration on the maintainer level. We plan to integrate with Kubebuilder on the SDK side by converging on a joint project layout and CLI switches. Kubebuilder focusses on Golang-based Operators while the SDK adds Ansible, Helm and potentially more language in the future on top of that plus packaging and testing.

---

Q: If there are 5 operators available to help run/manage MySQL database,  how would you know which one to choose?

That's a great question. We have drafted a capability model (https://github.com/operator-framework/operator-sdk/blob/master/doc/images/operator-capability-level.png) that allows to differentiate between Operators in terms of maturity. Eventually it comes down to the feature set of an Operator.

---

Q:  Are Operators meant to be used with helm charts?

A: This is possible with the SDK. There is a conversion (https://github.com/operator-framework/operator-sdk/blob/master/doc/helm/user-guide.md) that takes charts as is and makes them run as an Operator. This is a good entry point in getting a handle on the CRD driven workflow and also allows to run charts without Tiller. We are looking to adopt Helm v3 very soon after release and are in contact with the helm maintainers.

Helm-based Operators are useful where you want to delegate access to a chart on cluster via standard RBAC and make it available via standard kubectl.

--