You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any errors in vault TriggerAuth configurations such as permissions or connectivity problems make it confusing to debug. Since the vault configuration lies within each ScaledObject, it could bubble up more descriptive errors when it's misconfigured instead of having to parse keda logs to find the root cause.
Use-Case
For example; when defining a ScaledObject and a TriggerAuth with an incorrect params;
this gives us the following Events on the ScaledObject
Warning KEDAScalerFailed 38s (x17 over 6m6s) keda-operator error parsing kafka metadata: no username given
it's a confusing error message to debug; it would be easier if it exposed the direct error from vault:
ex:
Warning KEDAScalerFailed 38s (x17 over 6m6s) keda-operator Error making API request.\n\nURL: PUT https://my-vault-server/v1/auth/cluster/login\nCode: 403. Errors:\n\n* permission denied
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
No response
The text was updated successfully, but these errors were encountered:
I tried to add support for this in the validating webhook but it's much more complicated then it seems;
since the webhook code lives in v1alpha1 there would be a cyclical dependency between v1alpha1 and the resolvers package where the vault/azuekeyvault logic lives.
I see a path forward but it's not trivial,
would either have to rewrite hashicorpvault_handler and azure_keyvault_handler to not depend on v1alpha1 packages by having a new struct & not use the ones in v1alpha1
or.... moving the webhooks to a different package (keda/v1alpha1/triggerauthentication_webhook.go -> webhooks or pkg/webhooks and refactoring the code there.
Proposal
Any errors in vault TriggerAuth configurations such as permissions or connectivity problems make it confusing to debug. Since the vault configuration lies within each ScaledObject, it could bubble up more descriptive errors when it's misconfigured instead of having to parse keda logs to find the root cause.
Use-Case
For example; when defining a ScaledObject and a TriggerAuth with an incorrect params;
& lets say that our user can't auth to vault because of some permission issues and we get the following:
this gives us the following Events on the ScaledObject
it's a confusing error message to debug; it would be easier if it exposed the direct error from vault:
ex:
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
No response
The text was updated successfully, but these errors were encountered: