# Callback plugins : host available as a task attribute in v2\_playbook\_on\_task\_start() **URL:** \ **Category:** Ansible Developer\ **Created:** [April 19, 2017, 5:06pm UTC](https://forum.ansible.com/t/callback-plugins-host-available-as-a-task-attribute-in-v2-playbook-on-task-start/24251 "2017-04-19T17:06:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Eric\_Salome](https://avatars.discourse-cdn.com/v4/letter/e/8e7dd6/32.png) [@Eric\_Salome](https://forum.ansible.com/u/Eric_Salome)\ **Post date:** [April 19, 2017, 5:06pm UTC](https://forum.ansible.com/t/callback-plugins-host-available-as-a-task-attribute-in-v2-playbook-on-task-start/24251/1 "2017-04-19T17:06:52Z")
Hi, In an Ansible V2 callback plugin : Within def v2\_playbook\_on\_play\_start(self, play): I have the list of hosts to play with in play.hosts (which is fine) Within def v2\_playbook\_on\_stats(self, stats): I have the list of hosts played in stats.processed.keys() (which is fine) Within def v2\_runner\_on\_ok(self, result, \*\*kwargs): I have the host that was run in result.\_host (which is fine) Within def v2\_playbook\_on\_task\_start(self, task, \*\*kwargs): I can’t find out where to get the host that will be run for that particular task (which is bad) Where do I get that information ? If nothing is already provided for, will it make sense to add an attribute “host” to the class Task and put in it : - the host\_name (on which the task will be run) or - the host object from inventory ? (whatever sounds best for you) I’d love to call task.get\_host() from v2\_playbook\_on\_task\_start(self, task, \*\*kwargs) Best regards - Eric ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [April 19, 2017, 6:13pm UTC](https://forum.ansible.com/t/callback-plugins-host-available-as-a-task-attribute-in-v2-playbook-on-task-start/24251/2 "2017-04-19T18:13:51Z")
You don't, normally on\_task\_start is called before hosts are iterated over. ---
**Author:** ![Eric\_Salome](https://avatars.discourse-cdn.com/v4/letter/e/8e7dd6/32.png) [@Eric\_Salome](https://forum.ansible.com/u/Eric_Salome)\ **Post date:** [April 19, 2017, 10:44pm UTC](https://forum.ansible.com/t/callback-plugins-host-available-as-a-task-attribute-in-v2-playbook-on-task-start/24251/3 "2017-04-19T22:44:41Z")
I guess it might depend on current (and future) strategies. But for the time being, an host has always been elected for queuing task before on\_task\_start is called. At least for the free strategy, the two followng calls come together : ```auto self._tqm.send_callback('v2_playbook_on_task_start', task, is_conditional=False) self._queue_task(host, task, task_vars, play_context) ``` And it could be a good idea (option in /etc/ansible/ansible.cfg ?) to enforce that on\_task\_start is called before _each_ call to \_queue\_task() if needed, whatever the strategy used. If one prefers a single call to “on\_task\_start” with no host for the linear strategy (whatever the number of hosts launched) no problem, the option will deal with that too. (by the way, the “patch” to implement the idea is not very difficult to code) Best regards - Eric ---
**Author:** ![Eric\_Salome](https://avatars.discourse-cdn.com/v4/letter/e/8e7dd6/32.png) [@Eric\_Salome](https://forum.ansible.com/u/Eric_Salome)\ **Post date:** [April 23, 2017, 12:43pm UTC](https://forum.ansible.com/t/callback-plugins-host-available-as-a-task-attribute-in-v2-playbook-on-task-start/24251/4 "2017-04-23T12:43:57Z")
Hi, As I mentioned, “patch” to implement the idea was not difficult to do. Yet, it should be reviewed (and corrected if needed). The following files were impacted : ./lib/ansible/config/ **init**.py ./lib/ansible/vars/reserved.py =\> to create an “option” by vars (but does it need to be an option ?) ./lib/ansible/playbook/task.py ./lib/ansible/plugins/strategy/free.py ./lib/ansible/plugins/strategy/linear.py ./lib/ansible/plugins/strategy/ **init**.py ./lib/ansible/plugins/callback/default.py =\> We now have a callback at the start and at the stop of each task for a specified host whatever the strategy used : We then should be able to do the following : - know in real time which tasks are still running, those finished and those yet to come. - know the hosts in strategy=linear that never end a task (thus preventing the launch of the next task for all hosts) - suspend execution of a task for a specified host untill all external requirements are done - change the level of debug for a specific host/task - etc Banners (at start of task for a group of hosts) are done as before. Best regards - Eric