Capomastro charm setting of nagios_context has some bad behaviors
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Capomastro |
Confirmed
|
High
|
Unassigned |
Bug Description
Due to some IS requirements, they contributed a small update to the charm to be able to set nagios_context as a juju option:
https:/
I merged this because This is not critical or too troublesome for us, because we have some freedom to just destroy the environment if needed, and it doesn't break anything crucial (nagios support is mostly an IS requirement). But as can be seen in the merge request, the code introduced did bring some problems with it (apologies for introducing tech debt):
nagios_context is only used in the nrpe-external-
1) If the nagios_context is changed via a juju set, the .cfg file won't be updated.
2) If the nagios_context is changed and *then* the relation is destroyed/readded, then a .cfg file is created with the new nagios_context *but* the old one is not deleted.
I'm talking about the files in /etc/nagios/nrpe.d; I notice (and checked) that it nukes /var/lib/
So work to be done for this bug:
- Make it so that the relevant files (see the nrpe-external-
- Ensure the files in /etc/nagios/nrpe.d that are stale due to a change in nagios_context are removed. This is a bit hard because unlike the ones in /var/lib/
The merge request has more comments by David Ames, but the crucial points are:
Nagios config generation code should be in a common area that multiple hooks can call.
The left over file [in etc] in this case is OK, though it may make sense to name it in such a way that the nagios_context does not affect the file name.
Changed in capomastro: | |
status: | Triaged → Confirmed |