Starting work on Operator Working Group


Chris Hein
 

Thanks Alois, let us know if there is anything we can help with.

Chris Hein
On Mar 13, 2020, 11:28 AM -0700, Reitbauer, Alois <alois.reitbauer@...>, wrote:

I am working on getting a meeting on the calendar next week.

 

From: <cncf-sig-app-delivery@...> on behalf of "mhamdi.semah via Lists.Cncf.Io" <mhamdi.semah=gmail.com@...>
Reply to: "mhamdi.semah@..." <mhamdi.semah@...>
Date: Friday, 13. March 2020 at 16:25
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I'd like to contribute. Looking forward to it.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Reitbauer, Alois
 

I am working on getting a meeting on the calendar next week.

 

From: <cncf-sig-app-delivery@...> on behalf of "mhamdi.semah via Lists.Cncf.Io" <mhamdi.semah=gmail.com@...>
Reply to: "mhamdi.semah@..." <mhamdi.semah@...>
Date: Friday, 13. March 2020 at 16:25
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I'd like to contribute. Looking forward to it.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


mhamdi.semah@...
 

I'd like to contribute. Looking forward to it.


Scott Nichols
 

I am interested in participating in this SIG. 

I work on Knative and have spent a fair amount of time thinking about controllers and how to write them. I think the thing that no one has really talked about yet is the flavor and purpose of a controller/operator: I see three main types, one that extends functionality of K8s to do something new for you (like Knative Service) and a second type that is the operational instructions to keep a system running. A third is something that is reaching off the cluster to allow someone to write a declarative API for another component that might not be declarative. 

Lumping these all into the same name of "Operator" seems forced.

I do like the Operator SDKs scales of an operator, and I think there might be a second axis around how broad that extension acts (its scope).


On Wed, Mar 4, 2020 at 7:53 AM <james@...> wrote:
I'd definitely be interested in being involved :) I'm especially keen to understand how we can:

* Define best practices around _deploying_ operators, including periphery components such as webhooks
* Community guidelines on how to release and manage API versions: Kubernetes defines a lot of this already, but it is not surfaced clearly and is non-trivial
* Guidelines on interoperability between operators, e.g. one third party extension depending on another (for context, in cert-manager we are often depended upon by other operators, which creates a 'dependency problem')

Despite have '''opinions''' in the past, I'm actually less concerned about inventing a strict definition for "operator vs controller", and I'm not that convinced that defining the difference is actually beneficial to users. All of these things are 'controllers' in essence, and beyond that, I think 'operator' gets thrown around as a bit of a marketing term of the back of the original CoreOS blog post on this about the "etcd-operator".

Thanks for putting this all together anyway, and looking forward to getting started :)

(sorry for the dupe if anyone got one, the CNCF lists page has the "Group Reply" button to the right and it took me a good 5 minutes to spot it!!)


james@...
 

I'd definitely be interested in being involved :) I'm especially keen to understand how we can:

* Define best practices around _deploying_ operators, including periphery components such as webhooks
* Community guidelines on how to release and manage API versions: Kubernetes defines a lot of this already, but it is not surfaced clearly and is non-trivial
* Guidelines on interoperability between operators, e.g. one third party extension depending on another (for context, in cert-manager we are often depended upon by other operators, which creates a 'dependency problem')

Despite have '''opinions''' in the past, I'm actually less concerned about inventing a strict definition for "operator vs controller", and I'm not that convinced that defining the difference is actually beneficial to users. All of these things are 'controllers' in essence, and beyond that, I think 'operator' gets thrown around as a bit of a marketing term of the back of the original CoreOS blog post on this about the "etcd-operator".

Thanks for putting this all together anyway, and looking forward to getting started :)

(sorry for the dupe if anyone got one, the CNCF lists page has the "Group Reply" button to the right and it took me a good 5 minutes to spot it!!)


Gerred Dillon
 

Alois,

Are we ready to move to the next steps? The charter seems to be settling. I'd move to kick off an initial meeting, establish leadership, and establish the scope and times for this WG and begin reporting back to the SIG.

Gerred

On Mon, Mar 2, 2020 at 12:01 PM Naga Ravi Chaitanya Elluri <nelluri@...> wrote:
+1, I am in.

On Fri, Feb 21, 2020 at 11:04 AM Reitbauer, Alois <alois.reitbauer@...> wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Felipe Musse
 

Great initiative, I'm very interested in participating.


Naga Ravi Chaitanya Elluri
 

+1, I am in.

On Fri, Feb 21, 2020 at 11:04 AM Reitbauer, Alois <alois.reitbauer@...> wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Nicolas Trangez <nicolas.trangez@...>
 

+1 very interested as well. K8s' continuous refinement from high-level
state declarations to real-world realization, and Operators/CRDs to
extend this model even further (including application/domain-specific
knowledge translated to code) are what makes an investment in K8s
compared to more traditional configuration management systems *really*
worthwhile.

Nicolas

On Mon, 2020-03-02 at 11:52 +0100, Guillaume Demonet via Lists.Cncf.Io
wrote:
+1 for me as well, thanks for the initiative!

On Mon, Mar 2, 2020 at 2:08 AM Peter Lunderbye <
peter.lunderbye@...>
wrote:

+1 Count me in

~ Peter
------------------------------
*Från:* cncf-sig-app-delivery@... <
cncf-sig-app-delivery@...> för Bowen, Mike <
mike.bowen@...>
*Skickat:* den 29 februari 2020 18:55
*Till:* prudraraju@... <prudraraju@...>;
cncf-sig-app-delivery@... <
cncf-sig-app-delivery@...>
*Ämne:* Re: [cncf-sig-app-delivery] Starting work on Operator
Working
Group


Please count me in.



*-Mike Bowen*





*From: *<cncf-sig-app-delivery@...> on behalf of
"prudraraju
via Lists.Cncf.Io" <prudraraju=salesforce.com@...>
*Reply-To: *"prudraraju@..." <prudraraju@...>
*Date: *Friday, February 28, 2020 at 9:50 PM
*To: *"cncf-sig-app-delivery@..." <
cncf-sig-app-delivery@...>
*Cc: *"cncf-sig-app-delivery@..." <
cncf-sig-app-delivery@...>
*Subject: *Re: [cncf-sig-app-delivery] Starting work on Operator
Working
Group



External Email: Use caution with links and attachments

I am interested in joining. Looking forward to following standards
set by
the group.



This message may contain information that is confidential or
privileged.
If you are not the intended recipient, please advise the sender
immediately
and delete this message. See
http://www.blackrock.com/corporate/compliance/email-disclaimers for
further information. Please refer to
http://www.blackrock.com/corporate/compliance/privacy-policy for
more
information about BlackRock’s Privacy Policy.

For a list of BlackRock's office addresses worldwide, see
http://www.blackrock.com/corporate/about-us/contacts-locations.

© 2020 BlackRock, Inc. All rights reserved.



--
Guillaume DEMONET
Scality - R&D Engineer
+33 6 58 58 11 26 | guillaume.demonet@...
http://scality.com/ | Twitter: @scality <https://twitter.com/scality>


Guillaume Demonet
 

+1 for me as well, thanks for the initiative!

On Mon, Mar 2, 2020 at 2:08 AM Peter Lunderbye <peter.lunderbye@...> wrote:
+1 Count me in

~ Peter

Från: cncf-sig-app-delivery@... <cncf-sig-app-delivery@...> för Bowen, Mike <mike.bowen@...>
Skickat: den 29 februari 2020 18:55
Till: prudraraju@... <prudraraju@...>; cncf-sig-app-delivery@... <cncf-sig-app-delivery@...>
Ämne: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group
 

Please count me in.

 

-Mike Bowen

 

 

From: <cncf-sig-app-delivery@...> on behalf of "prudraraju via Lists.Cncf.Io" <prudraraju=salesforce.com@...>
Reply-To: "prudraraju@..." <prudraraju@...>
Date: Friday, February 28, 2020 at 9:50 PM
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

External Email: Use caution with links and attachments

I am interested in joining. Looking forward to following standards set by the group. 

 

This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.blackrock.com/corporate/compliance/email-disclaimers for further information.  Please refer to http://www.blackrock.com/corporate/compliance/privacy-policy for more information about BlackRock’s Privacy Policy.

For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/about-us/contacts-locations.

© 2020 BlackRock, Inc. All rights reserved.



--
Guillaume DEMONET
Scality - R&D Engineer
+33 6 58 58 11 26 | guillaume.demonet@...


Peter Lunderbye
 

+1 Count me in

~ Peter

Från: cncf-sig-app-delivery@... <cncf-sig-app-delivery@...> för Bowen, Mike <mike.bowen@...>
Skickat: den 29 februari 2020 18:55
Till: prudraraju@... <prudraraju@...>; cncf-sig-app-delivery@... <cncf-sig-app-delivery@...>
Ämne: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group
 

Please count me in.

 

-Mike Bowen

 

 

From: <cncf-sig-app-delivery@...> on behalf of "prudraraju via Lists.Cncf.Io" <prudraraju=salesforce.com@...>
Reply-To: "prudraraju@..." <prudraraju@...>
Date: Friday, February 28, 2020 at 9:50 PM
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

External Email: Use caution with links and attachments

I am interested in joining. Looking forward to following standards set by the group. 

 

This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.blackrock.com/corporate/compliance/email-disclaimers for further information.  Please refer to http://www.blackrock.com/corporate/compliance/privacy-policy for more information about BlackRock’s Privacy Policy.

For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/about-us/contacts-locations.

© 2020 BlackRock, Inc. All rights reserved.


Reitbauer, Alois
 

Great to see so much interest in this work.

 

You can find the latest draft of the charter here: https://docs.google.com/document/d/1DqHnj8O9DoU1ev9RvEdpStFUQvH-Iz6OYako6bQn9rM/edit#

 

I also added a section at the end where everyone can share what they want to get out the working group.

 

// Alois

 

 

From: <cncf-sig-app-delivery@...> on behalf of "Bowen, Mike via Lists.Cncf.Io" <mike.bowen=blackrock.com@...>
Reply to: "mike.bowen@..." <mike.bowen@...>
Date: Saturday, 29. February 2020 at 19:08
To: "prudraraju@..." <prudraraju@...>, "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

Please count me in.

 

-Mike Bowen

 

 

From: <cncf-sig-app-delivery@...> on behalf of "prudraraju via Lists.Cncf.Io" <prudraraju=salesforce.com@...>
Reply-To: "prudraraju@..." <prudraraju@...>
Date: Friday, February 28, 2020 at 9:50 PM
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

External Email: Use caution with links and attachments

I am interested in joining. Looking forward to following standards set by the group. 

 

This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.blackrock.com/corporate/compliance/email-disclaimers for further information.  Please refer to http://www.blackrock.com/corporate/compliance/privacy-policy for more information about BlackRock’s Privacy Policy.

For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/about-us/contacts-locations.

© 2020 BlackRock, Inc. All rights reserved.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Bowen, Mike
 

Please count me in.

 

-Mike Bowen

 

 

From: <cncf-sig-app-delivery@...> on behalf of "prudraraju via Lists.Cncf.Io" <prudraraju=salesforce.com@...>
Reply-To: "prudraraju@..." <prudraraju@...>
Date: Friday, February 28, 2020 at 9:50 PM
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

External Email: Use caution with links and attachments

I am interested in joining. Looking forward to following standards set by the group. 

 

This message may contain information that is confidential or privileged. If you are not the intended recipient, please advise the sender immediately and delete this message. See http://www.blackrock.com/corporate/compliance/email-disclaimers for further information.  Please refer to http://www.blackrock.com/corporate/compliance/privacy-policy for more information about BlackRock’s Privacy Policy.

For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/about-us/contacts-locations.

© 2020 BlackRock, Inc. All rights reserved.


prudraraju@...
 

I am interested in joining. Looking forward to following standards set by the group. 


Reitbauer, Alois
 

I created a Google Doc to detail out what we want to work on. Please add yourself and also comment regarding goal and non-goals.

 

// Alois

 

 

[1] https://docs.google.com/document/d/1DqHnj8O9DoU1ev9RvEdpStFUQvH-Iz6OYako6bQn9rM/edit?usp=sharing

 

From: <cncf-sig-app-delivery@...> on behalf of "Matt Baldwin via Lists.Cncf.Io" <baldwin=stackpointcloud.com@...>
Reply to: "baldwin@..." <baldwin@...>
Date: Tuesday, 25. February 2020 at 03:07
To: Chris Hein <me@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I'm very interested in participating in this sig. Looking forward to it. 

 

On Mon, Feb 24, 2020 at 12:23 PM Chris Hein <me@...> wrote:

I'm interested in contributing & participating in this!


 

--

...........................................................................................................

 

Matt Baldwin

CEO

connect // (206) 719-8374 / LinkedIn / @baldwinmathew

 

Follow StackPointCloud on LinkedInTwitter, and Google +

Recent News : Bitnami, Stackpoint.io Partner to Deliver Turn-Key, Managed Multi-Cloud Serverless

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Liz Rice <liz@...>
 

It would be hugely helpful to have a community-agreed definition of what an Operator is, so I'm all in favour of this initiative. 

--
Liz Rice - sent from my phone

On 24 Feb 2020, at 11:57, Matt Farina <matt@...> wrote:


Alois,

You made a comment that may be getting to my point of confusion...

3. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?
[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

This raises two questions for me...
  1. The SIGs derive their scope from the TOC who gets it from the charter. What output could come from the "valid" operator discussion that would be used within the scope of the TOC as it relates to the projects. The TOC doesn't sit as management to project maintainers telling them what to do or build.
  2. If it comes to being listed in the operator hub isn't that an interface that the owner of the operator hub declares and works with other projects on? Isn't it the owner of the operator hub to decide on the scope for what they list?

I ask these questions because it comes down to a matter of who owns what scope. This is why I wanted the project level scope worked out ahead of time.

Does that help to explain why I'm asking the questions.

- Matt

On Mon, Feb 24, 2020, at 11:27 AM, Reitbauer, Alois wrote:

See comments below:

 

// Alois

 

From: <cncf-sig-app-delivery@...> on behalf of "Matt Farina via Lists.Cncf.Io" <matt=mattfarina.com@...>
Reply to: "matt@..." <matt@...>
Date: Friday, 21. February 2020 at 18:11
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I have a few questions, if you don't mind. I'm trying to place where this fits with the things...

 

  1. Is this meant to be a formal working group under the CNCF? As in https://github.com/cncf/toc/tree/master/workinggroups

[Alois] – Yes, just as we do for air gapped environemnts

  1. Is there a definition of done for the working group? Or a task to figure that out. Something like "Coordination work among different operator framework" could go on forever.

[Alois] First step is to see whether we have enough interested people. Next steps is to define the detailed agenda. I just threw in some high level discussion points to get the converstion started.

  1. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?

[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

 

Thanks,

Matt

 

On Fri, Feb 21, 2020, at 11:00 AM, Reitbauer, Alois wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20

 


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Matt Baldwin <baldwin@...>
 

I'm very interested in participating in this sig. Looking forward to it. 


On Mon, Feb 24, 2020 at 12:23 PM Chris Hein <me@...> wrote:
I'm interested in contributing & participating in this!



--
...........................................................................................................

Matt Baldwin
CEO

Recent News : Bitnami, Stackpoint.io Partner to Deliver Turn-Key, Managed Multi-Cloud Serverless


Chris Hein
 

+1 I'm interested and willing to contribute.


On Mon, Feb 24, 2020 at 11:57 AM Matt Farina <matt@...> wrote:
Alois,

You made a comment that may be getting to my point of confusion...

3. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?
[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

This raises two questions for me...
  1. The SIGs derive their scope from the TOC who gets it from the charter. What output could come from the "valid" operator discussion that would be used within the scope of the TOC as it relates to the projects. The TOC doesn't sit as management to project maintainers telling them what to do or build.
  2. If it comes to being listed in the operator hub isn't that an interface that the owner of the operator hub declares and works with other projects on? Isn't it the owner of the operator hub to decide on the scope for what they list?

I ask these questions because it comes down to a matter of who owns what scope. This is why I wanted the project level scope worked out ahead of time.

Does that help to explain why I'm asking the questions.

- Matt

On Mon, Feb 24, 2020, at 11:27 AM, Reitbauer, Alois wrote:

See comments below:

 

// Alois

 

From: <cncf-sig-app-delivery@...> on behalf of "Matt Farina via Lists.Cncf.Io" <matt=mattfarina.com@...>
Reply to: "matt@..." <matt@...>
Date: Friday, 21. February 2020 at 18:11
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I have a few questions, if you don't mind. I'm trying to place where this fits with the things...

 

  1. Is this meant to be a formal working group under the CNCF? As in https://github.com/cncf/toc/tree/master/workinggroups

[Alois] – Yes, just as we do for air gapped environemnts

  1. Is there a definition of done for the working group? Or a task to figure that out. Something like "Coordination work among different operator framework" could go on forever.

[Alois] First step is to see whether we have enough interested people. Next steps is to define the detailed agenda. I just threw in some high level discussion points to get the converstion started.

  1. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?

[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

 

Thanks,

Matt

 

On Fri, Feb 21, 2020, at 11:00 AM, Reitbauer, Alois wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20

 


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Omer Kahani
 

I'm also interesting in joining


On Mon, Feb 24, 2020 at 6:27 PM Reitbauer, Alois <alois.reitbauer@...> wrote:

See comments below:

 

// Alois

 

From: <cncf-sig-app-delivery@...> on behalf of "Matt Farina via Lists.Cncf.Io" <matt=mattfarina.com@...>
Reply to: "matt@..." <matt@...>
Date: Friday, 21. February 2020 at 18:11
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I have a few questions, if you don't mind. I'm trying to place where this fits with the things...

 

  1. Is this meant to be a formal working group under the CNCF? As in https://github.com/cncf/toc/tree/master/workinggroups

[Alois] – Yes, just as we do for air gapped environemnts

  1. Is there a definition of done for the working group? Or a task to figure that out. Something like "Coordination work among different operator framework" could go on forever.

[Alois] First step is to see whether we have enough interested people. Next steps is to define the detailed agenda. I just threw in some high level discussion points to get the converstion started.

  1. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?

[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

 

Thanks,

Matt

 

On Fri, Feb 21, 2020, at 11:00 AM, Reitbauer, Alois wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Matt Farina
 

Alois,

You made a comment that may be getting to my point of confusion...

3. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?
[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

This raises two questions for me...
  1. The SIGs derive their scope from the TOC who gets it from the charter. What output could come from the "valid" operator discussion that would be used within the scope of the TOC as it relates to the projects. The TOC doesn't sit as management to project maintainers telling them what to do or build.
  2. If it comes to being listed in the operator hub isn't that an interface that the owner of the operator hub declares and works with other projects on? Isn't it the owner of the operator hub to decide on the scope for what they list?

I ask these questions because it comes down to a matter of who owns what scope. This is why I wanted the project level scope worked out ahead of time.

Does that help to explain why I'm asking the questions.

- Matt

On Mon, Feb 24, 2020, at 11:27 AM, Reitbauer, Alois wrote:

See comments below:

 

// Alois

 

From: <cncf-sig-app-delivery@...> on behalf of "Matt Farina via Lists.Cncf.Io" <matt=mattfarina.com@...>
Reply to: "matt@..." <matt@...>
Date: Friday, 21. February 2020 at 18:11
To: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Cc: "cncf-sig-app-delivery@..." <cncf-sig-app-delivery@...>
Subject: Re: [cncf-sig-app-delivery] Starting work on Operator Working Group

 

I have a few questions, if you don't mind. I'm trying to place where this fits with the things...

 

  1. Is this meant to be a formal working group under the CNCF? As in https://github.com/cncf/toc/tree/master/workinggroups

[Alois] – Yes, just as we do for air gapped environemnts

  1. Is there a definition of done for the working group? Or a task to figure that out. Something like "Coordination work among different operator framework" could go on forever.

[Alois] First step is to see whether we have enough interested people. Next steps is to define the detailed agenda. I just threw in some high level discussion points to get the converstion started.

  1. Why do we need a minimum requirements for a "valid" operator? Has a problem surfaced that needs this for solving?

[Alois]  This relates to comments from your side regarding requirements to be listed in e.g. operator hub for non OLM operators.

 

Thanks,

Matt

 

On Fri, Feb 21, 2020, at 11:00 AM, Reitbauer, Alois wrote:

Hello everybody,

 

As discussed a while back we are also planning a working group on Operators. This is the next step after starting the work on operator definition. During the creation of the document it became clear that there is more work to be done than simply a definition.  Also with operator related projects joining the CNCF and more and more project using operators to deploy and manage on Kubernetes there is a lot to be covered:

 

  • Best practices how to write operators e.g. CRDs, APIs, ….
  • Minimum requirements for a “valid” operator
  • Supporting projects with Operators
  • Coordination work among different operator framework.

 

As this is a working group, we will need people to do the actual work 😊. If you are willing to actively contribute, please simply reply to this thread.

 

// Alois

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20

 


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20