One thing you can do is write each role in two modes ("apply" and "remove"), apply it to all hosts, and hope you don't have too many left-overs ;-).
You can select hosts where it should be applied by setting defaults inside a role for the "remove" case, and overwriting it in group_vars.
This of course makes your roles much more bulky (and full of state={{ this_roles_target_state }}), and the removal won't ever be 100% reliable.
Dnia pią, 23 maj 2014, 22:11:21 Dmitry Makovey pisze:
No config system really handles "this shall not be X".
sounds like NixOS is doing that. Granted their config management is built
into the OS giving it some advantages in tracking state.
What NixOS does is pretty much what Michael proposed - recreating things from scratch. Well, at least the Nix-managed parts of the OS, like most of /etc.
They built the whole new system side by side with the running one (the way packages are stored in Nix makes that possible), and then use an "activation script" to switch from the old config to the new (restarting services that changed, starting new ones, stopping unneeded ones etc.).
IIRC you can still put your own files in /etc (you just can't edit the Nix-managed ones) so that leaves you with some dirty state.
If you are using cloud hosts, it's easier to destroy the hosts, and that's
the generally accepted way to do it.
sure, clouds with disposable OS'es - kind of tolerable. But even then - you
don't want to "re-format" your entire cloud just to move services from A to
B? What if that is a chain move with more hosts involved?
If it's a chain move you'll need to orchestrate it somehow anyway, so just removing things is not enough.
Actually, you'd probably want to move some data, disable the service on old host, move the rest of the data, enable it in it's new home,
and only then purge it from the old one - that's not something Ansible is able to figure out by itself, it can only help with applying the actions.
P.S.
not trying to start a flame-war or point a finger of blame - just looking
for some solution (or workaround).
What you are asking for is really hard to do right (even handling configuration and state from removed packages is a huge problem, without getting into live parts and uptime :-)).
My proposed workaround (that you'll probably only apply to roles that will be moved like that) is at the top of this message. Hope it helps at least a bit