On Wed, Jan 11, 2017 at 4:27 PM, Matthias Runge mrunge@matthias-runge.de wrote:

Hello,

for opstools-ansible[1], which installs a monitoring server, we had the brief discussion of overwriting/replacing package provided config files vs. adding changes to a .d directory for the application.

Specifically, this was the request for collectd. Additional plugins and are loaded and configured by placing a respective config snippet to /etc/collectd.d/...conf.

The question is: is it a valid expectiation, that operators wouldn't want the package provided config file /etc/collectd.conf modified?

Do you care at all?

Thanks for posting this email, following a private conversation we had.

I now sent an email about a series of patches for oVirt, one of which [1] is the subject of current email.

I'll reply here, although you might prefer to continue the discussion on gerrit.

Generally speaking, and as someone who spent ~ 15 years of his life as a sysadmin, I agree with you. Overwriting configuration files is not something to be done lightly.

Some thoughts I have re this, and specifically about collectd.conf:

1. Its default configuration file is pretty simple - lots of comments, plus a few LoadPlugin's and an 'Include "/etc/collectd.d"'. As-is, it's reasonable, and we (oVirt) might even be able to live with it and give up on this patch.

2. Specifically, it already has Include, which means we do not need to touch it in order to add snippets to collectd.d, as opposed to fluent.conf, which is also already overwritten by opstools-ansible, with its contents being replaced by a single include line. Still, since fluent.conf is already overwritten, I thought this is considered ok by the project and so pushed this patch.

3. OTOH it does load two plugins we decided we do not need for now, namely interface and syslog, and loading them does incur some overhead in both cpu/time and disk space, in the elasticsearch store. And AFAICT there is no way to "unload" a plugin (which is very reasonable, I do not know many other similar programs that do).

4. In oVirt, we usually treat the engine machine as being "multi-app", in the sense that the admin might use it for other things and we should not touch it too much, but we treat the hosts (hypervisors) as being "ours", in the sense that we control mostly everything on them. Current patch series is for the hosts, although it's intended to eventually be adapted also for the engine (as we do want to collect stuff also from it).

5. Obviously, it's pretty easy to change the patch to do this optionally. Add a var to control this and let the users decide. I don't mind much doing this, but obviously every such change adds complexity, and would better be avoided if possible.

Best,

[1] https://review.rdoproject.org/r/4275

Best, Matthias

[1] https://github.com/centos-opstools/opstools-ansible

Matthias Runge mrunge@matthias-runge.de _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel