15:03:05 <bcoca> #startmeeting ansible core irc meeting
15:03:05 <zodbot> Meeting started Thu Apr 19 15:03:05 2018 UTC.  The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:05 <zodbot> The meeting name has been set to 'ansible_core_irc_meeting'
15:03:57 <sivel> .hello2
15:03:59 <zodbot> sivel: sivel 'Matt Martz' <matt@sivel.net>
15:04:10 <bcoca> #topic open floor
15:04:12 <maxamillion> .hello2
15:04:13 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:04:16 <maxamillion> oh, bcoca beat me to it
15:04:19 <maxamillion> :)
15:04:41 <bcoca> maxamillion: seems like ive been handling most of the meetings lately, @thaumos ???
15:05:37 <bcoca> soo, become plugins, everyone seen the PR? questions/opinions?
15:05:55 <maxamillion> I have not seen it... or I don't remember
15:06:05 <maxamillion> this other project has my brain all distracted/scrambled
15:06:10 <bcoca> https://github.com/ansible/ansible/pull/38861
15:06:59 <sivel> I have not looked at it as of yet.
15:08:08 <sivel> so I can't say I have much of any question or opinion at this time
15:08:20 <maxamillion> bcoca: just did a quick read over it, I like the idea ... I suspect we'd need a *lot* of testing :)
15:08:42 <maxamillion> bcoca: also, are the DEFAULT_SUDO_* and DEFAULT_SU_* vars going away with this change?
15:08:45 <bcoca> 90% of it is moving existing code, but yes
15:08:59 <jtanner> hello (multitasking with bluejeans meeting)
15:09:10 <bcoca> yes, but each can still keep their config/envvars/connection vars
15:09:43 <bcoca> but constants will not have sudo/su entries (they were goint to be removed in 2.8 anyways)
15:09:49 <maxamillion> bcoca: cool
15:15:28 <bcoca> k, since no one seems to have anything .. going to close meeting
15:16:23 <maxamillion> +1
15:16:33 <sivel> I have something
15:16:38 <sivel> didn't realize we were moving on yet
15:16:53 <sivel> I found an oddity in subspec defaults yesterday.
15:17:15 <sivel> if the top level is not required, and the sub options have defaults, they are never considered if you omit the top level option
15:17:41 <sivel> My attention was drawn to it, due to workarounds that have been implemented to get around that
15:18:00 <sivel> In one case, duplicating the defaults, and applying `default` to the top level arg
15:18:21 <bcoca> sigh
15:18:26 <sivel> I've submitted a PR, which ultimately brought me to adding a new argument option called `apply_defaults`
15:18:33 <sivel> because so many people have worked around the issue
15:18:38 <sivel> I can't just change how it works now
15:18:46 <bcoca> *sigh*
15:18:50 <sivel> because like every network module breaks
15:18:54 <bcoca> why didnt they file bug??!?!
15:18:59 <sivel> exactly!
15:19:09 <sivel> So in any case
15:19:09 * bcoca tempted to break it ... as a teaching exercise
15:19:13 <sivel> here is the PR
15:19:15 <sivel> https://github.com/ansible/ansible/pull/38967
15:19:27 <sivel> As mentioned it adds a new `apply_defaults`
15:19:42 <sivel> that can be used on the parent, to actually allow you to use `default` on subspec arguments
15:19:43 <bcoca> can you add a 'deprecated' to apply_default=false?
15:19:57 <sivel> bcoca: maybe
15:20:13 <bcoca> that woudl make people fix their modules and we could remove the insanity
15:20:15 <sivel> Apparently because this has been the way it worked for so long, people are actually relying on this behavior now
15:20:29 <bcoca> hence deprecation vs outright error
15:20:29 <sivel> Apparently people have weird expectations
15:20:36 <bcoca> yes, yes they do
15:20:59 <sivel> I'll play with it, but since this is a minimal change, I plan on adding to 2.6 if possible
15:21:00 <bcoca> *mumble* xkcd .. keyboard as heat source ...*mumble*
15:21:15 <sivel> so if I do add a deprecation, probably not in 2.6
15:21:34 <sivel> I'd like to not add any deprecations in 2.6, due to "stability"
15:22:11 <bcoca> i would consider current state unstable ...
15:22:24 <sivel> I also know that none of these options have docs really.  So I may likely start some docs for the argument keys
15:22:33 <bcoca> agreed
15:22:36 <sivel> Yeah, seeing as though people have been actively working around it...
15:22:46 <sivel> which annoys me.  Submit a bug.
15:23:10 <bcoca> funny enough, networking folk actually did the full subspec implementation, i had started but didnt have time to finish
15:23:28 <sivel> I talked to peter, and he believed it was an oversight due to rushed impl
15:23:28 <bcoca> there is the expertise there to actually deal with the defaults issue
15:23:43 <sivel> in anycase, here we are
15:23:44 <bcoca> which is ok, but then dont reimplement fix on eveyr plugin ...
15:24:19 <bcoca> +1 to merge .. i woudl deprecate right away, but fine if you do so in 2.7 ... add note to code and/or PR on 2.7 milestone?
15:24:31 <sivel> Yeah, I'll get to it, after I write docs
15:24:55 <jtanner> i know very little about subspecs or this problem ... +0
15:26:03 <bcoca> jtanner: basically recursive argspec
15:26:38 <bcoca> when 'top' level key was not getting set, we set default automatically, but then we didnt traverse down and set appropriate defaults for subkeys
15:26:43 <sivel> If you look at the PR, I provide an example that should make it clear
15:26:53 <bcoca> this fixes that ..  but has to allow for modules that were doing this themselves
15:30:33 <sivel> That's it for me right now
15:30:43 <jtanner> ah, i see now
15:31:26 <jtanner> hopefully people don't  assume the existence of the key implies it was set
15:32:57 <bcoca> anything else?
15:33:26 <sivel> not from me
15:34:13 <bcoca> #endmeeting