Consider providing a mechanism for overridding configuration

[mmihic]

Currently the configuration framework only reads configuration YAML files that have been embedded into the application jar, and the only way to customize the application's configuration for local development is to edit the configuration files that have been committed to git. This is a poor development experience, as it means needing to remember to skip adding those hand-modified files when building commits, or risk accidentally committing a development configuration specific to an individual machine. Propose that we provide a way to specify an override for the embedded YAML files at runtime, possibly through e.g. an environment variable that points to an external YAML file that gets loaded instead of or after all of the embedded files.

With this, the development flow would look like:

1. src/main/resources contains default configuration (<service_name>-common.yaml) and a development configuration (<service_name>-development.yaml) that runs "out of the box" inside a local docker image built from the service supplied Dockerfile. Typically this development configuration will use the same hostnames, ports, paths as the service would use in a staging/production configuration, and which are local to the docker image / user bridged docker network.

2. Developers that want to run a service on their laptop outside of Docker can create a yaml file anywhere on their local laptop file system and explicitly control all of the configuration for the service, then tell the service to load that custom configuration via env var (or some equivalent means).

[mmihic]

Alternately we should not do any implicit configuration file loading at all, and instead require that you always explicitly specify the configuration file on the command line / in an env-var (with a syntax for saying use a file within the jar)

[eeSeeGee]

Once we're rolling on developing on top of working docker images we should probably have our whole k8s dev environment encapsulated in a bunch of docker-compose.yml files. With docker compose it's dead easy to substitute a local directory over whatever's in the running image, so this would cover config and built class files for whatever you're working on. This can be done with vanilla Docker too, it's just tedious.

As for non-docker dev stuff, maybe a separate config dir that takes precedence (and only takes effect when the process determines it's not running inside a container)?

[swankjesse]

I think we might have it:
#296