Rabbitmq scaler: Allow providing separate paremeters for user and password

[iordaniordanov]

Proposal

I would like to be able to provide username/password as separate parameters for the RabbitMQ scaler, in order to be able to get host from Environment variable and username/password from separate environment variables/secrets

Use-Case

We are using single RabbitMQ deployment for multiple applications which have separate secrets containing their credentials. Since credentials are generated by helm templates we have no way to know what they will be in advance. Adding to this we are using podpreset to inject the environment variables containing the username and password, which means we cannot combine everything in 1 variable using the pod manifest, because the username/password variables are injected at the end of the variables array. Having the option to reference separate secret/environment variables from which username and password to be taken is crucial for such deployments.

Anything else?

No response

[wasabii]

I strongly second this. Another obvious use case is using the Rabbit MQ Message Topology Operator to generate users. This operator produces secrets with separate username, password data. Additionally, you need to fetch the host, amqpPort, vhost, etc from another secret produced by the Rabbit MQ Cluster Operator.

Providing each of these as separate parameters to the TriggerAuthentication would allow us to simply point to the existing secrets, instead of having to devise a crazy way to combine them all into a URL on yet another secret.

[zroubalik]

I think this makes sense, WDYT @JorTurFer ?

[JorTurFer]

yes, IMO it totally makes sense. Are you willing to contribute with this @wasabii @iordaniordanov ?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed due to inactivity.

[xoanmm]

I would like to tackle this issue

[JorTurFer]

it's yours

[b1czu]

What about this feature? Any ETA? We have deployment to multiple namespaces using kustomize and without ability of providing each of these as separate parameters to the TriggerAuthentication we can't simply point to the existing secrets generated by RabbitMQ Cluster Operator and/or RabbitMQ Messaging Topology Operator. Using KEDA's RabbitMQ Scaler's hostFromEnv with something like this inside example-deployment definition:

envFrom:
  - prefix: RABBITMQ_
    secretRef:
      name: example-deployment-default-user
env:
  - name: RABBITMQ_ConnectionString
    value: amqp://$(RABBITMQ_username):$(RABBITMQ_password)@$(RABBITMQ_host):$(RABBITMQ_port)

also does not work because keda sees these variables before expansion, although it works inside example-deployment's container just fine.

[JorTurFer]

@xoanmm

[xoanmm]

@b1czu I'm working in the PR associated, I think that I'll be able to finish in the following weeks, I'm having a hard time since I haven't programmed anything in go for a few weeks

[zargarf]

Is there an approx timeline on this feature? This is one that's important to us too

[JorTurFer]

AFAIK, the PR was abandoned, so you can open another PR adding the support if you are willing to contribute @zargarf

[cecilphillip]

This feature would be particularly useful when using the secrets generated from the RabbitMQ Operator

[JorTurFer]

@xoanmm , are you still interested on contributing with this? If you cannot any other folk can tackle it

[hkhairy]

Any update regarding this feature? We're facing a similar situation, and it would be great to have the username and password as separate fields.

[JorTurFer]

There isn't any news AFAIK. Are you willing to continue with the feature?