Dgraph Alpha Command Line Options Should Use Dotted Notation

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