19:11:01 <ryansb> #startmeeting Ansible Core IRC
19:11:01 <zodbot> Meeting started Tue Aug 23 19:11:01 2016 UTC.  The chair is ryansb. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:11:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:11:01 <zodbot> The meeting name has been set to 'ansible_core_irc'
19:11:09 <abadger1999> jimi|ansible, gundalow, shertel, bcoca, nitzmahone, mattclay, Qalthos, jtanner|t420: meeting ping
19:11:13 <abadger1999> Thanks ryansb!
19:11:14 <jtanner|t420> hello ... will be back n forth
19:11:16 <shertel> Hi!
19:11:24 <nitzmahone> Yo
19:11:31 <MichaelBaydoun> present
19:11:32 * jimi|ansible here now
19:11:43 <jimi|ansible> also working on stuff in the background
19:12:18 <Qalthos> hiya
19:12:38 * abadger1999 multitasking
19:13:19 <ryansb> huh, what happened to the `agenda` issue
19:13:30 <ryansb> #chair Qalthos nitzmahone
19:13:30 <zodbot> Current chairs: Qalthos nitzmahone ryansb
19:13:42 <ryansb> #chair jimi|ansible shertel
19:13:42 <zodbot> Current chairs: Qalthos jimi|ansible nitzmahone ryansb shertel
19:14:34 <linuxdynasty> hello
19:15:04 <ryansb> First order of business, RC for 2.1.2 is out for testing
19:15:19 <ryansb> #link https://groups.google.com/forum/#!topic/ansible-devel/CGwPAmGnGA0 for 2.1.2 notes & instructions
19:16:14 <ryansb> Anybody have items for the agenda today?
19:16:18 <abadger1999> Thank you jimi|ansible for getting it out, thank you everyone who contributed bugfixes!
19:17:00 <abadger1999> Informational: We decided how to implement metadata earlier today.  Details are in this ticket comment: https://github.com/ansible/proposals/issues/30#issuecomment-241805430
19:18:00 <ryansb> #link Module metadata decision, including renaming "stable" to "stableinterface" https://github.com/ansible/proposals/issues/30#issuecomment-241805430
19:18:20 <ryansb> If nobody has other items, this is about to be a super-short meeting, as I just have one other thing
19:18:56 <ryansb> The feature freeze for the core repo (ansible/ansible) is going to be September 4th
19:19:25 <ryansb> which means if you're adding stuff there, please get it reviewed and merged by then (basically in 2 weeks)
19:19:35 <ryansb> because after that we'll just be doing bug fixes and the like
19:21:22 <linuxdynasty> i have 1 PR that I added today in the ansible repo if someone would like to review it https://github.com/ansible/ansible/pull/17195
19:21:28 <linuxdynasty> It is failing but not because of the PR
19:24:53 <linuxdynasty> This PR as well https://github.com/ansible/ansible/pull/17039, which is waiting for the core team to make a decision
19:25:18 <linuxdynasty> Both PRs include tests
19:25:21 <abadger1999> jimi|ansible: Does https://github.com/ansible/ansible/pull/17195 look good to you?  You know more about vars than the rest of us.
19:26:36 <abadger1999> bcoca is really busy with the roles revamp feature... So for cloudretry I'm thinking we should consider it a module-level change so that it can go in after the September 4th deadline.
19:27:25 <linuxdynasty> kk :( This is holding back other PR's I am going to make for the AWS modules to include it. But I do understand.
19:27:29 <jimi|ansible> not sure if that's really necessary, as the same can be done with include_vars and with_fileglob i think
19:27:30 <ryansb> cloudretry is on my review list
19:27:46 <abadger1999> I think what bcoca wanted was for cloudretry to be implemented in terms of the existing retry functionality in api.py... so either calling it or subclassing or soemthing.
19:27:46 <ryansb> linuxdynasty: ^
19:27:51 <linuxdynasty> jimi|ansible: the include_vars_dir allows to include a direcotry and nested directorie
19:27:53 <abadger1999> ryansb: Cool.
19:28:01 <caphrim007> abadger1999: could you point me to any docs/prs about said revamp so I can update my understanding?
19:28:14 <linuxdynasty> and files to ignore as well as to search. fileglob allows for a subset
19:28:18 <abadger1999> caphrim007: Roadmap... let me get you the link to that.
19:28:22 <caphrim007> thanks
19:28:48 <linuxdynasty> This will help users who have a complex nested vars dir that depend on how they load
19:29:08 <caphrim007> abadger1999: found it
19:29:10 <linuxdynasty> and control the depth
19:29:34 <abadger1999> roles revamp: roadmap entry: https://github.com/ansible/ansible/blob/devel/docsite/rst/roadmap/ROADMAP_2_2.rst   and that links to moredetails at: https://github.com/ansible/proposals/blob/master/roles_revamp.md
19:30:13 <ryansb> #link bcoca's role revamp https://github.com/ansible/proposals/blob/master/roles_revamp.md is in progress for 2.2
19:30:24 <caphrim007> thanks all for the links
19:32:40 <linuxdynasty> Also will load in alphabetical order. I agree it has a subset of the functionality, but it does do a bit more.
19:33:13 <bcoca> easy to emulate with lookups + filters + loops
19:34:20 <ryansb> bcoca: there's something to be said for not having to assemble a filter/lookup chain to do it though
19:34:35 <linuxdynasty> This also make it easier on the user. The user does not need to be intermediate ansible user in order to use this module
19:34:46 <ryansb> ^that
19:35:19 <bcoca> i fear having modules that just do 'a bit more' than other modules, need to maintain 2 codebases that do almost same thing
19:35:46 <bcoca> now we add feature B to include_vars, people will complain the other module does not have it
19:36:23 <linuxdynasty> well it does contain test ;) if that counts for anything :P
19:37:49 <linuxdynasty> I personally feel there is 2 distinct use cases here. One is meant for loading a file, that can load x amount of files by applying loops and filters
19:38:04 <linuxdynasty> the other includes a dir of vars that does not need a loop or filters
19:38:37 <linuxdynasty> With this power, power users can organize there vars in such a way to leverage this module
19:39:10 <bcoca> they still can and we can easily show them how to do it with good examples
19:39:31 <linuxdynasty> well that is enough of me defending this PR lol. you guys are the boss and I know you guys know better than me on this subject.
19:39:34 <bcoca> when you can do something with 3 tools that each do 1 part well, vs creating a big tool that does 1 path of the 3 well, i prefere the 3 tools
19:40:33 <linuxdynasty> 1 tool is working with a directory and the other is working with a file.
19:40:49 <bcoca> directories are files that contain other files
19:40:56 <linuxdynasty> not the same exact tool, just similar functionality
19:41:08 <bcoca> and no, one uses a directory to get list of files to include, the other just takes a file to include
19:41:30 <linuxdynasty> understood, let me know and I will close the PR.
19:44:01 <bcoca> now, if you want to add directory detection and handling to include_vars, diff issue
19:44:55 <bcoca> still think current way works well enough
19:47:55 <jimi|ansible> bcoca: that was my thought too, extending include_vars to handle irs
19:47:56 <jimi|ansible> dirs
19:48:52 <caseylucas> I submitted https://github.com/ansible/ansible-modules-core/pull/4432 a few days ago. Is this the correct forum to ask for async_wrapper advice/recommendations?
19:52:55 <ryansb> caseylucas: yeah
19:54:22 <ryansb> I've not worked on it, but it looks like bcoca and jimi|ansible have
19:54:46 <caseylucas> ryansb: thx. my main question is: can async wrapper rely on only two transient files (module and possible arguments) being pushed to remote? The mentioned PR assumes this.
19:55:12 <bcoca> sleeps are there cause solaris is a problem child ....
19:55:16 <bcoca> ^ among others
19:55:30 <caseylucas> right, but i implemented the IPC to handle those cases
19:55:46 <bcoca> not all posix forks are the same, some 'return ok' before actual fork happens, just get OK, OS knows how to fork this, go back
19:56:16 <bcoca> ah, only read title
19:56:23 <linuxdynasty> So from reviewing the  code in include_vars, all I will need to do is  to accept a param called file and accept raw params
19:56:35 <bcoca> if you actually setup IPC .. that requires some review, but probably can get rid of sleeps
19:56:42 <caseylucas> i did find an existing os.waitpid issue on freebsd btw.
19:56:51 <bcoca> linuxdynasty: look in 2.2, already have file= param
19:56:55 <caseylucas> shippable server found it
19:56:59 <linuxdynasty> the question  I have is is the team ok with all the features I added to include_vars_dir and can I add them to include_vars?
19:57:18 <jimi|ansible> linuxdynasty: yeah i think it's fine, i'd just merge the functionality
19:57:25 <linuxdynasty> that is what I am looking at and thats what I meant
19:57:35 <jimi|ansible> +1
19:57:37 <linuxdynasty> ok I will close the current PR and merge the functionality
19:57:48 <bcoca> im on fence, but it at least voids the code/path duplication
19:58:15 <ryansb> +1
19:58:38 <linuxdynasty> kk
19:59:21 <linuxdynasty> thank you guys for the feedback, and i do feel bad about the pestering of the retry decorator. Just trying to help you guys make the AWS provisioning a 1st class citizen in Ansible :)
19:59:53 <bcoca> dont feel bad, sorry i've been bogged down
20:00:23 <bcoca> but basically what abadger1999 said above was my intent, to remove redundancy and allow extending these functions to multiple uses
20:01:08 <caseylucas> linuxdynasty: I can second that. we (at work) are doing a lot of aws provisioning with ansible.
20:01:30 <linuxdynasty> I've a;ready applied that decorator to most of the AWS modules I use locally
20:01:55 <bcoca> need to so same for paging, already added it to a couple of modules
20:02:06 <linuxdynasty> but can not create a PR, until merged. bcoca if I can be of any assistance, just let me know
20:02:11 <linuxdynasty> refactoring it if needed
20:02:40 <bcoca> i need time and/or clone
20:03:47 <linuxdynasty> hehe, I meant from my time ;). But I would need your time to guide me on how you would like it refactored, which means you have no time, which means I just confused the hel out of myself
20:03:49 <linuxdynasty> :p
20:04:40 <ryansb> Righto - we're a few mins over
20:04:56 <ryansb> so I'm going to close this down in 60 seconds if nobody has more
20:14:33 <ryansb> #endmeeting