A package update will not likely replace the existing config, so Juju will still be authoritative (.orig?).
My point is more of now we have to manage and maintain the config file. If that changes upstream in the latest nagios package (say with new config options / features), we'd have to pull it into the charm. So now the next upgrade-charm could potentially ship out a new config with options to an environment that has nagios packages that probably doesn't yet support the new configs (Xenial on Trusty for example)? I'm more in favor of just reading in the current config and only modifying/adding the config otpions we're interested in (in this case, it's just authorized_for_read_only). If the charm was to be deployed in a new distro or nagios release where cgi.cfg has introduced newer config options, then it would still just work (unless ofcourse the authorized_for_read_only is renamed or removed heh). -- https://code.launchpad.net/~jhebden/nagios-charm/+git/nagios-charm/+merge/318564 Your team Nagios Charm developers is subscribed to branch nagios-charm:master. -- Mailing list: https://launchpad.net/~nagios-charmers Post to : [email protected] Unsubscribe : https://launchpad.net/~nagios-charmers More help : https://help.launchpad.net/ListHelp
