[CentOS-devel] [opstools] overwriting package provided config files

On Wed, Jan 11, 2017 at 4:27 PM, Matthias Runge
<mrunge at 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 at matthias-runge.de>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel



-- 
Didi