api: Update gateway status to include AttachedListeners

[davidjumani]

What type of PR is this?
Add one of the following kinds:
/kind gep

What this PR does / why we need it:
Updates the status of the Gateway to include AttachedListeners which is the count of successful ListenerSet attachments to the gateway. Ref: slack thread

Does this PR introduce a user-facing change?:

Adds the `AttachedListeners` conditions to the Gateway status which is the count of successful ListenerSet attachments to the gateway

[howardjohn]

I am going to take a contrarian point of view here and say maybe we shouldn't add this. AttachedRoutes, IMO, is an extremely high-cost status field to update with extremely little value.

Our implementation spends like 20% of its CPU calculating AttachedRoutes...

If we do decide to add it though, the PR itself LGTM

[rikatz]

@howardjohn regardless of the implementation detail (which I see your point and agree about the performance caveat), I am wondering that we need a way to let the Gateway owner know that there are some ListenerSets attached to the Gateway.

Do you suggest some different approach for it?

[howardjohn]

A ListenersAttached: bool instead of int is one approach that maybe could be acceptable tradeoff.

FWIW the implementation detail is not specific to any implementation, it necessarily at least doubles the number of status writes to the API server on a route creation/deletion.

[rikatz]

ok, seems reasonable.

@robscott @youngnick for some comments, we can change for a boolean instead. I think it is important for an admin at least to know something is attached to the gateway

[davidjumani]

A ListenersAttached: bool instead of int is one approach that maybe could be acceptable tradeoff.

Thanks @howardjohn - The AttachedListenerSets status condition should suffice if this is the case

[youngnick]

I'm sorry, but the fact that implementing something can be difficult for one implementation doesn't decrease the utility of the integer field for me.

I disagree that attachedRoutes is a low-utility field, having the number there is much closer to what would be the most useful (having a list of all the routes), while still being less loaded on the apiserver than a full list.

I am happy with the integer as it currently stands.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: davidjumani, youngnick

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [youngnick]

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

[howardjohn]

It's not "difficult for 1 implementation". It's expensive for all implementations. There is no possibile way to avoid an explosion of writes as each route triggers a listenerset write