[ansible] runner + callbacks: allow callbacks to template the delegates (#8432)

Archives Ansible Developer
1

Hi Michael,​

In reference to your comment on my PR 8432:

From: Michael DeHaan <notifications@github.com>
Date: 4 August 2014 20:11
Subject: Re: [ansible] runner + callbacks: allow callbacks to template the delegates (#8432)

Not sure I’m comfortable with all the calls to “get_inject” or understand all that’s going on here.

view it on GitHub.

Why this PR: a recent patch now shows the delegate_to: host via playbook callbacks. This is quite nice, but one forgot to take into account that delegate_to: can contain variables and needs to be templated.
A we use templated delegates a lot, it is quite important to get the templating right (and hopefully merged into the upcoming version, or we’ll have lots of people confused…)

The callback can access the current Runner object, and uses here runner.module_vars to retrieve the delegate. These however does not contain a templated version, but the original construct from the playbook dataset.

Now keep in mind that:

  • Runner templates delegate_to: but does not keep that templated version available outside of the function that uses it.

  • The original delegate_to variable is available in the inject, but the inject is not kept as a Runner() variable, and is only passed through Runner methods.

James C. proposed to put the inject generating code into a separate method, so the callback can call that via its Runner object.

So this patch

  • moves the inject calculating code in a separate method, and does some caching

  • the callback retrives the (cached) inject through that method

(inject can obviously not be retrieved just once in the callback’s constructor)

Moving that code into a separte method is a first step that James wanted to do when refactoring Runner().

The caching is right now only used by the callbacks, to keep this lightly.

​
I’m totally open to other/better ways to solve this. My first idea was to make the inject a Runner() object variable (as in self.inject). There might be other ways that are more future proof if you guys have particular ideas on how to refactor Runner.

Thanks,

Serge

2

Thanks for the email Serge.

My general thought is the callback module should remain pretty dumb (because it’s not fair to the authors of the callback to know things, and also because some intent to wish to follow some things like the Law of Demeter (sort of) and not expose too many internals throughout class boundaries (which we don’t always do well, but wish to correct when we see them).

Anyway, I want to start building a stronger dividing line between Runner and the rest of the code, since that eventually makes Runner and other areas a lot more safer and less tightly coupled.

So in this case, I could be very very wrong, but it seems we could template the “delegate_to” prior to calling the callback and this MAY be a one-line fix.

3

​Well, almost yes, I forced updated the PR with a new fresh commit :slight_smile:

4

Yep, this was a nice patch, thanks!