15:00:48 #startmeeting Core Team Meeting 15:00:48 Meeting started Thu Jan 12 15:00:48 2017 UTC. The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:48 The meeting name has been set to 'core_team_meeting' 15:01:08 hello! 15:01:19 #chair abadger1999 alikins jimi_|ansible bcoca jtanner masteinhauser mordred newtMcKerr Qalthos ryansb ryansb 15:01:19 Current chairs: Qalthos abadger1999 alikins bcoca gundalow jimi_|ansible jtanner masteinhauser mordred newtMcKerr ryansb 15:01:38 o/ 15:01:57 Agenda https://github.com/ansible/community/issues/148 15:02:06 * mattclay waves 15:02:48 #topic IRCBot https://github.com/ansible/proposals/issues/48 15:02:51 Bikeshed time! 15:03:01 allanice001: Not sure if you are around 15:03:13 DocBot 15:03:20 i thought that was a state of mind ... does that mean we have to stop bikeshedding the rest of the time? 15:03:20 Searchy 15:03:27 * bcoca goes back to yakshaving 15:03:36 nagmenot 15:03:47 bcoca: always bikeshedding, just need bikeshed++ now 15:05:07 https://public.etherpad-mozilla.org/p/ansible-botname 15:05:13 Please add ideas and votes 15:06:12 yup 15:06:26 Was just a few minutes late 15:06:35 lmgtfybot 15:06:51 "was that so hard?" 15:07:01 whattodobeforeasking 15:07:13 yeahitsdocumented 15:07:24 tiredofansweringthis 15:07:28 learnhow2computer 15:07:31 * gundalow mutters, what have I done 15:07:36 googleitMF 15:07:36 FOCUS PEOPLE 15:07:49 * bcoca stops now 15:07:54 You know the definition of focus, right? 15:08:14 we were focused! ... on the wrong thing .... 15:08:39 so, what are we talking about? 15:08:57 jtanner: a name for the IRC bot https://public.etherpad-mozilla.org/p/ansible-botname 15:09:11 Well, we could call the bot Focus :P (feck off cuz u're stupid) 15:09:17 oops 15:09:22 ^^ lol 15:09:25 Wow, private got banned here? 15:09:33 my bad 15:09:48 i acidentally pasted wrong and did "flags privateip +ryansb" 15:09:50 clearly jimi_|ansible thinks privateip should do more time coding, less time talking 15:09:59 looooooooooooooooool 15:10:13 jimi_|ansible: confess ... you just saw network_config and retaliated! 15:10:35 how about "moobot" 15:10:57 I see 'foart' on etherpad, can I +1 that? :D 15:11:26 shaps: +1 -1 as you wish 15:11:35 Ask the Cow is cool 15:12:02 mcdonalds wifi is slooooow 15:12:12 Also, when do you want the bot in #ansible ? 15:12:16 jtanner: That's a crap name for a bot 15:12:17 we should spin up a lambdamoo server and use that instead of IRC 15:12:35 gundalow: poobot? 15:12:42 jssjr: ++ 15:12:45 gah 15:12:47 jtanner: ++ 15:12:52 OK, VOTING CLOSED 15:12:58 I think "bot" should be in the name regardless 15:13:06 or rather we have better things to do 15:13:25 Pleas add your thoughts and comments and we will revisit next week 15:13:50 Once the name is sorted are people happy to add it to #ansible? 15:13:50 +1 15:14:06 i think it can go in there now 15:14:11 the name isn't necessary to use it 15:14:27 That's a good point 15:15:04 +! 15:15:07 +1 15:15:32 Anyone else? 15:15:44 allanice001: Anything stopping us putting it live now? 15:15:50 nope 15:15:54 yeah, would love to have it in 15:16:16 #action allanice001 To put the bot live on #ansible 15:16:19 any name with "bot" in it works for me 15:16:33 #action Core team to pick a name that contains "bot", can rename later 15:16:35 Thanks 15:16:42 Anything else on Bot? 15:16:47 not from me 15:17:07 #topic SmartOS Timezone module: ansible/ansible#20105 15:17:16 #link https://github.com/ansible/ansible/pull/20105 15:17:19 abadger1999: ^ 15:17:30 Do we want this as a separate module or merged with the existing timezone module? 15:18:22 im 50/50 here ... when we combine very disimilar systems into one module we get a mess *cough*service*cough* ... but we do have both patterns 15:18:55 i would hope timezone would not be the case ... but ... timezones are one of those things humans made incredebly complex but always fail to realize and think its trivially simple 15:19:09 So what are the concerns, usability, confusion about which module to use? 15:19:32 code duplication/maintenance? 15:20:46 * gundalow is a solid + zero on this 15:21:06 Well, actually from an end user point of view a single module is easier 15:21:27 but a pita to maintain 15:21:58 Depending on how many options are specific to one use of the module, it may not even be easier to use. 15:23:25 if detecting a system is SmartOS is easy/reliable, then I would say add it to existing timezone 15:24:55 alikins: detection is something we already do for service/facts/user/group/etc 15:25:15 its the easy part, but the module itself can get very complicated ^ any of the above as example 15:25:47 we've decided to break up service and facts, but not user/group so it also depends on fragmentation of the problem 15:31:54 How do we move this forward then? 15:32:40 Is one option "better" (no idea how you measure than) initially, and swap to separate/merged modules later 15:32:40 ^ only count shipits AFTER last commit 15:32:50 bcoca: Wrong discussion :P 15:33:03 sorry .. 5 conversations .. .starting to meld 15:33:03 Slacks over ---> here 15:33:40 for timezone .... im +0, need a compeling argument to decide, right now i can see it both ways and they both suck 15:33:51 OK 15:34:01 #info We don't know what to suggest 15:34:33 #topic Open Floor 15:34:40 Looks like that's the end of the Agenda 15:34:45 What else does anyone have 15:35:08 Otherwise do we look at Proposals, or shall we close now and go back to Slack discussions? 15:35:45 Ola 15:35:45 #topic Configurable fact path 15:35:50 #link https://github.com/ansible/ansible/pull/18147 15:38:28 bcoca: I added that to the agenda before you commented on it. Seems like you're OK with the change? 15:39:38 mattclay: yeah, just saw that we need to standarize how we do this in general, my comment is not about this particular PR 15:42:49 bcoca: When you do, could you add the information to the developing ansible variables google doc? 15:42:59 https://docs.google.com/document/d/1vb9-OPXTLeySlPF40gXI3pRDkJzBPbJAJTYwcSAe7yI/edit 15:44:00 abadger1999: once 'we' do 15:44:12 wait ... google doc? not the rst? 15:44:39 bcoca: we do not yet have an rst. and the doc has enough false/missing information that it's not ready to convert yet. 15:45:02 I'll make an rst once I know the doc has good information. 15:45:11 i would work on the rst and just not link it, would allow contributors to update 15:45:35 with WIP clearly on top 15:46:14 bcoca: I can convert.... I was going by the proposed docs workflow but it seems we haven't had any input from there so... 15:46:56 that was my thought, google doc will go stale unless we (rh employees) have time, in repo the 'we' is a larger group 15:46:56 bcoca: The configurable fact path changes look good and the tests pass. Is it ready to be merged? 15:47:59 mattclay: need to ammend docs to make sure people realize this is ONLY for the implicit setup 15:48:06 but that can be done post 15:50:19 #chair mattclay 15:50:19 Current chairs: Qalthos abadger1999 alikins bcoca gundalow jimi_|ansible jtanner masteinhauser mattclay mordred newtMcKerr ryansb 15:50:25 hi 15:50:58 #info https://github.com/ansible/ansible/pull/18147 (configurable facts_path ) ready to merge 15:51:17 merged already, fixing docs 15:51:23 #action need to amend docs to make sure people realize configurable facts_path is ONLY for the implicit setup (per bcoca) 15:51:43 bcoca: cool. 15:52:03 mattclay with action, one thing I like to do is always have a person tasked with the action. 15:52:16 (it's just convention but it's helpful) 15:52:30 abadger1999: Yeah, good point. Thanks. 15:52:51 bcoca: do you want an action for changing where the fact-related variables are set as well? 15:53:23 abadger1999: just add for next meeting, low priority 15:53:32 bcoca: k 15:54:06 #topic shipit workflow for non-modules 15:54:11 #link https://github.com/ansible/community/issues/148#issuecomment-270251944 15:54:19 gundalow: re: other topics.. some of the old items on the agenda are unresolved. 15:55:12 mattclay: +1 to all three... I think some will lean heavily on "core team" for a bit but we need to start somewhere. 15:55:52 Yeah, I'm +1 as well. I discussed with jtanner earlier and he just wanted to get consensus on it before making the changes. 15:56:00 module utils gives me pause, plugins would need to use metadata 15:56:04 ^ we really should 15:56:15 dyn inventory would be my first target tbh 15:56:40 meta can go in FILEMAP.json 15:56:40 contrib is clear, but once we start inventory plugins, we should also use metadata 15:56:59 +1 to plugin metadata 15:57:22 ^ need to make list and which ones are core ... i would say any with external deps == community 15:57:30 mongodb/dig/etc 15:57:50 dyn inventory is almost exclusively external to core. 15:57:55 filters/tests are harder as they use common file .. we might need to split those 15:58:26 abadger1999: true but considering the importance of some, we might want to keep at least as curated *cough*ec2.py*cough* 15:58:30 We should alert the tower team to that, though... they might want to make sure someone from the tower team is responsible for changes to some of them 15:59:00 bcoca: 15:59:28 ^ counting that as JINKX 15:59:56 they should be marked as maintainers if they're going to gate them 15:59:58 probably ec2/openstack ... might want to give gce and others to the respective 'cloud maintainers' 16:00:33 jtanner: 2 decisions, a) support core/curated/community ... b) maintainers list 16:00:47 i would not put any in core, but probably 2 or 3 in curated 16:00:53 rest are community 16:01:15 Unfortunately I need to duck, but bot is in #ansible 16:01:36 allanice001: Nice! 16:01:36 gundalow is registering answerbot nick which will be used 16:01:38 azure/ec2/vmware*/openstack <= curated .. openshift? 16:01:49 docker? 16:02:03 rest im fine with community 16:02:08 gundalow, I should be online in just over an hour 16:02:18 only curated if they work well now and we have an expectation that someone is available to maintain them 16:02:29 vmware is community, imo 16:02:46 allanice001: ACK 16:03:19 Catch y'all later 16:05:51 Okay, anything else for this topic? 16:05:59 I guess action items? 16:06:27 Do we want to start with just dyn inventory and then expand once we have that working? 16:07:36 #action abadger1999 will ping tower team about expanding external maintainership to dyn inventory; invite them to add maintainers for inventory scripts they care about. 16:09:49 #action abadger1999 to update script to add metadata to the inventory scripts 16:11:32 #action team to put together a list of metadata suggestions for dyn inventory and will approve it next week. 16:11:57 https://docs.google.com/spreadsheets/d/1z-BfOkAaY60nYir6qx6L9yHMqcwT31UtrgaAFKnjH9w/edit#gid=0 16:11:57 jtanner, mattclay: anything else you want to have get done this week? 16:12:23 No, that's it for me. 16:12:24 not sure i understand 16:12:47 bcoca: I may modify the spreadsheet columns a litttle -- I already have a csv format in the metadata-tool script. 16:13:05 i probably won't even start on this till next week 16:13:25 shipits on modules is still a WIP 16:14:24 jtanner: Cool. I guess.. Anything else you'd need the rest of the team to finish up so that you aren't blocked when you do start? 16:14:48 nope 16:14:54 excellent 16:15:28 abadger1999: i think current is good for voting, we can add column and hide 'voting' when ready to script 16:15:33 bcoca: Remember to share that spreadsheet :-) 16:15:35 column with 'results' 16:15:45 abadger1999: my whole drive is shared by default 16:16:18 bcoca: huh.... I get request permission from all of my accounts (looking at it from red hat account now) 16:17:33 try now 16:17:37 rh account should work 16:18:16 seems my change to the drive was reverted by 'admin policy' 16:18:27 works :-) 16:18:41 #link https://docs.google.com/spreadsheets/d/1z-BfOkAaY60nYir6qx6L9yHMqcwT31UtrgaAFKnjH9w/edit#gid=0 16:18:51 #topic "Ansible 2.0 no longer finds modules in library subdirectories" https://github.com/ansible/ansible/issues/15432 16:19:02 i'll make one per plugin type 16:19:05 https://github.com/ansible/community/issues/148#issuecomment-270201815 16:19:11 though most of other plugins will be 'core' 16:19:21 Last week we talked about this and came up with three proposals. 16:19:28 Need to make a decision on it. 16:19:47 -1 still on my side, i thnk it is extra complexity for a very niched need that 99.9999% of users dont care about 16:20:20 bcoca: Which is a vote for #3 (Do not add subdirectory support but document multiple ANSIBLE_LIBRARY_PATH paths[...]), correct? 16:20:44 yes, .. but those are already documented? 16:21:03 I'm easily swayed on this but I'm also a #3 right now. 16:21:31 bcoca: I'll check... might be just a matter of adding this use case to teh documentation on ANSIBLE_LIBRARY_PATH 16:21:58 + we should add some tests for it. It's something that none of us would nessarly have setup in our usual case 16:21:58 i would argue .. you need to add it to all ANSIBLE_*_PATH 16:22:08 ^ also to corresponding ansible.cfg entry 16:22:09 ansible-test makes it easier to test these type of things 16:22:54 ANSIBLE_LIBRARY is only documented in the dev_guide right now... We need to change that. 16:23:32 intro_config should have the ansible.cfg path settings 16:23:33 Maybe add environment variable mentions to the relevant config file entries? 16:23:40 and then ^U 16:23:42 jinx 16:23:43 which i think are more appropos for the use case that started this 16:24:54 #action abadger1999 to add mention of environment variables to intro_config 16:25:32 Anyone else want to weigh in here? 16:26:04 Even with don't care? (otherwise it feels like two people are making the decision for everyone). 16:27:15 did you end up with multiple paths in ANSIBLE_LIBRARY? 16:27:22 That sounded clean to me 16:27:45 silence == tacit approval 16:27:56 ^ last chance to weigh in 16:28:09 :) 16:28:19 gundalow: yeah, that's the proposed solution here, document the existing facility of multiple paths in ANSIBLE_LIBRARY as the way to do this. 16:28:21 ^ smiling emoticons count as +1 16:28:30 +1 16:28:40 rather than adding a new feature to the code. 16:28:44 aye, defo 16:28:57 The ayes have it :-) 16:29:07 \o/ 16:29:16 #action abadger1999 will take care of documenting the use case in intro_config. 16:29:52 abadger1999: Once you've documented it add me on the review and I'll add some tests in for it 16:30:58 * gundalow -> afk 16:32:02 will do thanks! 16:32:15 #action gundalow to make tests for the use case 16:33:28 #topic Open Floor 16:33:35 Anything else from people? 16:35:30 jtyr: If you're around I think you had a PR you wanted to at least get on the agenda for next time? 16:36:02 jtyr: If you're not around, we'll get the info from you between meetings and put it on the agenda. 16:36:19 Okay, I'll close in 60s 16:38:24 #endmeeting