1. Cncf-Tag-App-Delivery
  2. Topics

Operator WG: Discussion Points

Omer Kahani
 

Hi,

In the last WG meeting (27.5), we were only three people, and we felt that this is not enough people for a vote. Instead, we want to try to use the mailing list to get more opinions, and maybe also do some votes. 


I added two sections from the operator group, with the points raised in the doc written as questions that you can answer. You can answer the questions or raise more questions.


1. Operators vs. Controllers:

Current text: "A Controller is an in-cluster process that executes a continuous reconciliation loop to act on changes to one or more registered types (GVK). A Controller is an implementation.


An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application.


Often, the term Operator is used as a generic descriptor for an in-cluster Controller. But Controllers and Operators do have different meanings. All Operators have a Controller but not all Controllers are functioning as Operators."


- Do we need to add CRD to the text?

An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application, using a CRD


2. Properties of an Operator

Current text:"

  • Control Loop? Using the Watch API? Level triggered system?
  • Reactive nature - but reactive is just message

"

- does a controller must have a control loop, does it must use the watch API?


There is a lot more in the doc: https://docs.google.com/document/d/1daXHyR2yG5ArjO1PO83v4a0fmLCLo2kYNT3TwGZksng/edit?usp=sharing

But I think that we can start with these points and then determine how to continue.


Regards,

Omer Kahani
Josiah Ritchie
 

I'd certainly not limit to a single CRD. There are several existing operators that use multiple CRDs. There are also things people have built that don't use a CRD, but perhaps that should be considered a Controller. 


On Fri, May 29, 2020 at 4:06 PM Omer Kahani <kahaniomer@...> wrote:
Hi,

In the last WG meeting (27.5), we were only three people, and we felt that this is not enough people for a vote. Instead, we want to try to use the mailing list to get more opinions, and maybe also do some votes. 


I added two sections from the operator group, with the points raised in the doc written as questions that you can answer. You can answer the questions or raise more questions.


1. Operators vs. Controllers:

Current text: "A Controller is an in-cluster process that executes a continuous reconciliation loop to act on changes to one or more registered types (GVK). A Controller is an implementation.


An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application.


Often, the term Operator is used as a generic descriptor for an in-cluster Controller. But Controllers and Operators do have different meanings. All Operators have a Controller but not all Controllers are functioning as Operators."


- Do we need to add CRD to the text?

An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application, using a CRD


2. Properties of an Operator

Current text:"

  • Control Loop? Using the Watch API? Level triggered system?
  • Reactive nature - but reactive is just message

"

- does a controller must have a control loop, does it must use the watch API?


There is a lot more in the doc: https://docs.google.com/document/d/1daXHyR2yG5ArjO1PO83v4a0fmLCLo2kYNT3TwGZksng/edit?usp=sharing

But I think that we can start with these points and then determine how to continue.


Regards,

Omer Kahani
Marc Campbell
 

Thanks Omer.

How about:

"An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application, using one or more CRDs".

Regarding your second question: I think it's common to use the watch API / Kubernetes Informers while implementing an Operator, but I don't think it should be a requirement that all "Operators" implement this. There are some examples of Operators that respond to external events and take action or deploy changes to the cluster.

-Marc Campbell



On Fri, May 29, 2020 at 1:06 PM, Omer Kahani <kahaniomer@...> wrote:
Hi,

In the last WG meeting (27.5), we were only three people, and we felt that this is not enough people for a vote. Instead, we want to try to use the mailing list to get more opinions, and maybe also do some votes. 


I added two sections from the operator group, with the points raised in the doc written as questions that you can answer. You can answer the questions or raise more questions.


1. Operators vs. Controllers:

Current text: "A Controller is an in-cluster process that executes a continuous reconciliation loop to act on changes to one or more registered types (GVK). A Controller is an implementation.


An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application.


Often, the term Operator is used as a generic descriptor for an in-cluster Controller. But Controllers and Operators do have different meanings. All Operators have a Controller but not all Controllers are functioning as Operators."


- Do we need to add CRD to the text?

An Operator is a subset of Controllers that provides an application or domain-specific knowledge to install or “operate” an application, using a CRD


2. Properties of an Operator

Current text:"

  • Control Loop? Using the Watch API? Level triggered system?
  • Reactive nature - but reactive is just message

"

- does a controller must have a control loop, does it must use the watch API?


There is a lot more in the doc: https://docs.google.com/document/d/1daXHyR2yG5ArjO1PO83v4a0fmLCLo2kYNT3TwGZksng/edit?usp=sharing

But I think that we can start with these points and then determine how to continue.


Regards,

Omer Kahani

1 - 3 of 3