[RabbitMQ] vHost is ignored when using regex

[crisp2u]

Report

We have a shared RabbitMQ instance with multiple vhosts and multiple deployments connecting to them and we get "Error":"error inspecting rabbitMQ: regex matches more queues than can be recovered at once"}
We use regex to scale our workers and looking at the code it seems that if useRegex is turned on the http call is not made using the vhost.

Relevant code is here

keda/pkg/scalers/rabbitmq_scaler.go

Line 429 in e851d8e

getQueueInfoManagementURI = fmt.Sprintf("%s/api/queues?page=1&use_regex=true&pagination=false&name=%s&page_size=%d", parsedURL.String(), url.QueryEscape(s.metadata.queueName), s.metadata.pageSize)

vs

keda/pkg/scalers/rabbitmq_scaler.go

Line 431 in e851d8e

getQueueInfoManagementURI = fmt.Sprintf("%s/api/queues%s/%s", parsedURL.String(), vhost, url.QueryEscape(s.metadata.queueName))

Because we run multiple instances of the same app the regex matches all the queues from all the vhost and the result exceeds the default pageSize of 100

The RabbitMQ Console is running the same regex filter using /api/queues/<<vHost>>?

Any workarounds for this ? I'm thinking increasing the pageSize but that will trigger all workers regarding of vhost. The other option would be to move to a dedicated instance.

Expected Behavior

Deployments should scale when using regex with multiple queues on a certain vhost

Actual Behavior

Deployments cannot scale because Scaler ignores vhost and the result match exceeds pageSize

Steps to Reproduce the Problem

See description

Logs from KEDA operator

{"level":"debug","ts":1642770893.2876174,"logger":"scalehandler","msg":"Error getting scale decision","Error":"error inspecting rabbitMQ: regex matches more queues than can be recovered at once"}

KEDA Version

2.5.0

Kubernetes Version

1.21

Platform

Amazon Web Services

Scaler Details

RabbitMQ

Anything else?

No response

[crisp2u]

Can anyone give any feedback on this ? @JorTurFer ? This is blocking us and we only have the option of dropping Keda or forking it :(
I think we can also provide a PR for this but a feedback on a possible solution would be most welcomed. Also as far as I see Keda does not have bug fix releases...

[JorTurFer]

Hi,
I have to apologize because I didn't see this...
I'm AFK now, in 20-30 min I'll review this

[JorTurFer]

Hi,
I have review your issue, You could increase the pageSize in trigger.metadata section up to your server max pageSize.
Related with doing the queries using regex and vhots, IDK, I have to test it. I'll do during the day

[crisp2u]

Already did that to get rid of the error. The problem is that I want to deploy another client on the same MQ cluster and the scaler will pick up the wrong queues without the vhost.

[JorTurFer]

That depends on the rabbit management plugin itself.
Did you try if it's possible using vhost? (just to save some time)

[crisp2u]

yes. I've mentioned in the issue. The easiest way to check is if you go to the RabbitMQ Management UI and filter queues using regex on a vhost. It adds /api/queues/<<vHost>> to the request

[JorTurFer]

I think that supporting this new feature if we maintain the current behavior also is worth. Maybe something like: if useRegex and vhost, then /api/queues/<<vHost>> and if not, current behavior.
You said that you are open to open a PR, right? 😄

[crisp2u]

@JorTurFer PR ready, sorry for being pushy but we're close to our release data

[JorTurFer]

@JorTurFer PR ready, sorry for being pushy but we're close to our release data

Don't worry, but just for sharing information, we released v2.6.0 last week and according to our governance repo, next release will be in 3 months. The milestone v2.7 ends on May.
Probably we will do another release with bugfixes, but we don't plan to include new features on.

I'm explaining this because you said that you are close to your release date and maybe you expect that this feature will be released ASAP. Once it's merged, it will be available in main tag, but main is not stable and we don't recommend it in prod

[crisp2u]

Yeah, I missed the release, I just saw it today. I'm also aware you are not doing bug fix releases, figured that out from the change log. We will either run from our fork or take the risk of running from keda master. Thanks for you help and I appreciate what you guys are doing.

[JorTurFer]

one tip, if you use KEDA from main tag, pull it and then push it into other registry and use it from that other registry. Doing that, you can "freeze" the version till next release