Cleanup sleepers/wakers to encapsulate their scaling target

[itzg]

I'm also uncertain about this code in routesImpl.GetSleepers where several SleeperFuncs are obtained. It seems like that would cause the same scaling operation to be performed multiple times. The outcome is technically correct, but not optimal when a several hostnames map to the same server instance's service.

This was identified as part of #512

Important

This is a reminder for myself to do some refactoring of scaler, discovery, and router. Please do not contribute PRs to this issue.

[itzg]

Should address

#511 (comment)

[L-Wehmschulte]

Responding to our conversation in #511 (comment) since it makes more sense here. I'd be happy to implement a reworked API-design, if you'd be so kind to provide me with a concept

[itzg]

I appreciate the offer but it seems you didn't read the "important" notice. It's more than the API. I need to rework a lot of the internals since it has gotten convoluted after several contributions.

[itzg]

... @L-Wehmschulte if you want to squeeze in the identifier you need via the existing API, then you can proceed with that. Just be warned that I'll probably rip it out and rework it with the rest 😀

[L-Wehmschulte]

I did read the notice up top ofc, but I figured we continue the discussion in here since you've linked to my last comment above. Anyways. I have thought up two ideas:

1. just return the scalingTarget instead of the route for the kubernetes services
2. add an additional endpoint which would contain the scalingTargets instead of the backend as values for each host.

When you get around to your big refactoring, you're of course free to tear it down again 😅

Which route would you prefer? 1) is ofc a breaking change although I doubt that a lot of people are currently relying on that behavior as it is quite niche

lmk and also should I open a separate issue for this?

[itzg]

Let's see what option 1 looks like and see if it can be an additional field to minimize user breakage.

No need for a separate issue since we've talked here. Just put a mention in your PR to point here.