Experience Report for Feature Request
Currently, command-line options are expressed both as --parent_child
and --parent.child
. I hope that they can later because of how they can be represented in configuration files (json, toml, yaml).
What you wanted to do
I would like options to use the --parent.child
for acl
, graphql
, vault
, and tls
similar to how badger
, jaeger
, datadog
are configured.
happy-config.yaml
This way we can use a config.yaml with higher usability/readability:
vault:
addr: http://vault.dgraph.devtest.io:8200
field: enc_key
format: base64
path: secret/data/dgraph
roleid_file: /dgraph/vault/roleid
secretid_file: /dgraph/vault/secretid
tls:
dir: /dgraph/tls
client_auth: VERIFYIFGIVEN
use_system_ca: true
happy-config.json
{
"vault": {
"addr": "http://vault.dgraph.devtest.io:8200",
"field": "enc_key",
"format": "base64",
"path": "secret/data/dgraph",
"roleid_file": "/dgraph/vault/roleid",
"secretid_file": "/dgraph/vault/secretid"
},
"tls": {
"dir": "/dgraph/tls",
"client_auth": "VERIFYIFGIVEN",
"use_system_ca": true
}
}
happy-config.toml
[vault]
addr = 'http://vault.dgraph.devtest.io:8200'
field = 'enc_key'
format = 'base64'
path = 'secret/data/dgraph'
roleid_file = '/dgraph/vault/roleid'
secretid_file = '/dgraph/vault/secretid'
[tls]
dir = '/dgraph/tls'
client_auth = 'VERIFYIFGIVEN'
use_system_ca = true
What you actually did
For command-line options that following the --parent_child
pattern, we cannot use categories or hierachies in configuration files or hierarchy as expressed supported by configuration languages.
Why that wasn’t great, with examples
We have to use this instead below.
sad-config.yaml
vault_addr: http://vault.dgraph.devtest.io:8200
vault_field: enc_key
vault_format: base64
vault_path: secret/data/dgraph
vault_roleid_file: /dgraph/vault/roleid
vault_secretid_file: /dgraph/vault/secretid
tls_dir: /dgraph/tls
tls_client_auth: VERIFYIFGIVEN
tls_use_system_ca: true
sad-config.json
{
"vault_addr": "http://vault.dgraph.devtest.io:8200",
"vault_field": "enc_key",
"vault_format": "base64",
"vault_path": "secret/data/dgraph",
"vault_roleid_file": "/dgraph/vault/roleid",
"vault_secretid_file": "/dgraph/vault/secretid",
"tls_dir": "/dgraph/tls",
"tls_client_auth": "VERIFYIFGIVEN",
"tls_use_system_ca": true
}
sad-config.toml
vault_addr = 'http://vault.dgraph.devtest.io:8200'
vault_field = 'enc_key'
vault_format = 'base64'
vault_path = 'secret/data/dgraph'
vault_roleid_file = '/dgraph/vault/roleid'
vault_secretid_file = '/dgraph/vault/secretid'
tls_dir = '/dgraph/tls'
tls_client_auth = 'VERIFYIFGIVEN'
tls_use_system_ca = true
Any external references to support your case
The dgraph helm chart 0.0.8 will use configuration files going forward, so this would make it easier to maintain configurations going forward, so more people will be required to use configuration files for dgraph. Customers are already using hierarchical configurations with YAML where the option is available, such as badger.compression_level
, badger.tables
, and badger.vlog
settings, expressed as:
badger:
compression_level: 3
tables: mmap
badger.vlog
It would be great to do this with other options: acl
, graphql
, vault
, and tls