Replies: 4 comments
-
In my experience, once configuration is done by file there is little reason to support env or flags. Nowadays with GitOps everything is a file anyway (even env vars or flag values). Operators can easily add support for using env or flags through scripts (that end up setting the values in the config file) if there really need it. Files also have other benefits, looking up a current config is doing a Having only one way to do configuration (from the application perspective) also greatly simplifies documentation and support as there are less variations in setup (less is more kinda thing). Out of scope suggestion: One thing that gets lost with files is the ability to see defaults. It would be nice if either a "default" config was included (params commented out but showing defaults) or the binary could produce a file with all the defaults set (for ones that have defaults - the ones without defaults left blank) |
Beta Was this translation helpful? Give feedback.
-
@pn-santos Thanks for your suggestion! I think the point you make about not needing env or flags if configuration can be done by file really makes sense. I'm thinking of having it so that we will still support env and flags for the next while in order to keep it backwards compatible but this will be marked as deprecated. |
Beta Was this translation helpful? Give feedback.
-
@clarafu Really depends on who you ask. I don't see a need for flags and a config file (not sure who runs a web node by hand directly from the command line...), but you will probably find that some people want a unified config file whose differences for different installations are changed via environment variable. For what it's worth, there are now ways to generate configuration files that take values from environment variables, which is what we do internally for other tools. See e.g. https://docs.dhall-lang.org/tutorials/Language-Tour.html#environment-variable-imports |
Beta Was this translation helpful? Give feedback.
-
It would definitely be way more convenient if concourse would support configuration drop in files read from a directory or loading config files from specifying multiple command flags since then it makes it easier(in eg kubernetes) to just provide separate configmaps and secrets for passphrases which get mounted as volumes or in some cases secrets get injected as files from init containers which can be just dropped in a directory concourse uses to read the config from. Keep env and flag values which you would want to use on the command line, are often changed by users or required for debugging the application |
Beta Was this translation helpful? Give feedback.
-
I've been working on being able to pass a config file to the
web
orworker
on the concourse command. The fields that need to be passed into (especially the web command) seems to make more "sense" to be a config file rather than the current way of configuring the commands through flags or environment variables.One question I'm sort of stuck on is whether or not we want to continue supporting flags and environment variables. Would users still benefit from being able to set the fields through flags and env vars if they are able to pass the commands a config file? Or is it just overkill to allow the user to set through three different methods?
I initially leaned towards allowing all three methods, just for backwards compatibility sake but then that might not be a good excuse because it can be achieved through other means. For example, we could allow some sort of migration tool or integration that will help convert the current state of their web or worker nodes into a config file.
Question: If the means to starting up your Concourse web or worker nodes is through a config file, is there still a need for flags or env vars for those same configuration fields?
Thanks! :)
Beta Was this translation helpful? Give feedback.
All reactions