Looking through the Ceph docs and its code again I begin to doubt that our current approach in charms themselves is a problem and that the issue described in the original report is the case under normal circumstances:

"Any value that already exists in the configuration database will no longer receive updates from ceph.conf. This breaks a number of settings in the ceph-* charms that rely on ceph.conf to propagate changes."

After all, this would be a major breaking change upstream. I think we need more data, namely we need to know if it affects mons only or other daemons too due to the following:

1) Ceph docs clearly state that config files are still being read and interpreted and values there override those that come from sources earlier in the list:

https://docs.ceph.com/docs/mimic/rados/configuration/ceph-conf/#config-sources
"Each Ceph daemon, process, and library will pull its configuration from several sources, listed below. Sources later in the list will override those earlier in the list when both are present.

1) the compiled-in default value
2) the monitor cluster’s centralized configuration database
3) a configuration file stored on the local host
4) environment variables
5) command line arguments
6) runtime overrides set by an administrator


2) I could find the implementation for the behavior mentioned in (1):

There are config source priority levels defined:
https://github.com/ceph/ceph/blob/v13.2.9/src/common/config.cc#L54-L66
const char *ceph_conf_level_name(int level)
{
  switch (level) {
  case CONF_DEFAULT: return "default";   // built-in default
  case CONF_MON: return "mon";           // monitor config database
  case CONF_ENV: return "env";           // process environment (CEPH_ARGS)
  case CONF_FILE: return "file";         // ceph.conf file
  case CONF_CMDLINE: return "cmdline";   // process command line args
  case CONF_OVERRIDE: return "override"; // injectargs or 'config set' at runtime
  case CONF_FINAL: return "final";
  default: return "???";
  }

Each call to _set_val includes an integer "level" passed by the caller:
https://github.com/ceph/ceph/blob/v13.2.9/src/common/config.cc#L1347-L1385
int md_config_t::_set_val(
  const std::string &raw_val,
  const Option &opt,
  int level,
  std::string *error_message)
{
    // ...
    if (p->second.rbegin()->first > level) {
      // there was a higher priority value; no effect
   // ...


Examples (mon settings and settings from a file):

https://github.com/ceph/ceph/blob/v13.2.9/src/common/config.cc#L263-L292
int md_config_t::set_mon_vals(CephContext *cct,
// ...
    int r = _set_val(i.second, *o, CONF_MON, &err);

https://github.com/ceph/ceph/blob/v13.2.9/src/common/config.cc#L440
int md_config_t::parse_config_files(const char *conf_files_str,
				    std::ostream *warnings,
				    int flags)
// ...
      int r = _set_val(val, opt, CONF_FILE, &error_message);


3) the same priority-based behavior is documented in the commit about a rewrite of common/config
https://github.com/ceph/ceph/commit/f8d4e5b5e9e540b16a0ed1e5617986046a7b2d25
"- for every option, we track values from any inputs (config, mon, override).  At get_val() time, we pick the highest priority one."


So, I think config file values should still have a priority over whatever is in the config database, otherwise it is a bug in Ceph itself.