19:00:05 #startmeeting ansible core 19:00:06 Meeting started Tue Oct 31 19:00:05 2017 UTC. The chair is thaumos. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:06 The meeting name has been set to 'ansible_core' 19:01:05 * gundalow waves 19:02:19 #chair gundalow 19:02:19 Current chairs: gundalow thaumos 19:02:25 * thaumos waves back at gundalow 19:02:52 * Qalthos 🌊🌊 19:03:17 blorp 19:03:49 hello 19:04:16 o/ 19:04:31 #chair Qalthos alikins jtanner funzo 19:04:31 Current chairs: Qalthos alikins funzo gundalow jtanner thaumos 19:05:54 o/ 19:06:30 #chair nitzmahone 19:06:30 Current chairs: Qalthos alikins funzo gundalow jtanner nitzmahone thaumos 19:07:15 hrm, this looks like #core_internal West ATM 19:07:23 pretty close 19:08:52 I'm here :) 19:08:58 hi there 19:09:01 #chair cognifloyd 19:09:01 Current chairs: Qalthos alikins cognifloyd funzo gundalow jtanner nitzmahone thaumos 19:09:12 I am not sure if bcoca is joining or not 19:09:24 ola 19:09:25 what's on the agenda? 19:09:28 #chair abadger1999 19:09:28 Current chairs: Qalthos abadger1999 alikins cognifloyd funzo gundalow jtanner nitzmahone thaumos 19:09:54 #topic Add adhoc callbacks to mirror playbook start/stats 19:09:58 #link https://github.com/ansible/ansible/pull/32304 19:10:07 cognifloyd's PR is the only topic for today. 19:10:17 bcoca and him have a discussion in the PR about it. 19:10:23 sivel is for this as well. 19:10:37 whoa sorry, hey 19:10:38 @cognifloyd have anything you'd like to add in here as a part of the discussion in the PR? 19:10:39 +1 19:10:45 #chair sivel 19:10:45 Current chairs: Qalthos abadger1999 alikins cognifloyd funzo gundalow jtanner nitzmahone sivel thaumos 19:10:54 lol sivel 19:10:55 I am in a priority planning meeting, so kinda here-ish, not here-ish 19:10:58 no worries 19:11:03 +1 19:11:04 I didn't intend for you to ping in 19:11:09 I've needed this for things in the past too 19:11:16 just wanted to make sure you were somewhat a part of the convo still bud 19:11:30 I am +1 for this as well, are we cool with it being in 2.5? 19:11:32 I like the idea of 32304 19:11:59 haven't tested/tried the impl 19:12:12 First: My computer is very slow until this blasted VM finishes shutting down ... :P 19:12:21 +1 19:13:11 Anyway. I think it makes sense to make callbacks work the same for adhoc as for playbooks. Even if we decide not to add v2_playbook_on_start, I hope at least v2_playbook_on_stats makes it in. 19:14:00 pr might be more accurately called something like 'Use a implicit playbook for adhoc instead of just a play'. Maybe could go a step or two further in that regard even. 19:14:51 At first I had separate callbacks, v2_adhoc_* (I did that so that it'd be completely backward compatible and callback plugins would have to opt in to supporting adhoc callbacks), but bcoca said it'd be better to reuse the v2_playbook callbacks instead of adding new ones. 19:17:31 Ultimately I did this because, as @armab pointed out, I'm trying to reuse adhoc commands in another program. For example: `ansible -m setup some.host.com | jq '.some[query].here'` 19:18:57 So looks like we have 4 +1 and 0 objections from committers. 19:19:07 +1 19:19:21 swoop voting 19:19:33 back to my question though, are we cool with including it in 2.5? 19:19:49 * cognifloyd is, but that's probably obvious. 19:19:50 I assume yes due to all the +1's, but I like to trust but verify 19:19:58 +1 to the events, just not sure the playbook object makes sense as is (no real feedback, just a feeling ... must thingk aobut it) 19:19:59 if it passes tests before then, sure 19:20:13 Yeah, the playbook object felt weird. 19:21:02 cognifloyd: as for the json output, you might be able to once my 'globalize callbcks' PR gets in 19:21:10 though you might need |head in verbose mode 19:21:33 cognifloyd: what does using adhoc that way gain you over 'ansible-playbook -i some.host.com -e "some_param=foo" | jq ...' ? 19:21:41 thaumos: yah, +1 from me for 2.5 19:21:58 Almost. Right now, the json callback (with globalize callbaccks) would still only work if there was an on_stats or something similar at the end. 19:22:26 so, for the topic, it looks like that we're good to merge. 19:22:35 should we continue the rest of the discussion in #ansible-devel? 19:22:37 alikins: json callback does most display work on stats, rest of methods just gather data for final output 19:22:38 or here? 19:23:11 We don't have anything else on the agenda, unless dag shows up for his item 19:23:37 open floor? 19:23:51 #topic Open floor 19:23:53 yeah 19:23:54 it is 19:23:57 https://github.com/ansible/ansible/pull/32275 19:24:20 #topic playbook dir option 19:24:28 #link https://github.com/ansible/ansible/pull/32275 19:24:36 +1 from me on this 19:24:44 ^ for console/adhoc since neither of them have a playbook dir and cannot pick up extra group/host/vars plugins vars 19:25:06 also 1st step for allowing include_role to work in adhoc 19:25:42 and includes in general, for when they need templates/ etc 19:30:04 CLI Option? sure, looks nice. Could you write an integration test too? Should be an easy script to write. 19:30:13 (but not blocking the initial PR for the test) 19:30:26 I just had someone complaining that ansible-inventory didn't pick up play relative group_vars, so I'd say +1 it oculd be useful 19:30:44 sivel: yep, aslo added to that 19:31:39 +1 ... "inventory" is an amalgamation of vars from various places and all should be considered 19:32:36 include_role in adhoc is an interesting topic though 19:32:41 that was part of it, its basically a stopgap to a 'project' concept 19:33:04 project concept? 19:33:16 jtanner: include_tasks also ... import_playbook ... i'm tempted to give specific .. just use asible-playbook warning 19:33:42 cognifloyd: most people treat their ansible layout as a 'project' and expect the top level dirs to be meaningful to playbooks all the way down 19:33:49 test/playbooks/x.yml 19:33:56 look in group_vars/stuff 19:33:59 or roles/stuff 19:34:54 ok 19:37:31 ok so vote 19:37:48 merge playbook dir option +1, -1 19:38:00 +1 19:38:37 +1 19:39:41 +1 (from a non-committer *shrugs*) 19:40:50 +1 19:41:20 * thaumos captured jtanner's +1 19:41:32 * thaumos and sivels 19:41:35 merged 19:41:44 sorta rebirth of Ansiblefile 19:41:57 alikins: ? 19:41:57 lulz ... 'while you were out voting, i was merging' 19:42:04 https://github.com/ansible/ansible/pull/32280 19:42:19 pssash whatever 19:42:20 jtanner: nah, was waiting for any negative, pressed merge after YOUR +1 19:42:22 lol 19:42:30 bcoca ninja merged it anyways 19:42:36 after the first +1 came in 19:42:40 I saw it happen 19:42:43 bcoca merged commit 95b31a3 into ansible:devel 38 seconds from now 19:42:49 ^ i merged it in my tardis 19:42:55 exactly 19:43:02 k, next open floor 19:43:06 so by "globalize", you mean bring it up to the cli layer and pass it down? 19:43:07 #topic Open Floor 19:43:08 ^ new PR above 19:43:21 missed that, thanks bcoca 19:43:24 jtanner: in part, also means 'hijacking' most of display methods and allow callbacks to controll them 19:43:34 #topic Globalize callback 19:43:35 i also update json callback as example 19:43:41 #link https://github.com/ansible/ansible/pull/32280 19:44:00 not ready for merge, jsut want to make sure everyone is OK with my approach 19:44:04 its really hackish 19:44:22 I haven't really reviewed the approach, just a couple of quick things I noticed 19:44:30 but its only way i saw to do this in w/o rewriting every call to display 19:45:17 also preserves current behaviour unless user/callback specifically wants to override it 19:46:10 https://github.com/ansible/ansible/pull/32280/files#diff-b433171851ee6e9ab6c4f98f233678b5R100 <= the 'hackish' part 19:46:13 bcoca: I'd rather implement that using a more standard oop pattern 19:46:20 but the idea is okay. 19:46:37 abadger1999: he, expected that, im open to suggestions, just got this working in 5mins (to my suprise) 19:46:43 19:47:11 bcoca: I'll look and make a suggestion and how to change it 19:47:19 i had never had an object 'copy and paste' methods from another 19:47:34 I like the idea of #32280 but not really the current impl 19:48:15 im not even looking at this as permanent solution, but quick way to enable the functionality while we work on a more thorugh design 19:48:37 i just feel it is currently very hackish, want to see what other alternatives we can work with 19:49:06 abadger1999/bcoca: 'I'd rather implement that using a more standard oop pattern' - yup 19:49:46 this breaks every pattern i ever though possible i'm 'side classing' from 2 objects w/o having inheritance 19:51:06 im both horrified and proud of said hack ... 19:51:30 heh. Yeah, I think this is a has-a pattern 19:51:49 Just instead of monkey patching, call callback.v() if it exists. 19:51:54 abadger1999: but reversed, display has a callback and then steals it's method for tiself 19:52:35 Might want to allow callback to have v undefined too. 19:52:38 abadger1999: tried that but got very slow during debug 19:52:42 for some definition of undefined 19:52:45 Hmm... 19:52:53 abadger1999: if not defined, it is not overriden 19:53:00 also avoids expenisve hasattr calls 19:53:20 bcoca: yeah but I mean... it would be nice for the callback baseclass to define all of the methods that are special to callback plugins 19:53:24 once 'set' its all direct calls, all the expense is on initial setup 19:53:36 So it would be nice for it to have a v() method that does not override display. 19:53:45 abadger1999: agreed, again, this was quick fix, and callbcaks used to NOT have all display functions 19:53:53 re-implement display as callbacks[1] seems like a reasonable goal. [1] callback in the general non-ansible specific meaning 19:53:57 abadger1999: ??? 19:54:10 doesnt it having a v method mean it SHOULD override display? 19:54:11 alikins: yeah... I was thinking that might also work 19:54:21 bcoca: not if v() does nothing. 19:54:34 abadger1999: then you basicaly break existing v? 19:54:44 bcoca: I'll show you some code so you can see what I'm saying 19:55:11 alikins: this is basically a 'callback' by overriding teh function ref directly vs a 2 step one 19:57:20 abadger1999: the other thing is that there are callbacks that dont use callbackbase, so i was remiss on making this depend on that 19:57:22 bcoca: https://paste.fedoraproject.org/paste/7Wxt2xDJR-SZCd5OYqzteQ 19:57:43 bcoca: but then, of course, we have to change how display decides to use the callback versus its own thing 19:57:57 abadger1999: i see the code, still dont understand how that does not break display 19:58:09 bcoca: we're coming up on the end of the hour... shall we move this to #ansible-devel 19:58:09 cause method exists, so display would use the 'noop' vs existing 19:58:14 let's continue this in ansible-devel? 19:58:18 * dag is back 19:58:20 k 19:58:21 we have to wrap up for our windows friends 19:58:22 dag... 19:58:24 dag is here, lets leave 19:58:25 wth man 19:58:28 not sure if there's still time :) 19:58:30 bcoca: (and the answer is... yes, it breaks display... that's why I say we have to change display as well) 19:58:34 you always come back at the end 19:58:43 not in two minutes dude 19:58:49 abadger1999: eventually, yes, but did not want to go that far at this point 19:58:54 can you be here on thursday? 19:59:01 yeah, it's halloween :-) 19:59:07 thaumos: sure, no urgency 19:59:25 ok 19:59:27 I have to mention that is starting to make callback/display look more and more like an accidental 'logging' re-implementation 19:59:51 alright folks, closing out for today! 19:59:51 alikins: part of this was to make 'display.log' load your 'python logging' callback 19:59:54 thanks for the discussions! 20:00:01 #endmeeting