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

Created on 13 May 2019  路  9Comments  路  Source: fluxcd/flux

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.

  1. 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.
  2. If specified, the configuration should be read from the user specified location.
  3. 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.
enhancement help wanted

All 9 comments

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.

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.

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"?

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.

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.

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 https://github.com/fluxcd/flux/pull/2438

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.

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.

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

https://github.com/fluxcd/flux/blob/72424ed293147f8f0a21b32b8db95148d3361d39/cmd/fluxd/main.go#L597

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

Was this page helpful?
0 / 5 - 0 ratings