Description
We had a TCPRoute and UDPRoute controller in our previous Golang-based control-plane. The purpose of this task is to add controllers for these types (and GatewayClass
and Gateway
) into our new Rust control-plane.
However, as we are preparing to implement the Service API we probably do not want to build discrete controllers for this as TCPRoute
, UDPRoute
and Service
will have common data. Instead we should build more generic tooling for converting these types which can help support the eventual Service
implementation.
Additional Thoughts
For the library component I suggest that we create direct conversions of TCPRoute
and UDPRoute
to the types available in backend.rs. We may in fact need some higher level type that wraps those types. With that higher level type, we could implement From conversions for TCPRoute
and UDPRoute
. In this model, the controller workflow might be something like:
- ingest the resource from the API
- check the
Gateway
andGatewayClass
to validate this is a managed route - any additional validation needed to avoid side-effects
- pass off the
TCPRoute
orUDPRoute
to the new library described above, allowing the conversion to take place and then operating generically to update the data-plane thereafter.
One additional side benefit of the above is that when we implement the Service API later we may be able to implement a From
for Service
as well and reduce how much new code needs to exist to implement that API (though, Service
does some additional stuff so... it will likely have a lot of it's own isms).
Note: This is just a suggestion. If there end up being some difficulties or generally good reasons not to do this, no sweat.
Sub-issues
Metadata
Metadata
Assignees
Labels
Type
Projects
Status