Puppet should retain information about what's managed to facilitate removing no-longer-managed resources
|Status:||Needs Decision||Start date:||12/08/2009|
|Affected Puppet version:||0.25.1||Branch:|
all resources used in manifest should be recorded and stored in “shadow manifest” and then applied with “ensure => absent” while they dissapear from “real manifest”. this would be an elegant way to purge configuration on servers that has been removed from pp’s.
additionally “revert” metaparameter should be defineable (possibly with default value of false – for compatibility). it could be true (ie. for files, crons, etc – where removal method is obvious) or specific command to execute (ie. for reverting exec’s and other non-obvious types).
optionally puppetmaster should log where there’s garbage left on puppets (ie. things removed from “real manifest” but not reverted from “shadow manifest”).
#1 Updated by Luke Kanies over 3 years ago
- Subject changed from resource bucket / shadow manifest to Puppet should retain information about what's managed to facilitate removing no-longer-managed resources
- Status changed from Unreviewed to Needs Decision
I’ve been thinking about this basic idea for a long time, thinking of it more as three way merge than a ‘shadow catalog’ or whatever, but it’s the same idea.
I’d also like it to integrate with ralsh well enough that ralsh would tell you when you were modifying a managed resource, and you could even have policies to say that if a resource is modified outside of Puppet then Puppet should just warn of a merge problem rather than overwrite the change.
In terms of reversion, yeah, you need some ability to do the opposite of an exec, but I think essentially everything else can be pretty easily reverted without any additional parameters, as long as you have a filebucket, package source, etc. There will always be some stragglers, but it shouldn’t be too bad.
I’ve made some progress toward this in a branch (feature/event_manager/rollback in my repo), and it does successfully roll limited transactions back. There’s still a ton more to do, though.
Could you split this into separate tickets, one for the ‘remove no longer managed’ bits and one for the ‘ability to revert any change’ bit?