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:
On Friday, May 23, 2014 6:16:28 AM UTC-6, Michael DeHaan wrote:
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 :-)
--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/537FB635.7070900%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
