feat: Support regex usage in Azure Service Bus scaler.

[v-shenoy]

I chose regex instead of supporting a list in queueName / subscriptionName parameters. Reason for this being, if the number of entities is small enough to write in a list, the user might as well use multiple triggers within the ScaledObject. While regex will allow users to specify a large number of entities easily.

Checklist

• Commits are signed with Developer Certificate of Origin (DCO - learn more)
• Tests have been added
• A PR is opened to update the documentation on (repo) (if applicable)
• Changelog has been updated and is aligned with our changelog requirements

Fixes #1624
Fixes #2920
Relates to kedacore/keda-docs#917

[tomkerkhove]

Reason for this being, if the list of entities is small enough to write in a list, the user might as well use multiple triggers within the ScaledObject

That's true but as soon as we support trigger ordering for evaluation or related cross-trigger features this goes away.

I do agree regex has its place, but maybe we need both? (list + regex?)

What are your thoughts @zroubalik @JorTurFer?

I personally wouldn't like to use regex as a list is simpler but see value in both.

[JorTurFer]

I do agree regex has its place, but maybe we need both? (list + regex?)

For me, regex is totally enough, it's the approach we have in RabbitMQ, but I'm not against supporting both

[tomkerkhove]

This is another one of those where I'm being a pain to try to increase the UX for non deep-experts

[v-shenoy]

I feel having multiple parameters to do the same thing makes it more confusing for users. The regex approach also maintains parity with RabbitMQ.

[v-shenoy]

Any more comments here @JorTurFer @tomkerkhove?

[JorTurFer]

Looking good. Should we add any e2e test for this?

[v-shenoy]

Looking good. Should we add any e2e test for this?

I'll add it. Should we cover for both queue and subscriber cases? (I don't mind adding them, I am just thinking about how the test suite size).

[JorTurFer]

I'll add it. Should we cover for both queue and subscriber cases? (I don't mind adding them, I am just thinking about how the test suite size).

If possible, I'd test both, but IDK how complicated it is. Maybe if we add more test to azure, it's time also to create a folder to group all azure e2e test like we do with rabbit or redis

[v-shenoy]

/run-e2e azure
Update: You can check the progress here

[v-shenoy]

I'll add it. Should we cover for both queue and subscriber cases? (I don't mind adding them, I am just thinking about how the test suite size).

If possible, I'd test both, but IDK how complicated it is. Maybe if we add more test to azure, it's time also to create a folder to group all azure e2e test like we do with rabbit or redis

PTAL @JorTurFer

[tomkerkhove]

What is the operation for? Not sure I get the usecase for it

[v-shenoy]

What is the operation for? Not sure I get the usecase for it

Given that multiple queues / subscriptions can match the regex, we need an aggregation operation to convert the message counts into a single metric.

[JorTurFer]

let's wait till the SDK update is merged (sorry for the extra work :( )

[v-shenoy]

Updated after the SDK change. PTAL @JorTurFer

[v-shenoy]

/run-e2e azure
Update: You can check the progress here

[v-shenoy]

/run-e2e azure
Update: You can check the progress here

[JorTurFer]

LGTM!