As an engineer, I want to specify my flux configuration in a single file

[mjpitz]

Describe the feature
Right now, users can provide a large range of command line options to help configure flux. It would be great if this configuration could be pulled from a single config file instead of needing to hard code options on the container itself. By decoupling the container from the configuration, the two can be managed independently.

What would the new user story look like?
How would the new interaction with Flux look like? E.g.
0. The flux container should allow an option --config to be specified. This options should point to a file path location where the flux configuration is specified.

1. If specified, the configuration should be read from the user specified location.
2. Existing command line options (e.g. --git.url) should override their --config file counterparts.

Expected behavior

• Users can specify either a config file or the existing command line options.
• The command line options override any config file value.
• Configuration can be managed independently from the container.

[squaremo]

This makes sense to me. It would lead the way for config being mounted from a ConfigMap, which might make e.g., automatic configuration much easier.

[tkeech1]

I'd like to work on adding support for ConfigMaps. It would be nice to use Viper because it supports hierarchical overrides and works with pflag. Please let me know if that's ok.

[squaremo]

I'd like to work on adding support for ConfigMaps.

Neat! Is there special support needed for ConfigMaps, over just getting config from a file? Or should I read this as "support for config from a file, which can be mounted from a configmap"?

[stefanprodan]

I think Viper is the right choice for us. The config file can come from a ConfigMap or Kubernetes secret but that shouldn't matter since Flux/Viper will just look for a file on disk.

[tkeech1]

My thought was to just add support for ConfigMaps. In a helm deployment, ConfigMap values would come from values.yaml. For a non-helm deployment, ConfigMap values would be specified in a new file, flux-configmap.yaml. In either case, the config will be loaded as a ConfigMap and the flux container will mount the ConfigMap values into environment variables. Existing command-line options will override environment variables.

Please let me know if you have something else in mind.

[stefanprodan]

I think Flux should look for a config file on disk. The configmap would be mounted as a volume by the Helm chart and fluxctl install. If people want to use https git addresses, then they should be able to switch to a secret instead of a configmap since the config will contain sensitive information see #2438

[vyckou]

Why not to use viper and configuration could be added to flux by config file by mount. Also it would enable to pass non secret configuration from configmap and for secrets from k8s secrets - both type of values would be available as env vars for fluxd daemon.

[stefanprodan]

Why not to use viper and configuration could be added to flux by config file by mount.

This is what I had in mind, users can chose from a configmap or secret that gets mounted in the Flux container. Flux will use viper to read the config file from a local path.

[vyckou]

Also please add the 🚩 to disable auto updates check and if statement to control

flux/cmd/fluxd/main.go

Line 597 in 72424ed

checkpoint.CheckForUpdates(product, version, checkpointFlags, updateCheckLogger)

As there are environments which will never get to the Internet and that is simply noise in the logs

[kingdonb]

Please let me know if you still need help with this. I apologize for the staleness of this reply, we are in the process of cleaning up stale issues from the Flux v1 repo now, this should be over soon.

I will close the issue for now as it is stale. Flux v1 remains in maintenance mode. Although I can still review and accept some pull requests, there is little labor effort available to develop the Flux v1 codebase and are no new features being added to Flux v1 daemon and this is generally critical fixes only situation at this point.

We can provide support to Flux v1 users especially with respect to migrating to the new Flux version, which has some breaking changes but is also a total rewrite and also brings many improvements. I'm closing the issue but you are most welcome to write back on this issue, or open another issue. Thanks for using Flux.