Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file

[Erik M Jacobs (JIRA)]

Title: Message Title










 

 Erik M Jacobs created an issue











 






 Puppet /  PUP-1713



  removing nagios_* resource from manifest doesn't remove from resulting file 










Issue Type:

  Bug




Affects Versions:


 3.3.2




Assignee:

 Kylo Ginsberg




Components:


 Types and Providers




Created:


 15/Feb/14 2:31 PM




Environment:


CentOS 2.6.32-431.el6.x86_64 Puppet 3.3.2-1.el6 EPEL




Priority:

  Normal




Reporter:

 Erik M Jacobs










If you declare a nagios_service resource, it is created in the resulting file. Ex:



  nagios_service { 'Load':
use => 'local-service',
host_name => 'server',
service_description => 'Load',
check_command => 'check_nrpe!check_load',
contact_groups => 'admin',
target => '/etc/nagios/conf.d/nagios_service.cfg',
  }



However, if you then remove this resource declaration from a manifest and do the puppet run again, this service is not removed.
   

Jira (PUP-1713) removing nagios_* resource from manifest doesn't remove from resulting file

[Erik M Jacobs (JIRA)]

Title: Message Title










 

 Erik M Jacobs commented on an issue











 






  Re: removing nagios_* resource from manifest doesn't remove from resulting file 










I've had a couple of additional random thoughts on this. Perhaps they add some color.
I somewhat expected that, because the nagios type operates inside a file, that it would evaluate the context of the entire file under its control and act accordingly. This expectation is based on how Puppet md5sums files under management (file resource) and, if the contents are not as expected, we re-deploy the file. Perhaps that is expecting a little much of the nagios types, as it would have to compile/calculate the resulting file (target) and then md5sum that and THEN decide that it should re-generate the file from scratch.
In reference to PUP-728, since the resource types lay down the files with "incorrect" ownership/permissions, you end up having to manage the file's ownership after use:



nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
  } ->
  file { '/etc/nagios/conf.d/testgroup.cfg':
owner => "root",
group => "root",
mode  => "0644",
purge => true,
recurse => true,
  }



However, if you really want to make sure your nagios stuff is "clean", you could purge/recurse the directory... but, when you do that on top of managing the ownership/permissions, you don't actually end up purging the folder. For example:



  file { '/etc/nagios/conf.d':
alias => "nagios-confd",
ensure => directory,
purge => true,
recurse => true,
  }

  nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
  }



This results in a purge every run before laying down the type.



  file { '/etc/nagios/conf.d':
alias => "nagios-confd",
ensure => directory,
purge => true,
recurse => true,
  }

  nagios_servicegroup { 'test':
target => '/etc/nagios/conf.d/testgroup.cfg',
require => File['nagios-confd'],
  } ->
  file { '/etc/nagios/conf.d/testgroup.cfg':
owner => "root",
group => "root",
mode  => "0644",
purge => true,
recurse => true,
  }



This never purges because the file in the conf.d folder is "known" by puppet and actively managed.
So, at least, in my case, the solution is to place an "rm -f /etc/nagios/conf.d/*.cfg" as a requirement to/before all the service definitions, and that seems to solve the issue. This would probably be super ugly on a very large nagios environment / take a lot of time... but it "solves" the problem of unmanaged resources not remaining.