remove minItems limit of listeners in gateway

[woodgear]

What would you like to be added:
remove minItems limit of listeners in gateway.
Why this is needed:
we are currently to impl a web ui for gateway-api, a common case could be

1. create a gateway (via admin)
2. add or delete arbitrary listener in it later.
   when a gateway must have atleast one listeners, it had to decide which listener shoud be add on createing gateway. and must delete the gateway when want to delete the last listener in it.

[howardjohn]

Prev discussion in #1596

[shaneutt]

Given #1596 (particularly, #1596 (comment)) it doesn't appear we could move forward doing this without a full API revision which would be painful. We can see why this is useful, but the requirements for the change make it difficult. @woodgear what do you think about us defining some sentinel values as a workaround (e.g. something that indicates a listener that is meant to be ignored) would this be adequate for your web UI to provide the display you're hoping for?

[sdjksdajshd]

@shaneutt If we decide to do this, should the sentinel values be created by the front end or generated by the back end? I hope this is clear, to avoid confusion when accessing different classes.

[shaneutt]

@shaneutt If we decide to do this, should the sentinel values be created by the front end or generated by the back end? I hope this is clear, to avoid confusion when accessing different classes.

If by front-end you mean the UI, then I think I would assume the back-end (the actual Gateway API implementation) would make this? But it's certainly open to debate since this is just an early concept on how to solve the problem without having to go through a full API revision.

[robscott]

I'd echo other comments from the previous issue (#1596) that this would be a breaking change and I don't think we can justify that here. Any change like this would require significant work for implementations. All implementations I know of today would require at least one listener to be present due to mapping to underlying load balancing infrastructure or a Service LB. If we introduced a state that didn't have that, it would be pretty messy to handle for every implementation and would risk breaking implementations that did not handle it before updated CRDs were installed in the same cluster.

Is there any reason the UI can't just suggest a default listener? Maybe 80 on HTTP? Could always be modified later if needed.

[sdjksdajshd]

As a platform ops who manage a lot of infrastructure，I create Gateways for application team（in many private cloud，application ops need apply for gateways from platform ops） ，I have no authority and reason to create a listener for gateway.

Either UI or the actual Gateway API implementation is OK.

@robscott @shaneutt

[shaneutt]

So it would seem (though @woodgear it would be good if you could chime in here too) that having a placeholder listener could be doable for this case. So the question then would become: can your implementation just start doing that in a way that works for it now, or is there need for this to be a standard where we document some known placeholder value as an option for situations where a Gateway would not have an active listener (but would otherwise be valid, perhaps waiting for configuration)?