# Idea storm: things action modules can do (notifications, etc) **URL:** \ **Category:** Ansible Project\ **Created:** [September 18, 2012, 10:17pm UTC](https://forum.ansible.com/t/idea-storm-things-action-modules-can-do-notifications-etc/11906 "2012-09-18T22:17:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [September 18, 2012, 10:17pm UTC](https://forum.ansible.com/t/idea-storm-things-action-modules-can-do-notifications-etc/11906/1 "2012-09-18T22:17:00Z")
Tim Bielawa, Jonathan Sabo, and I have been discussing action modules that can run outside the host loop, like (as Tim originally proposed and is working on), something like: name: pause action: pause msg="Make sure the quantum marzelvanes and veeblefetzers are aligned before continuing" We really want to run that outside the host loop (once per play, so if 200 hosts, just once), , so maybe there is an attribute: outside\_host\_loop: True or maybe even it has an alias like: local\_action\_one\_shot: pause If used with serial: N, it would run (hosts/N) times. But what other sorts of modules would be useful in states like that? I can think of a lot that we could have: \* IRC notification \* Campfire notification \* other chat notification (?) \* Pagerduty \* X10 (ok, maybe not, but maybe you want to turn off the lights when you're done?) These could also be easily combined with the proposed failure handlers too. All of these things could be written as a standard module, and would allow orchestration for things related to software rollout, but not directly related to managing systems. Pretty cool, I think. modules that need to read config settings can load up constants.py and use the functions there to read ansible.cfg, wherever that may be. modules that need certain code to import can import in a Try/Except pattern and yield appropriate errors on usage where their dependencies are not installed. As a result, all of these would make awesome core modules to have. This all speaks to a greater theme of the process of rolling out software or making updates -- not just about config management. What other ideas can you think of or would find useful in the workflow of doing software updates, managing systems, or otherwise orchestrating your nodes? Let's make this happen. --Michael ---
**Author:** ![Chamberlain\_Darren](https://avatars.discourse-cdn.com/v4/letter/c/ee7513/32.png) [@Chamberlain\_Darren](https://forum.ansible.com/u/Chamberlain_Darren)\ **Post date:** [September 18, 2012, 11:16pm UTC](https://forum.ansible.com/t/idea-storm-things-action-modules-can-do-notifications-etc/11906/2 "2012-09-18T23:16:44Z")
Maybe borrow terms from Xunit[1] and call these setup and teardown?   [1]: [http://en.wikipedia.org/wiki/XUnit#Test\_execution](http://en.wikipedia.org/wiki/XUnit#Test_execution) \* Michael DeHaan \ [2012/09/18 18:17]: ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [September 18, 2012, 11:58pm UTC](https://forum.ansible.com/t/idea-storm-things-action-modules-can-do-notifications-etc/11906/3 "2012-09-18T23:58:14Z")
> Maybe borrow terms from Xunit[1] and call these setup and teardown? Interesting idea. Seeing we might want to specify these things in the middle of the playbook (irc notify "halfway there" or whatever) that might not quite solve all possible uses.