19:00:42 #startmeeting Engine meeting 19:00:42 Meeting started Tue Jul 11 19:00:42 2017 UTC. The chair is thaumos. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:42 The meeting name has been set to 'engine_meeting' 19:01:23 * thaumos needs to get his bearing 19:02:11 hello 19:02:16 hi 19:02:16 o/ 19:02:23 hi 19:02:27 hi 19:02:31 blorp 19:02:33 wurg wurg 19:02:38 #chair abadger1999 ryansb dag itdependsnetwork alikins abraverm jtanner 19:02:38 Current chairs: abadger1999 abraverm alikins dag itdependsnetwork jtanner ryansb thaumos 19:02:48 good list of peeps today 19:02:54 hello 19:03:02 #chair ghusson 19:03:02 Current chairs: abadger1999 abraverm alikins dag ghusson itdependsnetwork jtanner ryansb thaumos 19:03:26 * gundalow waves 19:03:39 #chair gundalow 19:03:39 Current chairs: abadger1999 abraverm alikins dag ghusson gundalow itdependsnetwork jtanner ryansb thaumos 19:03:55 off topic gripe, but I am having a hard time getting my stuff together with all of the issues opened. 19:04:02 * thaumos wishes for a better process. 19:04:34 thaumos: Before the meeting I used to go through and give hearts to the thing I thought were relevant to go through in the meeting. 19:04:45 okay, that's not a bad idea. 19:04:47 hi 19:04:48 Helps you skip over things you know haven't progressed/waiting on maintianers feedback 19:04:50 #chair shertel 19:04:50 Current chairs: abadger1999 abraverm alikins dag ghusson gundalow itdependsnetwork jtanner ryansb shertel thaumos 19:05:31 @gundalow do you have any clue what's going on with all the issues opened right now? Are some needing to be covered today, or should I just jump right into the comments? 19:05:49 * gundalow looks 19:06:16 thaumos: if in doubt start at the end and work back 19:06:20 thx, because I don't know where what we need to follow up on from Fest. 19:06:56 #topic ansible/ansible#20717 19:07:07 #link https://github.com/ansible/ansible/pull/20717 19:07:14 itdependsnetwork, what's the scoop? 19:07:27 Was hoping you could tell me 19:07:31 lol 19:07:36 I don't know of a reason why it can't go in 19:07:55 ah, this one 19:08:02 so it sums up to this. 19:08:05 I have been told that there has not been consensus 19:08:24 We need to make a decision on going forward what the convention is going to be. 19:08:32 That's sort of on me to be perfectly honest. 19:08:42 SO I take full full blame for it. 19:08:54 #action thaumos to get closer, by thursday's meeting on this topic. 19:09:01 ok, so any chance before 2.4? 19:09:13 I guess it depends. 19:09:24 Let's cover that on Thursday as well.. 19:09:27 Sound good? 19:09:41 I guess that is my last time before cut off, right? 19:11:09 it depends. 19:11:23 We'll have it all covered on Thursday, promise. 19:11:27 lol, ok good to go 19:11:30 cool 19:12:07 #topic ansible/ansible#25865 19:12:09 Hmm, there is a freeze ? 19:12:35 Yes, freeze for core is August 15, modules August 29 19:13:05 how is this being communicated ? I missed that 19:13:07 I thought this week or something? 19:13:16 we just talked about it today dag 19:13:22 thaumos: ah ok 19:13:37 so we were going to communicate today at end of meeting and send out other project list stuff, etc. 19:13:38 dag: Once your ROADMAP updates go in we will add the details to the top of that page then email it out 19:13:39 anyways 19:13:41 topic 19:13:46 #link https://github.com/ansible/ansible/pull/25865 19:14:03 uh....it's being communicated right now 19:14:14 ryansb: :) 19:14:40 queue spaceballs scene 19:15:03 now now? 19:15:36 #action thaumos to speak offline with the manageiq folks to figure out the intent of the PR. 19:15:49 jtanner: riiiiiiiiight NOW 19:17:20 #topic ansible/ansible#26335 19:17:33 #link https://github.com/ansible/ansible/pull/26335 19:17:39 willthames wanted feedback on ^ 19:17:44 * ghusson gives spaceball extract link for younger people... https://www.youtube.com/watch?v=qzO4BSTnkgg 19:18:35 I read it as: "all module updates and submissions must be completed by 2017-Jul-15 for high probabilities of inclusion (subject to review)." 19:19:35 @itdependsnetwork, can you ping me offline on that. I am updating roadmap docs, and will work with others to get the rest updated. 19:19:44 ghusson++ 19:20:10 @bcoca you lurking around? 19:20:35 sorry, I'm good, just relaying what I had read :) 19:20:53 bcoca, resmo, jimi|ansible: Review of https://github.com/ansible/ansible/pull/26335 19:21:12 thx @abadger1999 19:22:03 I don't see anything wrong with it but that's part of the code I don't know so I can't speak to the logic changes. 19:23:05 * thaumos nods 19:23:51 #action someone to poke the bcoca bear... possibly via GH comments. 19:24:45 #topic ansible/ansible#22567 19:25:28 that's me 19:25:34 :smile 19:25:52 #link https://github.com/ansible/ansible/pull/22567 19:25:53 so this PR includes two fixes to imrove the YAML inventory format 19:26:10 one is to ensure hosts: can be a list of hosts (rather than a dictionary) 19:26:55 second is to ensure that if a dictionary of hosts is provided (with no vars), it still works (as normally that translated to null) 19:28:12 we stumbled on this because we generated static YAML inventories, and it broke ansible on these two occasions 19:30:09 so this is something to need bcoca here to discuss code in depth as well. however, I see the case for both usage patterns. I am curious though what users will tend more towards. 19:31:44 i have no notion of how popular yaml inventory is. I use either ini or dynamic. It seems like it keeps things flexible for yaml inventory users though 19:31:56 seems ok to me. if that yaml format worked with the old code, then I dont see any reason not to 19:32:39 @jhawkesworth_ it's new 19:32:52 it's not related to recent changes, it failed as well before bcoca's recent inventory changes 19:33:00 dag: Line 140-146; is that section part of sanitizing for an internal representation? 19:33:08 thaumos: in fact, it is not, originally in 2012 YAML was the default inventory format 19:33:14 * jhawkesworth_ feels better for not using it then 19:33:29 then we switched to ini 19:33:31 but somewhere in 0.8 it was ditched for INI-only (and JSON interface) 19:33:34 yep 19:33:36 I remember 19:33:41 0.2 user 19:33:45 ah :-) 19:34:44 abadger1999: that part is required to support a list of hosts, without that part you need to provide a dictionary with hostnames as keys and null-values 19:34:51 (well, nothing as value) 19:35:03 to support null-values, the other changes are required 19:37:48 yeha, I see that internally, it's not using the datastructure that's passed in for permanent storage... So no problems... looks good to me. 19:39:44 +1 from me for this. If ini supports it then it would be good for yaml to support it as well. 19:40:21 I guess we need final signoff from bcoca but it makes sense to do. 19:43:00 #action have bcoca look at PR and make final signoff. 19:44:57 any other topics? 19:45:19 mine ? :-) 19:45:51 @ghusson, I still haven't gotten any feedback from management. 19:46:14 ok 19:46:16 from a user and product stand point, we don't see what you are seeing. 19:46:22 once I hear anything I will dm you directly. 19:46:35 on what? 19:46:43 Maybe we can discuss this old one: https://github.com/ansible/ansible/pull/23062 ? 19:46:57 Ok, for information, I posted a link to the code in the meeting issue 19:47:09 yep, I see it :-) thanks for that! 19:48:17 dag: why is that happening? 19:48:17 #topic ansible/ansible#23062 19:48:18 thaumos: you're welcome. Just let your people contact me when you would like to talk about ? my mail : g.husson_ansible@liberasys.com 19:48:52 shell/command are really only subproces.Popen(shell=True|False) 19:48:55 #link https://github.com/ansible/ansible/pull/23062 19:49:12 i don't see why that affects the "executable" parameter or makes it relevant to only shell module 19:49:44 discussed in a different meeting i suppose 19:49:45 oh well 19:50:38 jtanner: I can't remember, maybe nitzmahone still remembers 19:50:40 Code is fine but yeah, I don't know the context for this change. 19:50:52 Looks like bcoca and nitzmahone were involved i nthe discussion? 19:51:15 i've never had to use the parameter, so i'm not personally invested 19:51:16 this was part of getting command and win_command using the same parameters 19:51:45 and nitzmahone told me that he preferred removing executable= from command, rather than adding it to win_command 19:51:54 and that this was discussed and agreed upon before 19:51:58 Oh, executable makes no sense in command, since you're specifying the command line and Popen'ing (well, I don't know what that does in popen, but should just be "execute this process with this cmdline) 19:52:01 I'll ask nitzmahone in the Windows-meeting 19:53:09 Only reason it's in command is because shell/command share an impl 19:53:22 (said everyone I talked to, jimi, bcoca, others) 19:53:45 The executable argument specifies a replacement program to execute. It is very seldom needed. When shell=False, executable replaces the program to execute specified by args. However, the original args is still passed to the program. Most programs treat the program specified by args as the command name, which can then be different from the program actually executed. On Unix, the args name becomes the display 19:53:45 name for the executable in utilities such as ps. If shell=True, on Unix the executable argument specifies a replacement shell for the default /bin/sh. 19:55:37 jtanner: so do you want to support this then ? 19:55:49 i dunno ... wondering why it was added in the first place 19:55:51 showing a different name in ps from what is really ran, I guess 19:56:35 was it added on purpose, or an oversight of the person copying the docs between command and shell ? 19:56:39 I think it's safe to say we aren't coming to a conclusion on this one today folks. Can we bring this up again on Thursday? Maybe bcoca will be around to chime in as well. 19:56:49 ok 19:56:50 okay, with nitzmahone's explanation... seems good to me. 19:57:14 i mean ... just get rid of it, and pretend nobody uses it until they complain 19:57:20 Maybe would change the warning message a bit but otherwise I'm +1 to merge it. 19:57:30 what a change since last week ;-) 19:57:51 abadger1999: sure, let me know what you prefer 19:58:14 okay, are we merging, or should we do a quick follow up on Thurs? 19:58:57 is that for supporting tools that change behavior based on sys.argv[0] ? 19:59:03 dag: added comment to the PR. let me know and I'll merge afterwards. 19:59:18 thaumos: I'll merge... bcoca can yell at me if he disagrees. 19:59:25 lol ok! 19:59:29 cool. 19:59:34 thanks everyone for the great meeting today! 19:59:37 #endmeeting