15:09:27 <abadger1999> #startmeeting Public Core Meeting
15:09:27 <zodbot> Meeting started Thu Sep  1 15:09:27 2016 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:09:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:09:27 <zodbot> The meeting name has been set to 'public_core_meeting'
15:09:50 <abadger1999> 3topic Roll call
15:09:53 <nitzmahone> Yo
15:09:57 <abadger1999> #topic Roll call
15:10:10 <abadger1999> #chair Trozz linuxdynasty caseylucas shertel nitzmahone
15:10:10 <zodbot> Current chairs: Trozz abadger1999 caseylucas linuxdynasty nitzmahone shertel
15:10:53 <Trozz> I wanted to talk about the current issue open on ansible#16612 (link: https://github.com/ansible/ansible/issues/16612)
15:11:06 <abadger1999> Agenda is here: https://github.com/ansible/community/issues/121
15:11:51 <abadger1999> #topic Figure out how to represent missing python libraries in facts https://github.com/ansible/ansible/issues/16612
15:12:07 <Trozz> Currently when displaying the fact information, if a module is missing e.g. libselinux-python instead of an error we return simply 'False'
15:12:26 <Trozz> this has lead to this ticket being created due to confusion
15:13:30 <Trozz> I think displaying an error there (e.g. missing-module) would be better than false as it informs the user that something is missing and cannot be checked
15:13:52 * jimi|ansible lurks
15:14:04 <abadger1999> #chair jimi|ansible
15:14:04 <zodbot> Current chairs: Trozz abadger1999 caseylucas jimi|ansible linuxdynasty nitzmahone shertel
15:14:11 <sivel> yo
15:14:14 <Trozz> How does everyone else believe this should be?
15:14:21 * docschick is here for a little while, too
15:14:21 <Trozz> hey sivel jimi|ansible
15:14:36 <abadger1999> Trozz: I agree but I'm not sure the best way to represent it either.
15:14:42 <abadger1999> None?
15:15:00 <abadger1999> We want to avoid breaking people who have checks in their playbook like:
15:15:21 <abadger1999> when: ansible_selinux
15:15:49 <abadger1999> #chair docschick
15:15:49 <zodbot> Current chairs: Trozz abadger1999 caseylucas docschick jimi|ansible linuxdynasty nitzmahone shertel
15:15:50 <Trozz> yeah as I could imagine some people have used, when: ansible_selinux = False
15:16:17 <abadger1999> Trozz: yeah, a comparison to False will break if we change it at all.
15:16:19 <sivel> don't provide the ansible_selinux fact at all?  that would at least cause the playbook to die where it is
15:17:02 <Trozz> I don't think we have ever stipped a fact even if it doesn't exist. which is why I think the current default was False
15:17:10 <abadger1999> <nod>  We could do that -- the drawback would be it's a little hard to discover then
15:17:48 <abadger1999> ansible -m setup localhost might no longer be as complete a picture of what's available, for instance.
15:17:49 <Trozz> I think either None OR explanation text would be better than nothing what so ever
15:18:31 <abadger1999> <nod>  Explanation text would be nice but it would also be "truthy" for the purposes of when: ansible_selinux
15:18:51 <sivel> coudl we create a special type, that could include a reason, but still blow up if used?
15:19:28 <sivel> sort of like our "omit" but you know that does something different, carries a reason, although that would be a lot more work
15:20:03 <sivel> note: those statements have not been thoroughly though out :)
15:20:33 <sivel> thought*
15:20:41 <sivel> having trouble typing this morning, fingers aren't warmed up yet
15:20:59 <Trozz> lol :-) I am torn between either None and explanation either one will cause a break for people that have currently written checks against ansible_selinux
15:21:05 <abadger1999> It travels over the wire as json so we'd have to have logic on the controller side that says if one of our values returned via json is Foo Basic Type with this marker, then print a warning contianed in the type and replace it with False/None/something else.
15:22:46 <sivel> my memory is likely failing, but I had believed it started as None, and then became True/False, but it could be what we do for supporting ssl context
15:23:27 <Trozz> also if the module is installed then the feedback for ansible_selinux is "ansible_selinux": { "status": "disabled" }
15:23:38 <abadger1999> {'_ansible_optional_facts_warning': 'selinux python library not found, unable to determine if this was set', 'set_to': None }
15:24:26 <Trozz> that sounds good
15:25:54 <abadger1999> Trozz: note that the fact itself would still be misleading.... but we can print the warning to stdout so that the user can see it.
15:26:03 <abadger1999> Does that work out fine?
15:26:24 <Trozz> yeah as long as we inform the user I do not see an issue
15:26:28 <abadger1999> k
15:27:11 <Trozz> everyone in agreement with that?
15:27:49 <abadger1999> Hmm... if it's just a warning... It might be better to leave ansible_facts alone and instead return a warning in a new toplevel key.
15:28:10 <abadger1999> that way we don't have to look through the entire return value.
15:28:18 <Trozz> if we go for the route of simply displaying a warning we can leave it as False so we don't mess with peoples current logic
15:28:25 <abadger1999> <nod>
15:28:36 <sivel> abadger1999: that sounds reasonable, and removes the need for a recursive function
15:28:56 <abadger1999> bcoca: Do we already have a warning key in return values or is that something we have to implement?
15:29:39 <abadger1999> Trozz: Okay, I think we have the outline of a plan even though we don't have precise implementation.
15:30:06 <abadger1999> #info End user will see a printed warning but facts will stay the same.
15:30:23 <bcoca> 'warnings'
15:30:30 <Trozz> sounds great, ill have a look at that when i get a chance
15:30:36 <bcoca> ^ its a list
15:31:20 <sivel> We need to make sure that gather_facts would also cause the warning to be displayed, I don't remember if it will, since we suppress the output there anyway
15:31:33 <abadger1999> #info Trozz will look at using the existing "warnings" return value (a list) to implement this.
15:32:03 <abadger1999> #info Need to look at gather_facts to make sure it won't supress the warning output
15:32:04 <Trozz> +1 I will also update the public ticket letting everyone involved on it
15:32:12 <abadger1999> Thanks Trozz!
15:32:32 * mattclay waves
15:32:42 * Trozz waves
15:32:42 <abadger1999> #topic speed up async module execution by removing some sleeps https://github.com/ansible/ansible-modules-core/pull/4432
15:32:49 <abadger1999> #chair bcoca mattclay
15:32:49 <zodbot> Current chairs: Trozz abadger1999 bcoca caseylucas docschick jimi|ansible linuxdynasty mattclay nitzmahone shertel
15:33:19 <abadger1999> dag_: If you're here, we haven't done unarchive yet, we can do that next.
15:33:43 <abadger1999> caseylucas: This one is your topic :-)
15:34:08 <caseylucas> i'd like some expert knowledge here.  modified code assumes there are two files that a sent to remote server. files are kept (via rename) before returning.
15:34:11 <abadger1999> mordred, Shrews, jeblair_: I know you guys took a look at this last week too.
15:34:21 <caseylucas> i just dont know if this is valid assumption
15:35:01 <mordred> I didn't do it
15:35:07 * mordred looks
15:36:04 <mordred> I like the PR in general, I have not yet tried it in anger
15:36:26 <nitzmahone> I actually had to do something different for that in Windows async- the watchdog had to delete the files (so the Windows wrapper opts out of deletion)
15:36:26 * gundalow waves
15:37:04 <nitzmahone> I actually only need it in the binary module case
15:37:13 <caseylucas> module file and possible arguments are copied before returning (and later removed), but if there are other files that are transferred that i dont know about it may break
15:37:29 <abadger1999> #chair gundalow mordred
15:37:29 <zodbot> Current chairs: Trozz abadger1999 bcoca caseylucas docschick gundalow jimi|ansible linuxdynasty mattclay mordred nitzmahone shertel
15:37:46 <gundalow> abadger1999: Thanks :)
15:37:49 <nitzmahone> Wondering if the same trick would work
15:38:42 <caseylucas> watchdog does removal of transferred module and possible arguments file with this PR
15:38:42 <abadger1999> caseylucas: I'd look at things like the copy module to see.  copy might have the source file as an extra.
15:39:30 <caseylucas> k. i can look at that
15:39:57 <nitzmahone> The way I did it for Windows gets the control side involved so we don't need to copy the temp
15:40:42 <nitzmahone> We'll need to reconcile regardless, or we'll have merge conflict or overlapping impls
15:41:03 <nitzmahone> Win async should be merged this week
15:41:39 <caseylucas> nitzmahone: can you send link to windows changes?
15:42:37 <abadger1999> If I'm looking at copy correctly, the copy action plugin (lib/ansible/plugins/action/copy.py ) cleans up the file that it copied over.  However, the copy module may have to create a temporary file if remote_src is specified.
15:43:00 <abadger1999> and then the copy module will clean that temp file up.
15:44:38 <nitzmahone> caseylucas: here's the updated action plugin: https://github.com/nitzmahone/ansible/blob/win_async/lib/ansible/plugins/action/async.py
15:44:46 <caseylucas> thx
15:45:01 <abadger1999> jimi|ansible: Do you know off the top of your head the answer to caseylucas's question?  "I'd like to make sure there are no transferred file cases I missed. Code currently assumes only two files (module source and possible arguments) are shipped to remote server." ?
15:46:31 <abadger1999> Alright... caseylucas I guess you have some things to look into now and we can take further discussion to #ansible-devel after the meeting?
15:46:53 <caseylucas> k. thx
15:47:21 <abadger1999> #info Windows async changes  https://github.com/nitzmahone/ansible/blob/win_async/lib/ansible/plugins/action/async.py
15:47:58 <abadger1999> #info copy module is good thing to look at to tell if more files are being transferred
15:48:18 <abadger1999> #info further discussion in #ansible-devel and next meeting if necessary
15:48:39 <abadger1999> #topic archive module parameters: https://github.com/ansible/ansible-modules-extras/pull/2323#issuecomment-237360607
15:48:57 <abadger1999> dag_: If you're here, we're onto the archive module
15:49:25 <abadger1999> bcoca: This was one you were interested in continuing to discuss at last meeting
15:50:43 <abadger1999> To summarize, we probably should have looked at the parameters for this module before merging.  Name-wise it looks like it corresponds with the unarchive module but parameterwise and functionalitywise it is different
15:51:10 <abadger1999> We also don't think the current parameters are sufficient for what users will want to do with it.
15:51:41 <abadger1999> So what do we want to do with this for 2.2?
15:52:55 <bcoca> https://github.com/ansible/ansible/pull/17351
15:53:28 <bcoca> ah, backlog just scrolled ....
15:53:36 <abadger1999> heh.
15:53:37 <bcoca> have not had time to look at archive/unardchive
15:53:55 <abadger1999> yeah, and I fear that will be the story for all of us until 2.2.
15:54:23 <Trozz> if we do not believe the module is where it should be and does not meet users needs we shouldn't look to ship it with 2.2
15:58:18 <abadger1999> Okay, so proposal, when 2.2 branches, revert from 2.2 tree.  If we get enough time to review changes to the parameters to the module and they get implemented, revert the revert and cherry-pick additional changes to fix the parameters.
15:59:10 <mattclay> abadger1999: +1
15:59:23 <bcoca> i need more coffee before i can parse that sentence
15:59:25 <bcoca> but +1
15:59:27 <abadger1999> If no one objects to this, I'll post it to the issue and also apologize that we don't have more time to devote to helping to define it right now (but inviting the maintainers to ping us on #ansible-devel if they want to try to get more eyes on it)
15:59:53 <Trozz> abadger1999 +1
16:00:22 <abadger1999> okee doke.
16:01:42 <abadger1999> #action abadger to apologize for lack of time and post idea to revert from 2.2 with the possibility of restoring it if proper parameters can be worked out in time.
16:01:46 <abadger1999> #topic open floor
16:01:54 <abadger1999> Okay, anything else that people have?
16:02:31 <Trozz> I think we might need some people with time to go through the open issues and close off what should be closed
16:02:48 <abadger1999> Trozz: yeah, that would be helpful.
16:02:53 <gundalow> Testing Working Group meeting is in one hour, hope to see lots of the community there <--- shameless plug
16:03:04 <Trozz> I will be driving sadly :(
16:03:10 <abadger1999> gundalow: Is Trozz's idea something that falls sort of in your realm?
16:03:29 <abadger1999> (of coordinating people)
16:03:54 <docschick> Just want to mention the DocSprint for the Ansible contributor summit in early Oct (Brooklyn) <-- trying to drum up some interest :)
16:04:05 <abadger1999> Doc Sprint ++
16:04:19 <gundalow> https://www.ansible.com/blog/ansible-contributor-summit-brooklyn-2016
16:04:49 <abadger1999> #info Testing Working Group has started.  Meeting today at 17:00 UTC
16:05:00 <gundalow> #info Agenda + info on Docs Sprint
16:05:02 <gundalow> ffs
16:05:08 <gundalow> #info Agenda + info on Docs Sprint https://public.etherpad-mozilla.org/p/ansible-summit-october-2016
16:05:22 <abadger1999> #info Doc sprint happening at the next Ansible Contriubtor Summit: Early October in Brooklyn
16:05:56 <gundalow> docschick: I have some ideas for completely redoing http://docs.ansible.com/ansible/developing_modules.html
16:06:35 <gundalow> Once 2.2 stuff has calmed down a bit I'll get more of it written up and speak to you and Scott(?)
16:06:39 <abadger1999> gundalow: put your head together with dharmabumstead (unfortunately, he's on US West Coasttime and doesn't keep as odd hours as I do)
16:06:42 <bcoca> https://github.com/ansible/ansible/pull/17351 <= need to link that there too
16:06:56 <bcoca> he 1h window
16:07:06 <docschick> @gundalow sounds good!
16:07:21 <gundalow> abadger1999: will do
16:07:22 <abadger1999> #info https://github.com/ansible/ansible/pull/17351 Start of documentation of names of common and internal return values
16:07:52 <gundalow> Trozz: Do you mean all issues under github/ansible/ansible*
16:08:06 * docschick heads afk for a bit
16:10:45 <gundalow> bcoca: developing_modules needs to link to common_return_values.rst
16:10:46 <gundalow> ?
16:11:10 <abadger1999> Okay, since Trozz seems to be busy, let's table the discussion of triaging old issues for things that can be closed for later.
16:11:23 <Trozz> just popped away, im back now
16:11:28 <abadger1999> ah cool.
16:11:36 <Trozz> yeah, theres alot dating back quite a while
16:12:01 <bcoca> i try to dedicate part of backlog to oldest pr/issues, but have not been doing triage last 2 weeks
16:12:05 <Trozz> I can help dig through and mention someone if that helps when I think an issue should props be closed
16:12:16 <bcoca> it does help
16:12:24 <gundalow> That would be a massive help :)
16:12:47 <gundalow> Trozz: You could add them onto the agenda ticket (when we create one for next weeks meeting)
16:13:12 <gundalow> $url $suggestion$
16:13:13 <Trozz> Yeah that sounds good :-) which meeting should I add it to as not sure if it falls in to Core
16:13:35 <gundalow> Will propbs be the core team that needs to review the list
16:13:50 <Trozz> kk
16:13:56 * gundalow create agenda for next week
16:14:10 <bcoca> @jtanner:  a bot label 'proposed_closed'?
16:15:39 <abadger1999> gundalow: also -- I think you have to close old agendas.. when I tried, I think I didn't have permission.
16:16:07 <abadger1999> #info Trozz will get teh ball rolling on closing old issues by putting them on the meeting agenda for next week.
16:16:36 <abadger1999> Okay, we've gotten through some good stuff here today.
16:16:38 <gundalow> Trozz: https://github.com/ansible/community/issues/122 agenda. Feel free to keep on editing the same comment rather than adding multiple comments
16:17:02 <abadger1999> If there's nothing new, I'll close in a minute.
16:17:03 <Trozz> gundalow I would do as constant comments can get very annoying ;-)
16:17:14 <abadger1999> (But feel free to keep talking here or in #ansible-devel ;-)
16:17:37 <Trozz> think that's everything
16:18:29 * gundalow -> food -> run Testing Working Group meeting
16:18:39 <abadger1999> #endmeeting