[PDB-134] Purging resources that were exported resources sometimes fails Created: 2013/12/04 Updated: 2014/07/28 Resolved: 2014/03/25
|Affects Version/s:||PDB 1.5.0|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
I'm seeing an issue where sometimes I have an exported resource that is failing to be removed from the node that is collecting them after the node has been cleaned up by running a "puppet node clean <hostname>" on the puppetmaster. For example, I'm exporting both nagios_host and nagios_service resources from my nodes and collecting them on my nagios server. On the nagios server, I've set up resources of these types to be purged:
If I purge a node on the puppetmaster:
On the next puppet run on the nagios server, I might get the following error message:
This doesn't happen all of the time, nor does it happen for all of the nagios_service resources for this node (other nagios_service resources get cleaned up just fine). I've seen this with both the nagios_host and the nagios_service type of resources. It will continue to occur for the same resource on any subsequent run of puppet on the nagios server. To remedy this, I have to manually remove the resource it is complaining about from the nagios configuration and restart the service (something I would like to avoid).
Not sure if it matters or not, but I'm using PuppetDB as the stored configurations backend.
|Comment by Charlie Sharpsteen [ 2014/03/25 ]|
Purge will refuse to remove any resource that is connected to other resources by a dependency edge. This behavior may be incorrect, but has been in place since 2010.
Prior to Puppet 3.3.0, the agent prepared the catalog in such a way that the very first generated resource would be added to the dependency graph. After 3.3.0, no generated resources are added to the dependency graph — so purging should work.
However, require/notify relationships won't be in effect for these resources.
Closing this out as a duplicate of
|Comment by Ken Barber [ 2014/03/25 ]|
Thanks Charlie Sharpsteen.