Sometimes we tell people to set components.zss.port when we mean
And, it's really easier to tell people 1 line instead of trusting people educate themselves on how to use YAML.
zwe startup takes YAML and flattens it, and part of that is to turn every . into _
Today, you can put this in the YAML
components.zss.port: 8888
components:
zss:
port: 9999
The environment variables you will recieve at runtime is
components_zss_port: 8888 or 9999
We don't know which wins.
But this is allowed by configmgr because "components.zss.port" is a key, and is not within the "components" key, so it is not validated.
So, users today can indeed type dot notation into the YAML, but it may not be read.
It'd work for APIML, because they only read env vars.
It wont work for ZSS or app-server, because they actually do read the YAML.
So, my ask is: can we enhance configmgr such that it does consider dot notation, folds it in, and all the cfgGet commands can handle it?
Then users could go flat, or go YAML, and it'd be up to them, we wouldn't care.
Sometimes we tell people to set
components.zss.portwhen we meanAnd, it's really easier to tell people 1 line instead of trusting people educate themselves on how to use YAML.
zwe startup takes YAML and flattens it, and part of that is to turn every
.into_Today, you can put this in the YAML
The environment variables you will recieve at runtime is
We don't know which wins.
But this is allowed by configmgr because "components.zss.port" is a key, and is not within the "components" key, so it is not validated.
So, users today can indeed type dot notation into the YAML, but it may not be read.
It'd work for APIML, because they only read env vars.
It wont work for ZSS or app-server, because they actually do read the YAML.
So, my ask is: can we enhance configmgr such that it does consider dot notation, folds it in, and all the
cfgGetcommands can handle it?Then users could go flat, or go YAML, and it'd be up to them, we wouldn't care.