Shipping with an embedded GW API provider #18
Conversation
| - including _howtos_ on how to "chain" existing ingress'es with gateway resources | ||
| - [ ] Abstract the Gateway Provider behind an [Service Provider interface (SPI)](https://en.wikipedia.org/wiki/Service_provider_interface), to support at least Envoy GW, Istio & OSSM. | ||
| - which makes for a clear contract any other Gateway API provider would be able to implement | ||
| - [ ] Package different distributions (at the very least GW API included, or pluggeable) as different Operators/images? |
There was a problem hiding this comment.
so would the idea here be to support go plugins https://pkg.go.dev/plugin and have the provider configured at install time a loaded at dynamically? Would our default impl also be plugins or just packaged as part of the operator?
There was a problem hiding this comment.
on another note I haven't ever used a go plugin but in theory sounds like it would work for this use case. That said I think we could provide an interface and default implmentations without plugins (IE like a provide factory) that returns the right impl based on config and then add support for loading a plugin at a later stage? Not sure if we want to do plugins for all implementations?
There was a problem hiding this comment.
I'd say that'd depend on "how big" these become… And how we'd even plug the default Gateway API provider (i.e. probably Envoy Gateway) in. I think, from a end-user's perspective, I'd lean towards one single operator image that just "does the right" thing. No Gateway API present? Go fetch and install our default provider; Or, we;re in an OSSM environment? Loads the appropriate SPI (possibly using the go plugin - which I guess are effectively a dlopen(3) kinda thing; or "just" using a factory indirection; or whichever…) and it all works.
I'll look into go plugins, but at this stage I mostly care about the definition of the contract between Kuadrant and these providers, to be defined in this/these SPI(s). And if we can then also easily accept contribution to support "yet another Gateway API provider", then great! If that is more complicated, supporting go plugins would be another way to decouple Kuadrant from the providers, all the way to the runtime, creating an even more open architecture for these extensions.
|
👍 to the intro written so far. |
Trying to lower the bar to entry into Kuadrant… if only until all k8s clusters out there have Gw API installed (using Envoy) 😜