Provide unified KEDA core configuration

[arschles]

A clear and concise description of what you want to happen.

Use-Case

When you run KEDA in a 12-factor environment, it's sometimes easier to configure it with environment variables (not commandline flags), in other cases, a pre-canned config file is more useful, and of course, we already have commandline flags, so those are certainly more useful to some people

I think we should support all 3 ways of configuring the KEDA controller (not necessarily the metrics API, but that could be considered)

Specification

• [ ] Change the stdlib flags package usage to use viper, or a similar library that can draw configuration values from multiple sources

[zroubalik]

viper is more relevant to the CLI based apps, right? And since the operator should be long running, the modification to the configuration should happen not just via arguments on the startup. I was thinking about this before and the proper configuration for the operator is a ConfigMap that's being watched by the operator, user can modify the settings in the ConfiMap and KEDA will react to it properly.

[arschles]

Not necessarily @zroubalik. I've used it in several server/daemon projects (most recent one. It's really good for allowing users to pass in configs from a variety of different sources. I've used it as part of a configuration hierarchy:

• flags on the command line
• env vars / config files (viper would come in and standardize the file and env var naming scheme)
• ConfigMap to mount env vars (which viper would standardize)

[zroubalik]

I agree that we should expose some unified endpoit for configuration. Flags or env Vars are nice to have to, but the solution should definitely provide a ConfigMap, that's being watched by the KEDA Operator and values are changed dynamically as they are changed in the CM.

[arschles]

Agreed regarding the ConfigMap. Would it be appropriate to create a config system that can provide configuration values at any point in time while also allowing a subscriber to get notified when something changed (regardless of the configuration's source)?

[zroubalik]

Yeah functionality like this would be nice. There are existing patterns for ConfigMap watchers in k8s ecosystem. We should reuse this, to not reinvent the wheel :)

[coderanger]

Rather than watching a ConfigMap directly, I think it would be better to mount it as a volume and watch the file. While we could use resourceNames to make a limited RBAC policy, letting the Kubelet do the API heavy lifting usually simplifies things and allows for a more complex deployment if someone wants to go off the rails ("make the config file however you want as long as you mount it here").

[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.

[arschles]

@zroubalik @coderanger do you think something like this is still worth pursuing?

[zroubalik]

@arschles yeah, I think we should do this.

[arschles]

ok. how about I pursue adding unified file-based and/or environment variable based configuration? that way, people can put their configs in a ConfigMap and mount it in as a file, as @coderanger suggested. if someone chooses file-based and we allow configuration to be changed at any time, should the controller automatically detect the change and reload configs?

[zroubalik]

+1 for the ConfigMap approach and automatic change detection with reload. Thanks for taking this!

[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.

[arschles]

I clearly haven't gotten to this yet. If someone else wants to take it, feel free. I probably won't be able to work on it for a while.

[tomkerkhove]

No worries Aaron!