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. Add Comment   Puppet / PUP-1713 removing nagios_* resource from manifest doesn't remove from resulting file If you declare a nagios_service resource, it is created in the resulting file. Ex: {code}   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',   } {co... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.