Including version in Gateway as extended conformance

[pmalek]

Just wondering what's community's take on adding version to Gateway as part of the extended conformance. version would designate the version of implementation to be used (i.e. a version of an image).

The idea behind this would be to decrease the reference chain with current possibilities (an object referenced by GatewayClass, which in turn is referenced by Gateway).

It does make sense for e.g. Kong's implementation, but we'd also like to gauge the support/need for such change from the community?

Would anyone be strongly opposed to putting such a thing into extended?

( Another possible field to consider would be the registry/image name to be used. Hypothetically, if that would also get traction then we might consider a different approach than solely with version )

[howardjohn]

What does it mean to have "version"?

[howardjohn]

Ahh. I see. In that case it seems like GatewayClass is the way to go. If GatewayClass is not sufficient for this use case it kind of suggests GatewayClass is not fit for purpose, since it was sort of intended for things like this...?

[pmalek]

You mean that we might consider extending GatewayClass with that field (as part of extended conformance) instead of Gateway?

[howardjohn]

It already has enough fields to add arbitrary info like this I think

[shaneutt]

I think there are some potential downsides with GatewayClass's ParametersRef: one being that you may need as many as a 1 GatewayClass for every Gateway if the configuration needs to be unique per Gateway (this is not uncommon in Kong's situation) and the other being that you then have to do several levels of object referencing in the controller to apply the configuration.

So far the configuration in Gateway.Spec has been held down to things which can be universally implemented (e.g. listeners/addresses), but if having things like version (just as an example) closer to the Gateway resource resonates with many implementations I would feel compelled to at least discuss it at some length and reconsider.

[howardjohn]

The version idea made me a bit uneasy (hence the comments), but I couldn't put my finger on why until now. This seems like a very specific solution to a small portion of the wider problem: how do I customize my underlying Gateway. This is especially a problem for in cluster implementations, which have possibly 100s of fields they want to customize. I thought we had an issue about this but I couldn't find it... #1355 is close-ish.

So I don't want to scope-creep this too much, but IMO we need to tackle the larger problem. We can handle a small portion first but it should be forward-compatible with a broader solution probably, which version doesn't really seem to meet? This is how Istio does it today fwiw: https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#deployment-methods - its not great, so would love improvements here.