What would a reference implementation control plane look like?

[alecholmez]

Let's spark some discussion here so we can get the communities thoughts.

What would a reference implementation control plane look like? What are some common features/functionality people would like to see supported here?

Things to Keep In Mind

Just some things to keep in mind:

• Let's design this in a way it's not REQUIRED to use, but there for people who need it
• Focus on common functionality that is repeated throughout the industry (service discovery on k8s, health checking, circuit breaking, etc...)
• It's okay to assert some opinion, but lets make this as generalized as possible so consumers inherit the benefits of the project without tying themselves to existing products

Resources

Matt Klein's blog post is a great read for those who haven't seen it.

[jpeach]

Matt Klein's blog post is a great read for those who haven't seen it.

What's the relationship between the ideas here and xds-relay (which seems to be abandoned)?

[ghost]

I think it would look a lot like https://github.com/3scale-ops/marin3r . I've been using it for a while now and it's robust.

[alecholmez]

Right so xds-relay wasn't a control plane. It was more of a shim/translation layer if I understood that project correctly.

I imagine we can set standards in this project for service mesh capabilities that are common across all projects. Service discovery is a good example here. We could design a basic service discovery mechanism for kubernetes. One thing this would lead to would be interfaces/modules that we can use internally to our caching mechanisms. I think we should leave the caches generic in a way where they can operate independent, but features like that might make sense to move upstream