Implementations should report when a gateway name is too big

[rikatz]

What would you like to be added:
A new Gateway condition, and a new conformance test that signals to the user when a name of a gateway is too big.

Why this is needed:
On our In Cluster GEP spec (https://gateway-api.sigs.k8s.io/geps/gep-1762/?h=cl#automated-deployments) we specify that the generated name of resources "SHOULD name all generated resources my-gateway-example (-).".

This causes problems on parts of the child resources that has limits on size (eg.: generated labels, service names, etc).

While we cannot add a restriction here, as it will become a breaking change, we need to provide our users a better experience to understand that a cluster may not be provisioned because the sum of a Gateway name and a gateway class name are too big.

Some ways of implementing it:

• Having a VAP on the metadata.name of a Gateway that, when a sum of the length ".metadata.name + .spec.controllerName" > 63, block the creation - This can be breaking change for implementations that do not generate a child resource, so may not be the way to do it
• Specify a new test or a new condition that says "when the size name + controller name violates the 63 limit, add a condition on a Gateway that this MAY be a problem"

Other ideas are welcome

[robscott]

Having a VAP on the metadata.name of a Gateway that, when a sum of the length ".metadata.name + .spec.controllerName" > 63, block the creation - This can be breaking change for implementations that do not generate a child resource, so may not be the way to do it

Do you mean .gatewayClassName here?

Specify a new test or a new condition that says "when the size name + controller name violates the 63 limit, add a condition on a Gateway that this MAY be a problem"

I think I'd personally be in favor of a new conformance test that tests the max length of all GW API resource names to see what happens. Currently we're just relying on the default CR validation in k/k, which I believe is 253 chars (1, 2).

[youngnick]

Agreed that we should have a conformance test in the end, since we should be making sure that things that are too long don't cause the system to block, panic or whatever.

In a couple of places in Cilium, we have code that detects if things are going to be too long, and does a truncate-plus-checksum style thing instead.