Cache metric names provided by KEDA Metrics Server

[zroubalik]

Signed-off-by: Zbynek Roubalik zroubali@redhat.com

Cache metrics provided by KEDA Metrics Server instead of requesting list of all ScaledObjects in the cluster, this should reduce the load on k8s server and Metrics Server should respond much faster.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Changelog has been updated

Fixes #2156

Potential fix for: #1937

[zroubalik]

/run-e2e

[JorTurFer]

LGTM!

[JorTurFer]

Should we add a note in the docs explaining this?
I mean, maybe in the KEDA metric server section where we explain how to query metric directly, we could write a short note. We are caching the metrics, IDK if in any case we could have any worng metric exposed there.

[zroubalik]

Should we add a note in the docs explaining this? I mean, maybe in the KEDA metric server section where we explain how to query metric directly, we could write a short note. We are caching the metrics, IDK if in any case we could have any worng metric exposed there.

This change is just introducing a caching of the metric names that are provided by KEDA Metrics Server, not the actual metrics (values). It is internal change, so I am not sure that it is worth documenting. But I am open to do that if we all agree.

[JorTurFer]

I don't have a strong opinion about it, I was just sharing my thoughts :)

[coderanger]

Looks good to me overall, just a few micro-optimization thoughts because I'm a terrible person :)

[zroubalik]

/run-e2e

[zroubalik]

/run-e2e

[zroubalik]

@ahmelsayed PTAL

[arschles]

@zroubalik LGTM. do you think it's worth wrapping the slice pointer and its lock into a separate struct? might make for easier-to-follow code later on, and reduce the likelihood of concurrency bugs down the line. I'd be happy to do that in a follow-up if you like.

[zroubalik]

@zroubalik LGTM. do you think it's worth wrapping the slice pointer and its lock into a separate struct? might make for easier-to-follow code later on, and reduce the likelihood of concurrency bugs down the line. I'd be happy to do that in a follow-up if you like.

@arschles I was thinking about similar approach, but not sure if it doesn't introduce additional complexity. But I am no strongly opposed to this.