gateway.listeners: make optional

[howardjohn]

What type of PR is this?
/kind api-change

What this PR does / why we need it:
This changes listeners field to be optional (i.e. allow 0 length list).

The motivation here is that a Gateway actually provisions underlying infrastructure. This can take a long time, too, depending on the set.
It may be useful to initially provision a Gateway with
zero listeners, and then later add them.

This PR loosens validation to allow not configuring any listeners, with the expectation that underlying infra would be provisioned, then a user would add specific listeners.

Does this PR introduce a user-facing change?:

Gateway.Spec.Listeners field is now optional

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: howardjohn
Once this PR has been reviewed and has the lgtm label, please assign caseydavenport for approval by writing /assign @caseydavenport in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hzxuzhonghu]

The motivation here is that a Gateway actually provisions underlying infrastructure.

Isn't gatewayClass that does provision?

[howardjohn]

Gateway class just says what controllers are installed (more or less). Gateway is an actual instance of the infra

[robscott]

Need more time to think about this, but I think it's too big of a change for v0.6.0, adding a hold on this until we get that released.

/hold

[shaneutt]

I'm not opposed to this, but I do have some general questions about the use case: it sounds like the intention here is to allow a CREATE followed by an UPDATE to add the Listeners after the Gateway becomes Ready=True, is that accurate? Can you help me to better understand the dilemma? What would be the downside of requiring the Listeners but then having the controller implementation wait until the underlying provisioning reaches a point where it can accept listeners before eventually applying those listeners, and then calling the Gateway Ready=True last? It seems to me that it would overall be better to not have the Gateway marked as Ready=True until it has listeners ready?

[howardjohn]

The dilemma is the person applying the gateway doesn't actually know what listeners they want until a later time, so they would have to put some dumny listeners if they wanted to do that.

…

On Tue, Dec 13, 2022, 6:38 AM Shane Utt ***@***.***> wrote: I'm not opposed to this, but I do have some general questions about the use case: it sounds like the intention here is to allow a CREATE followed by an UPDATE to add the Listeners after the Gateway becomes Ready=True, is that accurate? Can you help me to better understand the dilemma? What would be the downside of requiring the Listeners but then having the controller implementation wait until the underlying provisioning reaches a point where it can accept listeners before *eventually* applying those listeners, and *then* calling the Gateway Ready=True last? It seems to me that it would overall be better to not have the Gateway marked as Ready=True until it has listeners ready? — Reply to this email directly, view it on GitHub <#1596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXP5JJRNOVAOEX2ZDLLWNCC75ANCNFSM6AAAAAAS4SI54A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hzxuzhonghu]

That can make the ready not really ready if a listener can be updated later

[howardjohn]

observedGeneration handles the fact that status and spec may be out of sync, I am not sure this changes that? The same applies when changing from 1->2 listeners

…

On Tue, Dec 13, 2022, 8:23 PM Zhonghu Xu ***@***.***> wrote: That can make the ready not really ready if a listener can be updated later — Reply to this email directly, view it on GitHub <#1596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXO3HFQK5UURLOHXW2TWNFDURANCNFSM6AAAAAAS4SI54A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[robscott]

@howardjohn I think I see the value of pre-warming infra whenever it's possible, but have a few questions:

1. Why not just provision a Gateway with a dummy listener and change it later? If the infra you're provisioning is a Service type=LB, wouldn't you need to specify ports there?
2. What would this mean for conformance? Not every implementation is going to be able to provision infrastructure without ports/protocols specified?
3. Are there other use cases a Gateway without listeners would enable?

[shaneutt]

@howardjohn looks like we have some outstanding questions here, let us know if you need anything from us in order to move this one forward 🖖

[howardjohn]

1. Why not just provision a Gateway with a dummy listener and change it later? If the infra you're provisioning is a Service type=LB, wouldn't you need to specify ports there?

Exposing a dummy port on public internet doesn't seem like a good idea and maybe conflict with security guidelines, etc. There is also a difference between "No listener" and "Listener without routes" (not to mention risk of accidentally attached routes)

2. What would this mean for conformance? Not every implementation is going to be able to provision infrastructure without ports/protocols specified?

I think like many other fields - implementation specific. We can declare regardless of support they should report status properly ("scheduled" but 0 listeners, or "not scheduled") .

3. Are there other use cases a Gateway without listeners would enable?

Yes, we want to use Gateway to deploy instances of waypoint proxies in ambient mesh. These have an implicit listener that isn't reliable to represent as a listener ("all protocols on all ports"), but also allow users adding explicit listeners using standard GW mechanism (ie port 443 HTTPS with some cert). Requiring a listener is fitting a square peg in a round hole and adds complexity for the user.

[youngnick]

Coming back to this one, I should note that changing a previously required field to optional is a breaking API change, sadly. In this case, controllers can currently expect the slice to have at least one entry, changing that is a breaking change. And breaking changes are supposed to have an API revision bump.

I don't necessarily think this is impossible, but I think it would need something to run through the use cases in different deployment models (what should an ingress controller like Contour or Emissary do with an empty list? Should it be accepted? And so on).

@howardjohn What would you like to do here?

[howardjohn]

I think at this point it may make sense to close this