I wouldn't want the system to generate two seperate files, but it could generate a new system for retries.
We can think about this. On Tue, Mar 18, 2014 at 10:40 AM, Petros Moisiadis <[email protected]>wrote: > On 03/18/14 16:20, Michael DeHaan wrote: > > "Being it a command line option does not help, because you do not know > before running the command that any of your tasks is going to fail and how." > > Incorrect, because you would use this when running the retry command > only. > > Well, it did not occur to me that you could actually use that option > _after_ the failure. :-[ > However, I think that a more controllable tool to run handlers selectively > could be more powerful for recovering from unexpected deployment failures. > For example, have ansible generate a file with a list of notified but not > executed handlers, which you can edit as you want and then pass it to a > '--handlers-file' option, in a similar fashion to how limit files work for > limiting hosts. > > > > > > On Tue, Mar 18, 2014 at 10:18 AM, Petros Moisiadis <[email protected]>wrote: > >> On 03/18/14 14:44, Michael DeHaan wrote: >> >> "For example, if a task that changes a server's configuration fails, >> forcing the execution of a handler that reloads/restarts the server could >> lead to the server failing to operate properly or be able to serve at all. " >> >> This is why it's a command line option to be used only when desired. >> >> Being it a command line option does not help, because you do not know >> before running the command that any of your tasks is going to fail and how. >> >> I think that the correct analysis of the problem is like this: >> >> You have designed a sequence of deployment tasks that should be run in a >> specific order. Your task specification language (ansible playbook) does >> not know what is the best thing to do if task execution is abnormally >> interrupted. Only you, the ansible user, will be able to know what should >> be done. Normally you expect everything to run fine, but, if something goes >> wrong (and things can still go wrong on production deployments, even after >> passed tests), you want your action to stop as early as possible. At the >> same time you want to have the tools that will help you to mitigate the >> problems caused by the abnormal interruption. And you want full control >> over these tools. You do not want the tools to decide for you on what >> should be done. You are the one to decide, and you can't do so before you >> actually see what and how it failed. >> >> So, you need a tool to run already notified handlers (or part of them), >> but you will use it only if it is good for the health of your system. You >> cannot decide about that until you actually see what happened. >> >> >> >> >> On Tue, Mar 18, 2014 at 8:22 AM, Petros Moisiadis <[email protected]>wrote: >> >>> On 03/17/14 15:51, Michael DeHaan wrote: >>> >>> There was a post about this last week about adding a --force-handlers >>> statement. >>> >>> This can be done though we're currently chasing some other items >>> presently. >>> >>> Pull requests would be welcome. >>> >>> >>> >>> >>> On Sat, Mar 15, 2014 at 1:12 PM, Julio Monteiro <[email protected] >>> > wrote: >>> >>>> Hello all, >>>> >>>> I am curious if/how Ansible plans on solving the "replay notifications" >>>> issue. I am having the exact same issue as reported on this StackOverflow >>>> question (the author does a great job describing the issue): >>>> http://stackoverflow.com/questions/21538516/ansible-how-to-replay-notifications >>>> >>>> I find that it is easy to prevent that by, instead of using >>>> notifications, using tasks with "when:" statements. But I really find that >>>> this is a workaround and notifications are great and easy features -- it >>>> should be a default way to replay them, or at least have a list of >>>> queued-but-not-executed notifications whenever a task fails. >>>> >>>> Thanks, >>>> jmonteiro >>>> -- >>>> 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/64e1dbe8-5b36-4e6b-b521-f086d2952008%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/64e1dbe8-5b36-4e6b-b521-f086d2952008%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> 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/CAEVJ8QNy-TU-EmK_i8%2BZLDMD9DFqC-UfvG4OAAc9J7sY6amSgQ%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAEVJ8QNy-TU-EmK_i8%2BZLDMD9DFqC-UfvG4OAAc9J7sY6amSgQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> Usually the task that notifies a handler has made some changes that >>> affect the behavior of systems involved by the actions being taken in the >>> handler. If the notifying task fails, but its handler is forced to run, >>> then the behavior of the involved systems could be unpredictable or >>> unwanted. For example, if a task that changes a server's configuration >>> fails, forcing the execution of a handler that reloads/restarts the server >>> could lead to the server failing to operate properly or be able to serve at >>> all. So, I think that a '--force-handlers' option is quite risky and could >>> lead to unpredictable behavior. It would be better to let users control the >>> (selective) replaying of the handlers only _after_ the failure occurs. >>> -- >>> 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/53283A78.8000207%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/53283A78.8000207%40yahoo.gr?utm_medium=email&utm_source=footer>. >>> >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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/CAEVJ8QNYsfvGxhGfMhCzBGVoh7p1i0qpG7bJaHMU%3D9empnhnEw%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAEVJ8QNYsfvGxhGfMhCzBGVoh7p1i0qpG7bJaHMU%3D9empnhnEw%40mail.gmail.com?utm_medium=email&utm_source=footer>. >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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/532855CE.7040309%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/532855CE.7040309%40yahoo.gr?utm_medium=email&utm_source=footer>. >> >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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/CAEVJ8QOM09Gi23MT4A-kX8yOBX%2Bfc0%2BNC%3DO54BDjvQoq8gDdtg%40mail.gmail.com<https://groups.google.com/d/msgid/ansible-project/CAEVJ8QOM09Gi23MT4A-kX8yOBX%2Bfc0%2BNC%3DO54BDjvQoq8gDdtg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > > > -- > 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/53285AF2.3040604%40yahoo.gr<https://groups.google.com/d/msgid/ansible-project/53285AF2.3040604%40yahoo.gr?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAEVJ8QMO%3DOpfyJU2SzjddMUmRCASZmqTi8RGPCxLCZy9ras0DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
