Adds support to use regex with HTTP protocol in RabbitMQ Scaler

[JorTurFer]

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Changelog has been updated
• Tests have been added
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable) Update RabbitMQ Scaler documentation to include the option of use regex keda-docs#489

This PR adds support to use regex as a queue selector in RabbitMQ Scaller. With this changes, complex cases with more than 1 queue in the application topology are covered and can be scaled with RabbitMQ Scaler

Closes #743

[coderanger]

Could you explain the use case for this? Looks like your aim is to scale something consuming from multiple queues?

[JorTurFer]

Could you explain the use case for this? Looks like your aim is to scale something consuming from multiple queues?

Sure! For example, in our use case we have more than 1 queue (near of 70) that are consumed by one hub to do some stuffs. You can imagine it as a "central hub". In this case, you could need to scale in base of all the queues instaed 1.
RabbitMQ supports the use of regex when you are using the HTTP protocol, so I think it's not too strange case.

[coderanger]

Yeah, the use case seems reasonable just wondering the best way to expose it. This hardwires taking the highest values out of any returned queue which I think should probably be fine? Might be some use cases around "mean value" but nothing super obvious comes to mind. And we should make sure that activating it in AMQP mode is a hard error so we don't get silent "it's just not working" behavior.

[JorTurFer]

You are right, I will update the code to raise an explicit error in case of invalid configuration. Related with the max value or the mean value, I don't have any strong about this point, I did with max value because the rate can't be usable to get the mean value and the maximum yes.
What do you think if I add support only for message count (not for rate) and I support the operations sum, max y avg?
This can be well documented and raise an error in case of a wrong configuration to avoid silent errors. Probably it's more useful than my current design.

I don't have too much time so I will do little changes during the week. I will stay tuned to your comments :)

[JorTurFer]

Could you approve the CI workflow please? I think that is fixed (at least in my own repo)
https://github.com/JorTurFer/keda/actions/runs/1033020481

[rwkarg]

For multi-queue use cases, we add multiple triggers for each queue which will have the same behavior of scaling at the maximum queue size or publish rate, but it will expose each of the scaling metrics in the HPA (instead of the external metric server collapsing it to one metric for the HPA).

I don't know that the current setup would support querying the metrics by regex, reporting each of those metrics, then updating the HPA with a metric for each observed queue (or only when there's a change). This would give visibility through the HPA what metrics are being evaluated for scaling decisions.

[zroubalik]

LGTM

[JorTurFer]

Hi @zroubalik
I have requested your review again because I have done some changes in the code to allow use regex with messageRate mode. Sorry for the inconvenient :(
I have just updated the documentation as well :)

[zroubalik]

LGTM, @JorTurFer thanks for the contribution!