Nit: The line length here feels inconsistent

so, mostly of these line breaks is because I have a horizontal ruler on 80 characters after someone told me I should work better on my line breaking abilities to make it better readable :)

That said, I missed this one so I will add a new proper break here but as we don't have any convention (I guess) I wouldn't mind that much on this

Sounds good, not too picky here. I personally try to wrap at 80 chars. I've also seen some folks successfully use the sentence per line approach, and I'm increasingly thinking that may be a good compromise here. In the Mesh GEP, @kflynn went a step further to use semantic line breaks. We're likely overdue to have some kind of standard for markdown in this project.

I tend to lean towards the following:

• 80 char wrapping for godoc comments
• Sentence per line wrapping for all markdown files

With that said, this should probably be turned into an issue/discussion for next steps.

(FTR I think the the Mesh GEP experiment was worth doing, but I think that the sentence-per-line approach is likely to be more practical.)

What should a Gateway implementation do with this? In the case where a Route is no longer accepted, is it supposed to drop it altogether? IE if you add a new parentRef that makes the Route invalid, do you drop the entire Route, or does the Gateway impl add something into status specifically for this ListenerSet?

Actually, did we cover how status is supposed to work here? Should we populate separate Route parent statuses for each ListenerSet and Gateway, or just the Gateway? cc @youngnick

The ListenerEntryStatus has an AttachedRoutes count. That should suffice for the listenerset side (at least for now)
I don't think the route should be dropped - if ListenerSets are an extension of the Gateway, then it should work as such - similar to what happens if a gateway parentref is invalid
The implementation could add something to the route status if needed

I think if you add a new invalid parentRef that breaks your HTTPRoute, it should be moved to Accepted=False as originally stated, and be unconfigured on the Gateway.

You are intentionally breaking your route, right? Let's remove the ListenerSet from the equation: what happens if you have a Route that is using a Gateway as a parentRef and then you change it to another Gateway but a sectionName doesn't exist on it?

oh, sorry, I just typed and saw your answer @davidjumani

So, the current behavior today is that the route is not dropped, and it gets something like invalid Parent ref on the status?

EDIT: anyway, as there are 2 different understandings here, I think it is a good callout of what should be done in this case. Will wait Nick to chime in, and we can disambiguate this case

In the case highlighted here, if a HTTPRoute references a sectionName on a parentRef that points to a ListenerSet, and there is no Listener in that ListenerSet with that name field set, then the HTTPRoute MUST fail to attach, regardless of what Listeners exist at the Gateway level.

That's what we agreed on earlier - to summarize:

• For considering Listener-Listener conflicts, you have to look at all Listeners, regardless of their source.
• For considering Route attachement, you only need to consider the listeners in the actual parent object (Gateway or ListenerSet). For Routes that attach to a Gateway, you don't need to care about what Listeners are in any ListenerSets, and for Routes that attach to a ListenerSet, you don't need to care about what Listeners are in the Gateway.

Maybe another way to say this that's more specification-like:

• Routes attach to all relevant Listeners in their direct Parent object.
• If a Route has a parentRef that is a ListenerSet, then the ListenerSet is the direct Parent.
• If a Route has a parentRef that is a Gateway, then the Gateway is the direct Parent.
• If the Route is using Gateway defaulting, then the default Gateway is the direct Parent.
• If sectionName is not set, then all Listeners in the direct Parent object are relevant, and the Route must attach to all of them (subject to any allowedRoutes criteria.)
• If sectionName is set, then only the Listener in the direct Parent object with the name field set to the same value as sectionname is relevant, and the Route must attach only to that Listener (subject to any allowedRoutes criteria).
• If there are no relevant Listeners (because, for example, a sectionName is specified that does not exist on the direct Parent), then the Route has nowhere to attach to and MUST be have Accepted set to false for that parentRef.

Route status is per-parentRef, so if a new parentRef is added, that attachment is independent of any existing parentRefs. A Route can be Accepted by one parentRef and not another, that's fine.

If you have a Route that has a Gateway parentRef with a sectionName, that is Accepted already, and you add another parentRef that points to a ListenerSet with a sectionName, and the ListenerSet does not include a Listener with a name matching the sectionName, then the ListenerSet parentRef must be Accepted status: false. That does not affect the Gateway parentRef.

To answer @robscott's original question, yes, we should populate status per-parentRef, no matter what the parent is.

That's a phenomenal summary, thanks @youngnick! Would love to see this incorporated into the GEP.

@robscott @youngnick I have copied Nick's text as is to the GEP, as I agree it is great and very clarifying, thanks!