-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Postgres Scalar: Only password field works on TriggerAuthentication #1286
Comments
Hello, i can confirm the behavior with keda 2.2:
Error reported is:
We'd like to centralize parameters on a single secret, so we don't require to update several files when DB details is changed. Based on docs:
i was supposed to move parameter from ScaledObject to TriggerAuthentication and have it parsed, but looks like is not true. |
Has anyone managed to make it work? apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: keda-trigger-auth-mysql-secret
namespace: develop
spec:
env:
- parameter: host
name: DB_HOST
- parameter: port
name: DB_PORT
- parameter: dbName
name: DB_SCHEMA
- parameter: username
name: DB_USERNAME
- parameter: password
name: DB_PASSWORD
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: worker-scaler
namespace: develop
spec:
maxReplicaCount: 1
scaleTargetRef:
name: publisher-backend-worker
triggers:
- type: mysql
metadata:
queryValue: "4"
query: "SELECT COUNT(*) FROM table WHERE TRUE"
authenticationRef:
name: keda-trigger-auth-mysql-secret For me, it makes it nearly impossible to use KEDA. 😩 |
I presume the workload have the specified environment variables? |
Yea, of course. I have also tried the The only way I was able to make it work for MySQL scaler is to add a new key to the Secret for |
Ok, I just wanted to verify - Thanks! We will definitely have to fix this then, it is not maintainable to use that workaround for sure. Is this something you are wanting to look in to @JorTurFer? |
I have just taken a look at this and is truth, we are not taking more than Support getting parameters from TriggerAuthentication shouldn't be a problem, but is it really necessary? I mean, could be better if we support (for example) Maybe we can support all the case, get value from trigger metadata, from environment variable without TriggerAuthentication and from TriggerAuthentication. We should maintain |
We should no longer use I will open issues to track these changes later today. |
So basically we have to support getting the values from trigger metadata and trigger auth, right? |
|
I will add to them today :) |
All the PR are opened :) |
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. |
I think that this can be closed because all related issues are closed |
#947 Expected Behavior
All other fields like host, database, username, ssl to work on reference to TriggerAuthentication object
Actual Behavior
Only password works now with TriggerAuthentication. Others produce the below error:
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: