• Users may have configurations they may want to keep separate. • The docker implementation will need it to clearly and explicitly define storage.
I marked it a higher priority simply because I'm in a mood to spend more time on it. :)
just don't break my docker installs. :wink:
be aware that when you declare a VOLUME, it’s then sealed in the build context and can only be manipulated in the runtime context
@Rotonen did I do something incorrectly? `The docker run command initializes the newly created volume with any data that exists at the specified location within the base image. For example, consider the following Dockerfile snippet:`
not parsing what you ask
i mean ```... VOLUME /foo RUN touch /foo/bar.txt ...``` and the volume will not containe bar.txt at runtime, only at build time
ah, yeah, I always specify volume last. "set things up" "run configuration"
from time to time i see people trip up on that as it's not the most intuitive also from time to time i see people abuse that, as it's convenient
How do you think configuration should be handled?
I don't like just outright overwriting files.
define 'configuration'`?
My thinking is: load_config_file override_with_env_variables override_with_cli_arguments -> /tmp/conf and run against the conf
oh - that, yes, that's sane and common
just don't roll your own, there's plenty of preexisting work on that
The idea being I'm specifying sane docker defaults for each component, but also I never want to overwrite the user's files for them.
if you want to look at something well done for inspiration, ZConfig is a python classic on that front
well, I tend to roll my own for easy simple and minimal usage. load config file keys as -> `SNOWBLOSSOM_key=value` override with env vars -> `SNOWBLOSSOM_key=value` -> /tmp/conf as key=value Run component /tmp/conf
there's a lot of value to picking up and sticking to a generalized solution
There is already a mechanism to override config values via environment
by heritage i can only assume java also comes out of the box with a hypergeneralized configuration scheme thingamabob
Yeah, iceleaf uses that
i was wondering what made you use the windows registry - seems you did not have to actually do anything - very good
With the env_override_prefix, you set that to something like snownode_
Then you can override the db path with and env variable like snownode_db_path
Works for everything that takes a config file
Not iceleaf