When I run the osbs playbook to create a new VM I got the following error
EXECV: /usr/bin/sudo -i /bin/bash -i -c cd /srv/web/infra/ansible ; /usr/bin/python2 /usr/bin/ansible-playbook /srv/web/infra/ansible/playbooks/groups/osbs-cluster.yml -l osbs-masters-stg PLAY [make the virtual instance] *********************************************************************************************************************************************************************************$ [WARNING]: Failure using method (v2_playbook_on_play_start) in callback plugin (<ansible.plugins.callback.fedmsg_callback2.CallbackModule object at 0x52f1210>): 'CallbackModule' object has no attribute 'play_context' [WARNING]: Failure using method (v2_playbook_on_play_start) in callback plugin (<ansible.plugins.callback.logdetail2.CallbackModule object at 0x52f1f90>): 'CallbackModule' object has no attribute 'play_context'
It looks like the fedmsg_callback2 and logdetail2 plugins needs to be updated for ansible 2.5
Here's the upstream conversation about this:
Apr 18 12:41:49 <abadger1999> bcoca: [12:38:41] <nirik> abadger1999: might you have a sec to look at some callback p lugins? after 2.5.0 ours are sending a warning: "[WARNING]: Failure using method (v2_playbook_on_play_start) in callbac k plugin (<ansible.plugins.callback.fedmsg_callback2.CallbackModule object at 0x52f1210>): 'CallbackModule' object has no attribute 'play_context' ' Apr 18 12:42:04 <abadger1999> bcoca: ^ I think that might be fallout from your change to callback plugins? Apr 18 12:42:27 <nirik> https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/callback_plugins/fedmsg_callback 2.py is the plugin... Apr 18 12:43:27 <bcoca> does not look related to my changes Apr 18 12:43:58 <bcoca> set_play_context not being called? Apr 18 12:45:34 <bcoca> .. setting play context has not changed in tqm in a looong time ... but code 'before it' has Apr 18 12:47:13 <abadger1999> nirik: Looks like new bug, then. Apr 18 12:47:44 <nirik> huh, ok. it did work ok with 2.4.x I am pretty sure. Apr 18 12:48:22 <bcoca> 1b8c2a2b0b1b87b41598f44ae57b17dfcc83ac73 <= only recent change i've found tha tmight be related Apr 18 12:49:15 <bcoca> which might make sense if we have not set_play_context yet at that point Apr 18 12:50:12 <bcoca> ... im going to say error is valid, you are not guaranteed play_context at that point, since if 'no hosts match' it bypasses creation Apr 18 12:50:23 <bcoca> ^ checking to see if that is the cause Apr 18 12:51:52 <bcoca> looks like that is the issue, on_play_start can be called in 2 spots, 1 of them is before play_ context exists Apr 18 12:52:18 <bcoca> so 'it worked' before the change ... but that was due to bug in existing code, once bug is fixe d, this breaks when no hosts are matched Apr 18 12:52:34 <nirik> ok Apr 18 12:53:10 <bcoca> 2 solutions, check if play context exists first or we add 'dummy' play_context in the other cal l ... but that requires core change Apr 18 12:53:53 <nirik> ok, I can add a check then... I don't know how many other folks would hit this... Apr 18 12:54:15 <bcoca> others probably use cli/self._optoins to get check_mode, which you always have Apr 18 12:54:43 <bcoca> play_context is guaranteed at task level, but not in that particular event Apr 18 12:55:11 <bcoca> 99 is redundant use, you only get there if false Apr 18 12:57:32 <bcoca> hmm, nvmd, creating playl_context there not useful .. have no way of passing to callback
If anyone wants to get this before me, feel free...
Metadata Update from @kevin: - Issue assigned to kevin - Issue priority set to: Waiting on Asignee
Either someone fixed this or it was fixed in a newer ansible version.
:house:
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.