[m3query] Allow for optional override config file. #1934
Conversation
|
|
pavelnikolov
force-pushed
the
allow-multiple-config-files
branch
2 times, most recently
from
244a146
to
e8f1ffc
Compare
pavelnikolov
force-pushed
the
allow-multiple-config-files
branch
from
e8f1ffc
to
0839f06
Compare
| // OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN | ||
| // THE SOFTWARE. | ||
|
|
||
| package config_test |
There was a problem hiding this comment.
meganit: we typically don't use the _test package name convention
There was a problem hiding this comment.
It was intentional because I am not using any private members of the package. If anything internal changes, the tests remain the same - only test the public API of a package. There should be very few reasons not to use _test, IMHO.
src/x/config/flag.go
Outdated
| // Then it can be invoked like this: | ||
| // ./app -f file1.yaml -f file2.yaml -f valueN.yaml | ||
| // Finally, when the flags are parsed, the variable contains all the values. | ||
| type StringSlice []string |
There was a problem hiding this comment.
Can we make this something more contextual, like FlagSlice? StringSlice is pretty generic and I think introducing flag-specific context is fine since this is built to implement flag.Value
Maybe something like MultiFlagAccumulator or something to convey that it accumulates duplicate values?
src/x/config/flag.go
Outdated
|
|
||
| import "fmt" | ||
|
|
||
| // StringSlice represents a slice of strings. When used as a flag variable, |
There was a problem hiding this comment.
nit: Mind adding var _ flag.Value = &StringSlice{} for a little extra context?
|
|
||
| func main() { | ||
| flag.Var(&configFiles, "f", "configuration file(s)") |
There was a problem hiding this comment.
What do you think about pulling all this configFiles stuff into xconfig.StringSlice, something like
xconfig.ParseConfigFilenames(flag string, description string) ([]string, bool)
That could handle the validation and make it a little easier to use? Don't mind either option much though, so up to you here 👍
There was a problem hiding this comment.
I'd personally leave it like this for now.
pavelnikolov
force-pushed
the
allow-multiple-config-files
branch
from
1b59798
to
3e9a3ed
Compare
What this PR does / why we need it:
Fixes #1921
TL;DR Some of the config is static and can be stored in
git. However, there are parts of the config that are generated dynamically like, for example, the RPC remote addresses, which are generated using service-discovery in our case. This PR allows for multiple config files.Special notes for your reviewer:
This is a draft proposal for additional configuration of
m3query. This is a WIP and chances are that this will break unit tests of components. Before I invest more time in this I'd like to know if you agree with this approach. Ideally, I'd prefer allowing for multiple-farguments, like this:Does this PR introduce a user-facing and/or backwards incompatible change?:
NONE
Does this PR require updating code package or user-facing documentation?:
YES