Multiple gateway providers in the same cluster

[eguzki]

For me the gateway provider should be per gateway basis instead of per kuadrant instance basis. The gateway, represented by the Gateway API's Gateway resource, should specify the provider. Actually, the gatewayClassName was intended for that. I think that the kuadrant control plane should rely on attributes read from the gateway to know how to configure it. If the gatewayClassName is not enough, maybe kuadrant can define some label/annotation that must be in the gateway object to have kuadrant configure it for rate limiting and auth.

For me this is the most flexible way. Less prone to errors like trying to configure gateways with some provider specified in the Kuadrant CR and the actual provider is other one.

I do not know if it is a real use case, but kuadrant might be configuring multiple gateways managed by different gateway providers at the same time.

[guicassolato]

@eguzki

For me the gateway provider should be per gateway basis instead of per kuadrant instance basis. The gateway, represented by the Gateway API's Gateway resource, should specify the provider. Actually, the gatewayClassName was intended for that. I think that the kuadrant control plane should rely on attributes read from the gateway to know how to configure it.

The gatewayClassName is just the name of a GatewayClass resource, so we'd need to read this other resource. Unfortunately the only thing that the GatewayClass resource guarantees is another field called controllerName, which may or may not give enough hint to infer the provider.

If the gatewayClassName is not enough, maybe kuadrant can define some label/annotation that must be in the gateway object to have kuadrant configure it for rate limiting and auth.

An annotation containing the info we need to infer the provider is a valid approach; likely that would be in the GatewayClass instead of each Gateway, since all gateways under a same GatewayClass must be implemented by the same provider.

[This actually gives me another idea...]

For me this is the most flexible way. Less prone to errors like trying to configure gateways with some provider specified in the Kuadrant CR and the actual provider is other one.

You raise a good point here. By just dumping a list of gateway providers in the Kuadrant CR (as I originally proposed), we get nothing that tells us which gateways are provided by each provider. It may suffice to inject configurations that apply to the entire provider, but not enough to cover occasional differences between providers when configuring the gateways themselves.

[...and this is the idea:]

So perhaps a couple improvements to this proposal could be:

1. Instead of listing "gateway providers" in the Kuadrant CR, users could list GatewayClass resources;
2. All Gateway resources referring GatewayClasses listed in the Kuadrant CR are to be managed by Kuadrant (cluster admins can always create more GatewayClasses to split the sets of gateways that will be managed by Kuadrant from others the won't);
3. Together with each GatewayClass referenced in the Kuadrant CR, the user would also provide the additional reference to the provider.

I do not know if it is a real use case, but kuadrant might be configuring multiple gateways managed by different gateway providers at the same time.

I don't think this is possible as definition enforced by the gatewayClassName, which always points to one provider.

[eguzki]

I don't think this is possible as definition enforced by the gatewayClassName, which always points to one provider.

I was referring to having multiple gateways with a different class (i.e. different provider). For example, one managed by Istio while other managed by, let's say, Gateway Envoy control plane.

[guicassolato]

I don't think this is possible as definition enforced by the gatewayClassName, which always points to one provider.

I was referring to having multiple gateways with a different class (i.e. different provider). For example, one managed by Istio while other managed by, let's say, Gateway Envoy control plane.

My point was that the name of the class itself may not be enough to infer the kind of the provider.