Description
Right now we overwrite the static_config every time we upgrade Couchbase Server on a node.
I assume this is so we get the new options added when we perform the upgrade (prime example is ipv6 in Vulcan).
However, this approach makes maintaining Couchbase Server installations where you need to make modifications to static_config untenable for a few reasons:
- We only provide the ability to override certain settings via static_config, a non-exhaustive but commonly changed list:
- ipv6 - if you set this to true, you need to go in and set it to back to 'true' after every single upgrade.
- Custom log rotation - https://developer.couchbase.com/documentation/server/5.1/clustersetup/ui-logs.html
- Custom log levels - https://developer.couchbase.com/documentation/server/5.1/clustersetup/ui-logs.html
- Custom ports - https://developer.couchbase.com/documentation/server/5.1/install/install-ports.html
- Custom log directory - https://developer.couchbase.com/documentation/server/5.1/clustersetup/ui-logs.html
- Custom node names - https://developer.couchbase.com/documentation/server/5.1/install/rhel-multiple-instances.html
- Custom stats settings - https://developer.couchbase.com/documentation/server/current/monitoring/monitoring-stats-configuration.html
- SSL Cipher List
- This is not a generic config file, it is a file containing very specific erlang data structures, you might not be able to just programmatically 'add the setting back'. This is may be okay if we never ever change the structure of the file and you can work out the magic characters to remove and add, but we do actively change the file structure where needed. Getting this wrong will cause the whole file to get ignored.
Either we need to not automatically overwrite the existing static_config file (ideally some erlang script to 'merge' the static_config?) or provide an alternative, more fool-proof method to set all of the settings that right now you can only do properly using static_config (not sureĀ /diag/eval counts).