ansible fails to restart if handler is broken?

[Kevin Burton]

this is a bug...

TASK: [pdns-recursor | recursor.conf file] ************************************ 
changed: [10.56.252.12]
ERROR: change handler (restart pdns-recursor) is not defined

... so my issue was that the handler wasn't defined (typo).  So now it has a new file, and the daemon NEEDS to be restarted , but it isn't.

Now, when I run ansible again, it does NOT restart the daemon, because the template is already updated.  

The solution here would obviously need to restart the daemon and properly run the handler.

I think the fix is to revert the 'template' so that the previous file was used.  

[Michael DeHaan]

Don't see how this is a bug.  Can you elaborate.

Tried --force-handlers ?

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/de02e7e4-b996-4f1c-b4df-0bd773512d7f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael DeHaan]

No, you actually use that after.

If you had a failure and you needed a handler to run on the next run because something should have triggered but did not, you can use that flag.

The retry suggestion has been made before.

On Thu, Dec 11, 2014 at 11:54 AM, Petros Moisiadis <erne...@yahoo.gr> wrote:

On 12/11/14 18:15, Michael DeHaan wrote:

Don't see how this is a bug.  Can you elaborate.

Tried --force-handlers ?

The option --force-handlers will work only proactively. You must use it _before_ the failure occurs. However, this is almost never the case. Normally, you don't expect your playbook tasks to fail.
A much better solution would be to extend retry files to include handlers that have already been notified before the failure, so that when using the retry files, these handlers are pre-notified regardless of the results of the tasks that notify them normally. I guess that would be a nice feature for v2. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyv%3DeMYD9aWe%2B%3DZT6rPUDT7X2T0PNLK6FT6RYTbPfQn1w%40mail.gmail.com.

[Kevin Burton]

Interesting.  Nice discussion. 

I think one issue is that there would be no easy way to revert tasks that fail without some type of API that instrumented changes.  Either that or have the tasks run in some sort of container that logged changes.  But of course you're not sure what type of changes to expect.  It could be a sysctl, FS changes, API call, etc.  How do you reliably roll those back?

So I guess the solution is to just be careful and know what your scripts are doing.  And maybe in the future tasks could implement a rollback API for when they fail but of course this might not be reliably supported everywhere. 

[Michael DeHaan]

"I am afraid this is not correct. I am testing it now with 1.8.2 and I can assure you that  '--force-handlers' will not trigger a handler if that handler has not been notified by a task."

Can you please paste a minimal playbook that shows this as well as your CLI invocation?

Thanks!

--

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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/30797ca0-8128-4f2e-9600-0650d1b92d40%40googlegroups.com.