nagios-charmers team mailing list archive

[James Hebden <james.hebden@xxxxxxxxxxxxx>]

> James, is nagios-cgi.tmpl directly from the nagios package? If so, should we
> instead parse and update that instead of shipping our own copy of it?

It is from the package, with some edits made to include template tags which are rendered by charm hooks. I feel that templating this file ongoing is the best approach, rather than parsing and modifying, as we've also taken this approach with other config files in this charm, and generally I believe it to be a better approach to take when charming.

Generally, my preference is to template rather than parse and update for the following reasons -

We should be authoritative with our config files when managing them with a charm. If Juju is managing a config file, regardless of how much of the config file we are managing via templated variables, it makes sense to make sure that any local modifications to a config file are controlled and that we can be sure of the configuration file in its entirety to prevent issues when parsing the config file, and to prevent issues with the generated config file not configuring the software for the intended purpose due to modifications the charm did not implement. This setting isn't a great example of this, as it's fairly self-contained - however I'm trying to think holistically about the approach here.

We also don't need to worry about squashing packaged updates to the software, as we can accommodate these with per-version templates if per-version config changes are needed, per what is done in the OpenStack charms, if that ever becomes an issue. I doubt very much we'll get into that issue with Nagios, but if we ever did we can accommodate it, and I also think this is a good way to make sure we capture the entire working config for an individual version of software.
-- 
https://code.launchpad.net/~jhebden/nagios-charm/+git/nagios-charm/+merge/318564
Your team Nagios Charm developers is subscribed to branch nagios-charm:master.