Issue #789 has been updated by luke. Status changed from Needs design decision to Rejected Affected version set to 0.24.4
As DavidS says, this is currently better done using resource purging, and the long term correct solution is just to have the client track changes to the resource catalog, and then have some general policy about what those changes mean. E.g., we could track when resources were in the old catalog but are not in the new catalog. We could then have a policy that said, purge any resource that we remove from our catalog. These are two relatively straightforward steps, and involve less work all around. ---------------------------------------- Feature #789: Configurable automatic object's purging http://projects.reductivelabs.com/issues/show/789 Author: tim Status: Rejected Priority: Normal Assigned to: luke Category: unknown Target version: unplanned Complexity: Unknown Patch: None Affected version: 0.24.4 Keywords: While talking on IRC, Spike and I figured it could be worth while to make this a feature request. The problem: When you delete an object in your manifest, it's not handled anymore on the client. The best way at present to make it also delete the object on the client is to leave it in the manifest with some kind of "ensure => absent" declaration. Although this works in a lot of places, it can be very ugly and inconvenient, especially when you're building a module. A solution: Allow for a "control" parameter on object basis. Make it best practice to have this always default to something like "not-puppet". When the parameter is set to "puppet" *manually in the manifest*, allow puppet to run some pre-determined defined command to remove it. This would mean that puppet would need to check on each run if the list of available "puppet-controlled" objects has been changed in comparison with the last puppet run. If so, if any has been removed, run the pre-determined defined method with the name of the object to actually remove it. Problems: Lots. Even when not counting on sysadmin messing things up. Cache problems between runs could be one problem. I personally think that most problems could be solved by simply using sane defaults: If anything goes wrong, yell, but don't change anything. I'd be happy if this feature was only available for puppet modules, but I can imagine further widespread usage of this. You also might want a global setting that simply disables this behaviour, even when control => puppet is explicitly set. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
