Draft guidelines on how substantial an operator has to be to become an independant project

[jberkus]

CNCF is starting to get a lot of Operators submitted as projects in the Sandbox queue. We do have some operators as projects, most notably Strimzi and Rook. However, it is also clear that some operators should instead be subprojects of the software they are operators for, rather than their own projects.

Drafting guidelines for how to make this decision would save time for evaluating the Sandbox queue.

@TheFoxAtWork

[TheFoxAtWork]

Thank you @jberkus for filing this issue.

I think one of the core items the TOC discussed on the most recent sandbox call and in previous discussions breaks this problem into a few different components:

• When should a operator be a core integration/offering a project?
• Should an operator, to exist as a standalone project, include other capabilities, such as exporters, controllers, plugins, hooks that provide adopters a "solution" to a problem set?

[raravena80]

Related: cncf/sandbox#49

[TheFoxAtWork]

Assigning this to myself to draft language on this later.

[linsun]

Would love another TOC member to take on.

[jberkus]

@raravena80 Kubean looks pretty clear-cut; it's a full tool for multicluster management, or at least it aspires to be.

However, also in the queue is CloudNativePG, Kardinal, and Runme Notebooks. And there's also the question of: what does an operator need for CNCF to accept it, if the software controlled by the Operator is not a CNCF project?

[raravena80]

One longer term suggestion is to group the operators into a different category. For example, they are not projects per se, they are 'operators'. There would have to be a requirement that whatever they are operating on needs to be open source, even if it's not part of the CNCF. I think ideally you want to foster the community around operators but being a 'project' may not be the fit.

[TheFoxAtWork]

that sounds more like the TOC Toolbox idea.