# (developers) callbacks are now modular! Connect with logfiles, datastores, and more. **URL:** \ **Category:** Ansible Project\ **Created:** [August 19, 2012, 12:43am UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811 "2012-08-19T00:43:15Z")\ **Posts on this page:** 6\ **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:** [August 19, 2012, 12:43am UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/1 "2012-08-19T00:43:15Z")
Earlier today I announced that connection types were pluggable. Now modules are too! If you want to write code that does additional logging, stores ansible results in a database, sends you email, or makes "pew pew" lasergun noises as your playbooks are going off, this is the feature for you! (I may seriously have to do that lasergun noise thing). Look in lib/ansible/callbacks and read the source to "noop.py"     [https://github.com/ansible/ansible/blob/devel/lib/ansible/callbacks/noop.py](https://github.com/ansible/ansible/blob/devel/lib/ansible/callbacks/noop.py) noop means "no operation", and this is the most boring callback ever. However, you can easily copy this class, drop it in another directory, and add code to the methods contained within -- then ansible can interface with whatever you want. You don't have to define all the functions -- just the ones you use -- and the class should be named exactly the same (no subclassing), when you drop it into the plugins directory. I expect that over time there will be something like an ansible-plugins repo, for storing things in differnet places, sending notifications, and so on. The list of callbacks we have now is not neccessarily all we're ever going to have -- so if there is some kind of event you'd like to hook up to, let me know, and we can probably make a callback for it. I have tested this with all of the sample playbooks in the "examples/" directory and haven't hit any problems, though there may be some lurking -- testing is welcome. Have fun and let me know if you develop anything interesting using this, let me know! --Michael ---
**Author:** ![Stephen\_Major](https://avatars.discourse-cdn.com/v4/letter/s/c77e96/32.png) [@Stephen\_Major](https://forum.ansible.com/u/Stephen_Major)\ **Post date:** [August 19, 2012, 12:51am UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/2 "2012-08-19T00:51:12Z")
nice, real time analytics with elasticsearch will work nicely with this ---
**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:** [August 19, 2012, 12:57am UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/3 "2012-08-19T00:57:36Z")
Yep, you'll probably want the "playbook\_on\_stats" method for this. I'm thinking a Graphite/Carbon sender would be pretty awesome as well.   (Ditto any of the other monitoring apps) Once we get a couple of interesting callbacks written, I'll host a ansible-callbacks repo full of useful ones. ---
**Author:** ![Lorin\_Hochstein1](https://avatars.discourse-cdn.com/v4/letter/l/ce73a5/32.png) [@Lorin\_Hochstein1](https://forum.ansible.com/u/Lorin_Hochstein1)\ **Post date:** [August 19, 2012, 5:20pm UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/4 "2012-08-19T17:20:27Z")
Cool. If I wanted to implement a plugin that stopped ansible from continuing after it encountered a failure, is it safe to do something like: def runner\_on\_failed(self, host, res, ignore\_errors=False): sys.exit(1) Or is there any cleanup that needs to be done before exiting? Take care, Lorin ---
**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:** [August 19, 2012, 8:49pm UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/5 "2012-08-19T20:49:12Z")
Yeah, not quite. All the temp file deletion per host would be done by then, but since Ansible uses multiprocessing (a Python library) and forks, sys.exit would only terminate one of the forks and not in a very clean way. So it's not really what you want. If you want to do that, it's probably better to introduce an extra callback specific to playbooks (patches accepted) when it detects that some hosts have failed which then raises an errors.AnsibleError -- which will stop everything with a nice string message as opposed to a less nice Python stacktrace. Kinda what I was alluding to in the email -- I think it will probably make sense to introduce a few more types of callbacks, and it's safe to do this because, the way things are written existing callback modules don't have to define functions they don't use. You would just need to find the right things to add to lib/ansible/playbook/\_\_init\_\_.py and lib/ansible/callbacks.py ---
**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:** [August 19, 2012, 11:17pm UTC](https://forum.ansible.com/t/developers-callbacks-are-now-modular-connect-with-logfiles-datastores-and-more/11811/6 "2012-08-19T23:17:20Z")
Thinking about this a bit, a better version of this callback would probably be "playback\_on\_runner\_results" where it could be fed the full hash of the runner results as well as the method name. (Patches still accepted, just don't think it should be error specific as you're going to get back a lot of different hosts at once)