Enhancement: Cache health groups and expose endpoint to fetch them

[cdprete]

Hello.

This ticket wants to be a follow up of the (partial) fix provided with #5298.

As discussed in there, the solution provided doesn't solve the N+M (N instances of the UI open, M instances of SBA server available) calls to the health endpoint completely, but it just reduces it.
In #5298 (comment) has been described a potential solution to this which doesn't imply changing the model of the STATUS_UPDATED event (even if personally I would, because it's way simpler and more manageable) and this ticket is here to implement it as requested by @ulischulte in #5298 (comment).

[ulischulte]

Hello.

This ticket wants to be a follow up of the (partial) fix provided with #5298.

As discussed in there, the solution provided doesn't solve the N+M (N instances of the UI open, M instances of SBA server available) calls to the health endpoint completely, but it just reduces it. In #5298 (comment) has been described a potential solution to this which doesn't imply changing the model of the STATUS_UPDATED event (even if personally I would, because it's way simpler and more manageable) and this ticket is here to implement it as requested by @ulischulte in #5298 (comment).

Thanks for opening this issue, @cdprete!
Just to clarify - I didn't request that specific implementation. I just requested to keep it out of that PR's scope and to track it as a separate follow-up — which is why I suggested opening this issue. So the feature idea and the proposed implementation approach are @cdprete's (#5298 (comment)). I just requested the issue be opened to track it separately.

Thanks again for the thoughtful suggestion and for offering to contribute the backend change!

[cdprete]

Hello.
This ticket wants to be a follow up of the (partial) fix provided with #5298.
As discussed in there, the solution provided doesn't solve the N+M (N instances of the UI open, M instances of SBA server available) calls to the health endpoint completely, but it just reduces it. In #5298 (comment) has been described a potential solution to this which doesn't imply changing the model of the STATUS_UPDATED event (even if personally I would, because it's way simpler and more manageable) and this ticket is here to implement it as requested by @ulischulte in #5298 (comment).

Thanks for opening this issue, @cdprete! Just to clarify - I didn't request that specific implementation. I just requested to keep it out of that PR's scope and to track it as a separate follow-up — which is why I suggested opening this issue. So the feature idea and the proposed implementation approach are @cdprete's (#5298 (comment)). I just requested the issue be opened to track it separately.

Thanks again for the thoughtful suggestion and for offering to contribute the backend change!

Hi @ulischulte.
I meant you requested to open the follow-up ticket.
Sorry if the way it's formulated may have sounded confusing.

[cdprete]

Another solution would be to expose them over the metadata and, if they're missing in there, fallback to their fetching and caching when the status/health of an instance changes.