Rust ControlPlane: GatewayClass Controller

[shaneutt]

The purpose of this task is to create a GatewayClass controller in Rust. This controller is very simple, pretty much only marking the GatewayClass as accepted or not based on ControllerName.

See the Go version of this for reference: https://github.com/kubernetes-sigs/blixt/blob/archive/golang-control-plane/controllers/gatewayclass_controller.go

TODO

• [ ] Create a GatewayClass controller that marks managed GatewayClass resources as accepted
• [ ] Update the Gateway controller to verify that any GatewayClass is accepted before programming routes
• [ ] Add integration tests for GatewayClass and Gateway which mirror our previous Golang-based tests

[nayihz]

I am a beginner in Rust. If possible, I'd like to give it a try.

[shaneutt]

Thank you @nayihz but at the moment this one already has an owner and is in progress. Please feel free to check out other issues which don't have assignees, and in general if you're just starting Rust but you'd like to do something practical, I can definitely recommend the Rust By Example Book!

[EandrewJones]

I also strongly the "Rust in 4 Days" course by the google android team: https://google.github.io/comprehensive-rust/

I worked through that (admittedly over more than 4 days) before touching anything in this code base.

Best

Evan Jones Website: www.ea-jones.com

On Fri, Dec 6, 2024 at 4:30 AM Shane Utt @.***> wrote:

Thank you @nayihz https://github.com/nayihz but at the moment this one already has an owner and is in progress. Please feel free to check out other issues which don't have assignees, and in general if you're just starting Rust but you'd like to do something practical, I can definitely recommend the Rust By Example Book https://doc.rust-lang.org/stable/rust-by-example/!

— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/blixt/issues/300#issuecomment-2523116139, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2T6AKJ6UNXOQDPH54CUN32EGKGJAVCNFSM6AAAAABQZWKVUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRTGEYTMMJTHE . You are receiving this because you were assigned.Message ID: @.***>

[EandrewJones]

@shaneutt Happy new year 🥳

Is there any other validation we should perform prior to acceptance?

I ask because in the docs there's an example of a failed acceptance state, but the docs are unclear about the conditions that might lead to failure.

[shaneutt]

We should try to do the following to validate the work here:

1. run any tests that are relevant in the Golang test suite and see if they're still passing.
2. validate any behaviors covered in the Gateway API conformance test suite

That said, as always with this project it's reasonable to take an iterative approach. If we can get some chunk done in one PR that has some of the validation we want, and is written in a way that is poised for additive iterations towards something more complete, that's fine too.

[EandrewJones]

Okay, I'll look at number 2 as the golden spec. Thanks.

[EandrewJones]

Flynn:

The failure states are dependent upon the implementation. For example, if linkerd sees a route where you have broken some linkerd rule (bad annotation, backendref pointing to something that does not exist). A route attached to a gateway you do not control, you cannot touch. For blixt, you must not touch routes where the parent is a service.

IF you have two gateways with exactly synonymous listeners, you may need to do something special (i.e failure state?)

Note to self: punt on conformance tests for this.

[shaneutt]

IF you have two gateways with exactly synonymous listeners, you may need to do something special (i.e failure state?)

Can you describe a bit further what you're anticipating is a problem here? My expectation is that two gateways with the same listeners would be fine, as they would carry a unique IP. I do think we'll need to disallow spec.addresses on our Gateways though at least at first, and we wouldn't do any kind of Gateway Merging (at least not at first).

[EandrewJones]

You'll have to ask Flynn. This bubbled up in our conversation and I wanted to capture the raw ideas in notes. We didn't flesh out details.

Best

Evan Jones Website: www.ea-jones.com

On Mon, Feb 3, 2025 at 4:39 AM Shane Utt @.***> wrote:

IF you have two gateways with exactly synonymous listeners, you may need to do something special (i.e failure state?)

Can you describe a bit further what you're anticipating is a problem here? My expectation is that two gateways with the same listeners would be fine, as they would carry a unique IP. I do think we'll need to disallow spec.addresses on our Gateways though at least at first, and we wouldn't do any kind of Gateway Merging https://github.com/kubernetes-sigs/gateway-api/issues/1713 (at least not at first).

— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/blixt/issues/300#issuecomment-2630834787, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJ2T6AKMYYN4GWHELBBAR432N5PPNAVCNFSM6AAAAABQZWKVUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZQHAZTINZYG4 . You are receiving this because you were assigned.Message ID: @.***>

[shaneutt]

/cc @kflynn !