On Wed, 9 Mar 2016 09:22:40 -0500 Josh Smift <[email protected]> wrote: > Would a > > - meta: flush_handlers > > task, immediately after the copy task (or whatever populates /etc/aliases, > and does the notify), do what you want in this case? It still wouldn't > help if the SSH connection dies immediately after the copy task, but > there's not a whole lot you *can* do in that case. If it's important > enough, maybe come up with a single shell task that populates the file and > runs the handler, so the whole thing will happen even if SSH dies after > the task, but that seems ugly unless it's essential that a particular > task+handler combo be as close to atomic as possible. >
Hm... Well, would make the window of opportunity smaller, so possibly one way to about it. I wonder how people out there handle this when using a lot of VMs (my use-case will be under 10). Another thing that popped to my mind just now is to have a set of tagged tasks within a role that would not execute unless tag is provided that duplicate any handler/task that may need to be re-run to fix possible inconsistencies. That way in case I detect a failed run, I could rerun those tasks to fix things up. Any opinions on this? I just wonder if I could abuse tags in this way, though (i.e. having a when: tag defined syntax). Best regards -- Branko Majic Jabber: [email protected] Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: [email protected] Молим вас да додатке шаљете искључиво у слободним форматима. -- 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/20160315115355.64e092fd%40zetkin.primekey.se. For more options, visit https://groups.google.com/d/optout.
