(developers) callbacks are now modular! Connect with logfiles, datastores, and more.

Archives Ansible Project
1

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

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

2

nice, real time analytics with elasticsearch will work nicely with this

3

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.

4

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

5

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

6

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)