Draft Governance and Membership

[dmesser]

No description provided.

[ecordell]

is disability the word we want to use here?

[gerred]

agreed, inability feels better, or unable to fulfill the role to be even more gentle. Also, this immediate removal seems fairly aggressive. How does this removal happen? By simple majority of the existing chairs? I'd prefer to identify ways that existing chairs can gracefully terminate their role and trigger an election, and provide mechanisms that reflect reality. This could potentially be an enhancement proposal after the initial governance charter has landed. :)

[gerred]

I have some ideas and would love to get involved! Also involving a few of the reviewers here based on some of our discussions at KubeCon... and including @alenkacz, @kensipe, and @zen-dog. Additionally, I'm directly summoning @shawn-hurley, @dmueller2001, @chris-short, @mhrivnak, and everyone else who was at our round table.

KUDO is already participating in an open governance model. The @kudobuilder governance needs to chime in here as well, but how does everyone on the Operator Framework side feel about making KUDO another subproject within the Operator Framework umbrella? This umbrella then covers many ways to build APIs on top of Kubernetes, and choices for building controllers. This unit could then enter the CNCF together as a set of toolkits and runtimes, as well as a set of standards (KOI, OLM) that other tools can use to promote interoperability between these tools.

This might be a little bit messy at first as we sort out this pile of ideas, but with a shared governance there we can all be empowered to distill these ideas into a great, coherent suite of tools that solve different aspects of this problem. In the future, we could bring integration opportunities forward to kubebuilder and metacontroller too, but Operator SDK and KUDO seem like a good place to test these ideas out, as you could argue Operator SDK is to kubebuilder as KUDO is to metacontroller. Lots of nuances and definitely very obvious differences here, but I think the analogy works well enough for the benefits of what I'm proposing.

If there's some agreement - at least around unification of effort, and understanding that we all have the intent to separate out a project that we all intend to donate tooling to, I would recommend:

• Add gerred to chairs (I'm open to someone else from KUDO, but I'm happy to begin shepherding this process along).
• Add the current KUDO core team to members

As well as generalizing (as mentioned by @ecordell) any company-based titles to the Operator Framework equivalent roles that would exist in the CNCF or other open governance environments.

Additionally, I might recommend that Operator SDK, OLM, KOI, and KUDO become referred to as "sub-projects" with their own respective leads. If so, we might want to consider shrinking the number of Operator Framework chairs and follow a Kubernetes-like model of having every subproject report back into the primary project.

If this were the case, I'd suggest the following subprojects:

1. Operator SDK
2. KUDO
3. Integrations (OLM + KOI)
4. Operator Hub

I've also suggested in a subsequent comment that we separate out kuttl for usage by the whole project, which may be worth spawning into an infrastructure / testing / certification working group.

Looking forward to working with everyone!

[gerred]

Phew, that ended up being a bit of word salad there, it was a little hard to capture the nuance of what I wanted to write. Hopefully everyone got the core ideas.

[gerred]

Also - I think it may be worth including an infra or testing working group / subproject here, since https://github.com/kudobuilder/kuttl is being abstracted out of KUDO's test harness now for more generalized test grid use for operators. cc @jbarrick-mesosphere

[robszumski]

@gerred Thanks for the proposal, sorry about the late respond. This got caught in the Thanksgiving email pile.

how does everyone on the Operator Framework side feel about making KUDO another subproject within the Operator Framework umbrella?

I feel good about that.

I've also suggested in a subsequent comment that we separate out kuttl for usage by the whole project, which may be worth spawning into an infrastructure / testing / certification working group.

I am super excited about a common testing framework. It's key to high quality.

How about we kick off this process in early January?

[gerred]

Sounds great! I'll be at the next SIG meeting as well.

[dmesser]

@gerred That sounds great to me. I added you as a chair to this proposal. Let's connect on kuttl, I am interested to find out more about this.

[dmesser]

After discussing with @gerred we concluded, that he would be a chair in this project. We will use this as a starting point for collaboration on how to adopt or incorporate some of the ideas and tools that KUDO has into the Operator Framework.

[gerred]

Hi all,

I just wanted to take the time to clarify a few things as I have received some questions about my earlier proposal. As merged under the Operator Framework governance and as raised by @robszumski and @dmesser in a meeting, KUDO is not at this time merging with Operator Framework. However, I have joined the governance of Operator Framework and am looking forward to working together as an equal chair in the project, enabling the OF governance to proceed in a multi-company governance manner. KUDO members are also involved in the Operator Framework and will continue to do so. We look forward to Operator Framework, and other members of the Cloud Native community to join KUDO's governance model in the future.

Operator Framework team members are additionally working on ways for KUDO and KUDO ecosystem projects to work together with the Operator Framework. The KUDO team has committed to working with the Operator Framework team to find out ways to enable inter-operability between operators, no matter how they are written, enable common distribution methods, and enable operator developers and end users to have better metrics and test results to determine the production readiness of an operator for a given use case.

KUDO, as an operator development project, focuses principally on building operator ecosystems that work well together, and building operators that enable users to quickly build operators for complicated, stateful services using tools native to their ecosystem. Operator SDK provides a model for developing operators that KUDO operators can consume as a dependency. In other words, KUDO is primarily an orchestration tool and Operator SDK is a development tool, and while both of these can perform the others' tasks, they excel in different settings - the end result of both being an operator. Neither of these projects directly compete with each other, with KUDO exploring a problem space that is very much in the early stages of being defined in the wider community.

That said, we all have a lot of tools in our toolbox, and some overlap with each other. As a chair for OF and KUDO, and someone heavily involved in SIG App Delivery and the Operator Working Group, we need to work in a way that helps coordinate many different operator projects together that is inclusive and advances the state of workloads on top of Kubernetes. As of right now though, this is a problem for future us and the best we can do is make sure that we are building an ecosystem / landscape, not individual projects.

Thanks all!