Keda: Resolve trigger configuration from environment variables

[mcollier]

Azure Functions provides a way to load trigger configuration values from an environment variable using an app setting binding expression (i.e. %syntax%) KEDA currently requires some values to be read from an environment variable / secret (e.g. connection strings), but other ones it requires literal values (e.g. queue name). It would be nice if there was also syntax to let KEDA know a value should be resolved from the target deployment environment variable.

Use-Case

As an Azure Functions developer who has built a function with a trigger that uses an app setting binding expression,
I want to have similar syntax resolved by KEDA to resolve trigger configuration from environment variables,
so that I have a consistent experience with trigger configuration (including connection strings) and am not forced to write alternative solutions such as Helm charts.

Specification

• [ ] Trigger configuration should optionally be resolved from environment variables
• [ ] KEDA should support syntax which allows a developer to indicate trigger configuration is to be resolved from environment variables
• [ ] Syntax used to indicate configuration from environment variables should be consistent for all trigger configuration (not specific to connection strings)

[mcollier]

@jeffhollan FYI

[tomkerkhove]

I might be missing something but we already read from environment variables based on trigger spec.

Do you have a concrete example that you can share?

_Although I can see why this is not clear_

[mcollier]

For the purposes of this discussion, let's use the Azure Service Bus trigger as an example. The documentation indicates that the connection value is resolved from an environment variable. As far as I can tell, other values such as queueName, topicName, subscriptionName, and queueLength are required to be literal values.

I feel it would be helpful if there was a way to indicate if a trigger configuration value should be resolved from an environment variable. As I understand it, currently the connection is treated as special.

[tomkerkhove]

That's valid feedback and something that confuses a lot of folks I think.

I've added it to our standup meeting to discuss how to proceed because maybe all fields should be literal and only be loaded from other places when using TriggerAuthentication.

Another approach is that it requires you to use fromEnv: foo which makes it more explicit.

[jeffhollan]

Talked about this in standup. Potentially calling this connectionRef or connectionEnv or something for values that do need to come from references of secrets / env / trigger auth. I think the big question here is on some timing. Is it worth making this breaking change right now? There will already be a bit of a breaking change here. Leaving this comment for discussion from community

[tomkerkhove]

@jeffhollan @zroubalik Looks like this was on the agenda for last weeks standup; is there an update on this?

Personally I'd make this change for v2 as we see more and more demand for this to be more flexible (for example #863)

[zroubalik]

@tomkerkhove I think we haven't touch on this topic. But I am open to this change, but I am still curious how many scalers would actually benefit from this (ie. where it does make sense).

[tomkerkhove]

I've quickly went through all scalers and current proposals which are documented in this doc: https://docs.google.com/document/d/1DWjG2GfhxO8nWrLciTLtHW2y6YDkj2CF7n3abj4-pmE/edit

In terms of timing I think it depends on the chosen approach - It can be a non-breaking or breaking change.

[tomkerkhove]

During standup we proposed to use connectionEnvRef/connectionEnv next to connection so that people can choose what they want to specify. If one or the other ones are specified, then that one wins. If both are specified, the hardcoded one wins.

Please share your thoughts and go through the docs to ensure we have listed all confusing/flexible fields.

We will do this as part of v2.

[zroubalik]

This is a good example of confusing configuration: https://github.com/kedacore/keda/issues/905 (Redis)

[MattJeanes]

This has just bitten me pretty hard on Azure Service Bus / Blob Triggers, the KEDA operator spits out these messages (censored slightly)

2021-01-06T17:52:39.445Z    ERROR   azure_servicebus_scaler error   {"error": "parse \"https://myservicebushere.servicebus.windows.net/%AzureServiceBusTopicName%/subscriptions/%AzureServiceBusSubscriptionName%\": invalid URL escape \"%Az\""}
github.com/go-logr/zapr.(*zapLogger).Error
    /go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:128
github.com/kedacore/keda/pkg/scalers.(*azureServiceBusScaler).IsActive
    /workspace/pkg/scalers/azure_servicebus_scaler.go:134
github.com/kedacore/keda/pkg/scaling.(*scaleHandler).checkScaledObjectScalers
    /workspace/pkg/scaling/scale_handler.go:203
github.com/kedacore/keda/pkg/scaling.(*scaleHandler).checkScalers
    /workspace/pkg/scaling/scale_handler.go:192
github.com/kedacore/keda/pkg/scaling.(*scaleHandler).startScaleLoop
    /workspace/pkg/scaling/scale_handler.go:135

This is marked under milestone 2.0, which I am using, but this doesn't appear to be fixed. I assume this one was missed out since this issue remains open.

For now I will have to work around and resolve these values manually in the ScaledObject though, but good to see this is at least planned hopefully soon!

[tomkerkhove]

Sorry about that :/

I think we should add it to our roadmap, thoughts @zroubalik @jeffhollan ?

[zroubalik]

@tomkerkhove agree