[GitHub] kocolosk opened a new pull request #50: Use default.d for image-provided config in 2.x

[GitBox <gi...@apache.org>]

kocolosk opened a new pull request #50: Use default.d for image-provided config in 2.x
URL: https://github.com/apache/couchdb-docker/pull/50
 
 
   Currently we are writing custom configuration files into `etc/local.d`. I ran into a bit of a challenge with this while creating a Helm chart to deploy CouchDB using Kubernetes.
   
   Kube has the concept of a [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configmap/) which can take configuration information and expose it as files under a mount point in the container filesystem. The trouble with treating `local.d` as a ConfigMap mount point is that, as `local.d` files take the highest priority in the system, any configuration updated using the `_config` endpoint will be written to a file in this directory, which will certainly clash with Kube as it believes it is responsible for the files underneath the mount point (e.g. it will dynamically update them if the ConfigMap changes). So instead, I told Kube to use `default.d` as a mount point (see https://github.com/kocolosk/charts/commit/88880a45be), but that means I cannot override configuration settings that are customized by this image.
   
   ## Possible Solution
   
   One way I thought we might improve upon this is:
   
   1. Publish the image's static config overrides (e.g. `chttpd.bind_address`) into `default.d` instead of `local.d`
   2. Continue to include an empty `etc/local.ini` in the image.
   3. Continue to use `local.d/docker.ini` (or switch to `etc/local.ini`) for the config overrides that occur in `docker_entrypoint.sh`
   
   This would enable a ConfigMap-derived configuration to override `default.ini` while still allowing for online configuration customization using `local.*` to take highest priority.
   
   This PR makes the above change for 2.x images. Curious to hear folks' thoughts.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services