Request for new repo: sigs.k8s.io/blixt

[Shane Utt]

Hi everyone,

In the Gateway API community we have historically not had a vendor-neutral implementation to run conformance tests on new PRs. Several community members have been working on https://github.com/kong/blixt as an example/testing implementation which is vendor neutral by way of building a data-plane from scratch (Linux/eBPF). We've been tracking this across several community meetings and it has broad support as well as several contributors from the SIG Network community. My company (Kong) has agreed to donate the repository to Kubernetes SIGs for this purpose.

At present the current proposed scope of this project is:

- provide Layer 4 functionality (GatewayClass, Gateway, UDPRoute, TCPRoute)

- provide a sigs owned implementation to plug into Gateway API CI to run conformance on PRs (we don't have this today)

- provide a reference/example control-plane implementation for future Gateway API implementations and for demonstration purposes

In addition to that scope, we are hoping for several side benefits:

- having fun: this project was very much intended to be fun for community members interested in experimenting with eBPF and learning Gateway API

- help to inform how Layer 4 support in Gateway API should work before we release them as beta as we've had little feedback from current implementations and we felt a practical approach like this could help us provide feedback to ourselves

- help improve Rust support in the Kubernetes ecosystem

- help improve eBPF support in the Kubernetes ecosystem

It should be noted that we consider any kind of production use for this project out of scope, our intention today is to support only testing type environments like kind and minikube to the extent that we can implement Gateway API conformance for it. We want to take an explicitly different path than the NGINX ingress controller in terms of how it is supported.

As such we would like to formally request a migration from https://github.com/kong/blixt to sigs.k8s.io/blixt so that we can continue building this as a Gateway API sub-project.

Thanks!

Shane

[Tim Hockin]

Do we have any other repos?

Does this aim to handle Services, too? How does it co-exist with
something like Cilium or kube-proxy?

> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/a9239171-8d60-45b7-83fe-14b935d9cdcfn%40googlegroups.com.

[Shane Utt]

> Do we have any other repos?

Other repos for this exact purpose, or what do you mean?

> Does this aim to handle Services, too?

No we're interested in ingress traffic, and not interested in implementing Service.

> How does it co-exist with something like Cilium or kube-proxy?

This project is meant for conformance testing and to be an example, it's not intended to be used in any production environment.

---

Given the questions it would seem the scope isn't entirely clear, we really want this to be predominantly for:

- Gateway API conformance testing
- Gateway API reference implementation

We're building it right now so that it only works in a kind cluster, we wont enable/support production use cases.

Rob actually suggested that if we renamed it something like gateway-api-implementation-example or something like that this could help to instantly clear up any confusion. Ideally we would not want to have to change a project's repository name in order to signal it's support level, but hopefully that suggestion itself helps to provide more clarity.

[Antonio Ojea]

a generic name may be handy later , so we avoid creating new repos

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/561d902b-c4ee-432b-b849-9d44843cef7bn%40googlegroups.com.

[Tim Hockin]

On Wed, Nov 16, 2022 at 6:27 AM Shane Utt <sh...@konghq.com> wrote:
>
> > Do we have any other repos?
>

> Other repos for this exact purpose, or what do you mean?

Sorry - my fingers missed a word. Do we have other rust repos? I'm
worried that we have tooling which comprehends Go-isms but not obvious

> > Does this aim to handle Services, too?
>
> No we're interested in ingress traffic, and not interested in implementing Service.
>
> > How does it co-exist with something like Cilium or kube-proxy?
>
> This project is meant for conformance testing and to be an example, it's not intended to be used in any production environment.
>
> ---
>
> Given the questions it would seem the scope isn't entirely clear, we really want this to be predominantly for:
>
> - Gateway API conformance testing
> - Gateway API reference implementation
>
> We're building it right now so that it only works in a kind cluster, we wont enable/support production use cases.
>
> Rob actually suggested that if we renamed it something like gateway-api-implementation-example or something like that this could help to instantly clear up any confusion. Ideally we would not want to have to change a project's repository name in order to signal it's support level, but hopefully that suggestion itself helps to provide more clarity.

I do think "example" or something makes it clear that this is not for
production use, but I won't hold up on that alone.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/561d902b-c4ee-432b-b849-9d44843cef7bn%40googlegroups.com.

[Shane Utt]

> Do we have other rust repos?

I don't believe that we do. If you try and filter on language at the org level, there's no repositories that are marked as Rust (unless there's some Rust hiding within one of them).

[Rob Scott]

First off, I'm excited about this project and how it will help us with both Gateway API conformance and L4. A big thanks to Shane for getting this going.

With any new repo I'm always concerned about scope creep. So I think it's important to clearly identify the intended scope of the project as a Gateway API reference implementation limited to L4. We also need to clearly document that there are no security or support guarantees and that the only intended use case is running conformance tests. 

So far this is entirely dependent on running on kind, but if we ever reach a point where we no longer have that dependency, we could add some kind of mechanism that automatically shut off after some period of time to ensure it really never was run in production.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAJQFyH%3DT9hkFC%3Dygzh3RMnzprz5wg6J5OoHY6pqsLbGqRtbUXg%40mail.gmail.com.

[Tim Hockin]

I don't want to sow FUD, I'm mostly asking because I expected the
answer was "no, we don't" and I don't know what might go wrong. Maybe
nothing.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAJQFyH%3DT9hkFC%3Dygzh3RMnzprz5wg6J5OoHY6pqsLbGqRtbUXg%40mail.gmail.com.

[Andrew Stoycos]

> With any new repo I'm always concerned about scope creep. So I think it's important to clearly identify the intended scope of the project as a Gateway API reference implementation limited to L4. We also need to clearly document that there are no security or support guarantees and that the only intended use case is running conformance tests. 

+1 I think we could definitely provide some built in mechanism to facilitate this.

> I don't want to sow FUD, I'm mostly asking because I expected the
> answer was "no, we don't" and I don't know what might go wrong.  Maybe
> nothing.

IMPO the other huge benefit of this project (aside from the obvious utility it provides to the GatewayAPI folks) is that it gives us the chance to explore/pave the way for using new techs (ebpf, Rust, etc) in kubernetes-sigs. So yeah things may go wrong at first but I think that's probably a good thing :)

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAO_Rewa3a%3DOz7Y90ikxt12CYzHuveh__vOrW-SUgses%2BLOQpRQ%40mail.gmail.com.

--

Andrew Stoycos, OCTO 

Senior Software Engineer Red Hat

(910) 620-5964 

ast...@redhat.com

[Shane Utt]

I'm fine with adding a builtin mechanism to literally stop people from using this in production as opposed to asking them not to. +1

[Nick Young]

I'm fine with adding the new repo, but I agree that big warnings about not using in production, along with some mechanism (shutdown after an hour or something?) would be a great idea.

I think that we won't find out if we have Go-isms in tooling until we do something that's not Go, and at least this is a low-impact experiment.

So, I'm +1 overall.

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAJQFyHm1Cy%2BxNjNGYSQ8oPsNs9-Hu47y9vzNMkiLowA%3DU9ysFw%40mail.gmail.com.