19:06:08 <bcoca> #startmeeting ansible core irc public meeting 19:06:08 <zodbot> Meeting started Tue Jul 3 19:06:08 2018 UTC. 19:06:08 <zodbot> This meeting is logged and archived in a public location. 19:06:08 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:06:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:06:08 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting' 19:07:17 <jhawkesworth_> hey 19:07:22 <abadger1999> Hello 19:07:36 <bcoca> #topic https://github.com/ansible/ansible/issues/42041 backporting rewriets 19:08:36 <bcoca> @fabianvf ? 19:08:41 <bcoca> @sdoran 19:09:10 <bcoca> @nitzmahone 19:09:16 <abadger1999> So this is specifically about backporting a new module for 2.6 19:09:18 <abadger1999> ? 19:09:21 <bcoca> ^ since you are 2.5 RM you might want to weigh in on it 19:09:24 <abadger1999> You want mattclay 19:09:30 <bcoca> abadger1999: a rewrite of an old module 19:09:31 <abadger1999> oh wait. 19:09:33 <abadger1999> it's in 2.6 19:09:43 <abadger1999> yeah, so nitzmahone 19:09:50 <abadger1999> It looks like a new module to me. 19:10:07 <abadger1999> With the old modules aliased to the new module or calling out to them from an action plugin or something. 19:10:11 <bcoca> its a rewrite, so yes ... 19:10:13 <abadger1999> (from the comments on the bug) 19:10:25 <sdoran> It is indeed a new module that fixed this issue. 19:10:42 <sdoran> So I'd say just use Ansible 2.6 rather than backport a new module to a previous release. 19:10:52 <bcoca> agreed 19:11:01 <bcoca> backporting new/rewrite is not something i recommend 19:11:11 <jhawkesworth_> if you really need in 2.5 presumably you can copy to your /library 19:11:12 <nitzmahone> Yeah, same 19:11:19 <fabianvf> It's a new module with a near identical interface, but the changes are significant 19:11:29 <sdoran> The issue was closed by the original author. 19:11:37 <sdoran> He seemed happy with using Ansible 2.6. 19:12:32 <abadger1999> Yeah, with no one saying they need it, I think we go with the default for now (just upgrae to Ansible-2.6) 19:12:40 <bcoca> understood, and i see good effort in keeping backwards compat to avoid breaking playbooks, but i dont think we want to backport changes of this magnitude 19:12:48 <sdoran> Agreed 19:12:52 <fabianvf> Makes sense to me 19:12:59 <bcoca> dont even think we need vote on this one. 19:13:16 <bcoca> # topic https://github.com/ansible/ansible/pull/39794 to GPL or not to GPL on module_utils 19:13:27 <bcoca> #topic https://github.com/ansible/ansible/pull/39794 to GPL or not to GPL on module_utils 19:14:06 <bcoca> im fine with adding as an exception, but would like more 'caution tape' .. just not sure what that would look like 19:14:46 <abadger1999> -1 19:14:52 <abadger1999> There's not a good justification for htis. 19:15:03 <bcoca> the library it imports is gpl2 19:15:12 <abadger1999> yes, but that isn't a problem. 19:15:20 <bcoca> ??? 19:16:08 <bcoca> afaik bsd=>gpl is fine but gpl=>bsd is not 19:18:15 <abadger1999> When using the ansible module, the work as a whole will be GPLv3+. 19:18:42 <abadger1999> But, if someone takes the module_util code and modifies it to not rely on a GPL library, then they will be able to use it as BSD. 19:19:17 <bcoca> i dont see anyone reimplementing the apt interface 19:19:18 <abadger1999> For us, that becomes most important when talking about people copying code from one module_utils to another 19:19:36 <abadger1999> (rather than someone rewriting the python-apt module). 19:20:03 <bcoca> i dont think we can legally republish as bsd this file even if we use with our modules in gpl3 19:20:25 <abadger1999> We also just told someone to relicense one or two weeks ago (when they were dual licensed) so I don't think precedent supports us consciously allowing GPL code in here. 19:20:30 <abadger1999> We can. 19:20:34 <bcoca> and yes, the copypasta is what worries me and i would like more caution tape .. but unsure how to do 19:20:51 <abadger1999> You're confusing a license on individual bits of code with the license on the work as a whole. 19:21:14 <bcoca> both are applicable,depending on how you bind to it, module_utils is something we expose to 3rd parties 19:21:23 <bcoca> if code there is importing gpl code .. its gpl 19:21:29 <abadger1999> No it's not. 19:21:44 <bcoca> pretty sure a direct code import makes it so 19:21:46 <abadger1999> The work as a whole has to be GPLv3+. 19:22:06 <abadger1999> But someone can take that code to another context and it can then fall under the BSD license. 19:22:24 <bcoca> that makes no sense to me, but IANAL 19:22:47 <abadger1999> It's pretty simple... 19:23:06 <abadger1999> Since you don't surrender copyright, you can choose to license your work under any terms that you want. 19:23:23 <bcoca> i dont think it is, you are saying it is fine to relicense a particular file as long as the 'whole' follows teh original license 19:23:31 <abadger1999> If two works are licensed undr different but compatible terms, they can be released under a license that satisfies both. 19:23:39 <abadger1999> No. 19:23:41 <bcoca> yes, i understand that, but for that it requires the python-apt guys to relicense 19:23:45 <abadger1999> We're not talking about relicensing. 19:24:08 <abadger1999> basic.py is licensed BSD. Ansible is licensed GPLv3+ 19:24:21 <bcoca> yes, as i said, that direction is not a problem 19:24:24 <abadger1999> When used from within Ansible's controller code, the work as a whole is GPLv3+. 19:24:34 <bcoca> but reverse it, and we have an issue 19:24:40 <abadger1999> When used from within a module, the work as a whole can be licensed as BSD or something else. 19:24:57 <bcoca> if the work didnt depend on gpl libs imported .. yes 19:24:57 <abadger1999> no. 19:25:25 <abadger1999> Anyow, the argument in the issue is invalid. 19:25:35 <abadger1999> So it should be relicensed to BSD. 19:25:36 <bcoca> if i write code that imports gpl libs, license it as bsd .. im violating it 19:26:20 <abadger1999> No. You aren't violating the license until you claim that the work as a whole is BSD. 19:26:28 <abadger1999> the snippet of code that you wrote can be BSD. 19:26:42 <abadger1999> But the work as a whole must comply to the GPL which means that it needs to be GPL. 19:26:42 <bcoca> but i cannot distribute it as such, since i import gpl 19:27:01 <bcoca> both are 'distribution licenses' not really 'writing code license' 19:27:08 <abadger1999> Someone can take the snippet of code from the work as a whole and use it in a BSD program. 19:27:18 <bcoca> i cannot distribute bsd code that imports a gpl license as bsd 19:27:19 <abadger1999> That's why the license on the individual piece of code matters. 19:27:37 <bcoca> only if they remove the hard dep that is the gpl lib underneath 19:28:58 <abadger1999> You're incorrect. 19:29:13 <abadger1999> But apparently no amount of examples will prove it so you'll just have to ask fontana 19:29:28 <bcoca> afaik this is the 'infectious' part of the gpl 19:29:38 <bcoca> if you import it .. you are also required to distribute as gpl 19:29:53 <bcoca> even if he licenses it to US as bsd, once we distribute it it has to be gpl 19:30:03 <sdoran> I don't understand the various licensing nuances enough to comment. We should get another set of eyes on it. 19:30:14 <sdoran> Lawyer eyes. For better or worse. :) 19:30:21 <bcoca> #info put to lawyers 19:30:59 <bcoca> #topic actually use 'type' in docs ... to describe type https://github.com/ansible/ansible/pull/42033 19:31:07 <bcoca> ^ module docs, config docs already do this 19:31:13 * gundalow waves 19:31:22 <bcoca> @sdoran ^ 19:31:40 <abadger1999> -1 for now. 19:31:54 <sdoran> Would be nice to use type in docs to actually state data type. 19:32:04 <abadger1999> When we do go down this path we will need to support more than simple types 19:32:09 <sdoran> Or at least do something with it to make it less ambiguous 19:32:19 <gundalow> From a user point of view all that `documention.options.FOO.type = bool`does is expands to `choices: yes/no` 19:32:19 <abadger1999> subspecs will come into play. 19:32:27 <bcoca> which are dicts/lists 19:32:32 <bcoca> well, subspec is dict 19:32:33 <abadger1999> containers, yeah. 19:32:40 <sdoran> But I don't understand exactly why it's behaves the way it does today, so I figured I bring it up. 19:32:52 <bcoca> +1 to using it to document types 19:33:04 <abadger1999> I do think we could expand it in the future... but we're not really ready for it yet. 19:33:26 <bcoca> unsure what you think we need that we dont already have? 19:33:26 <sdoran> The original issue wanted to use it for type validation for syntax highlighting in their IDE. 19:33:40 <abadger1999> Have them use the argspec. 19:33:56 <bcoca> we want users to 'know' the types also, its nice for when they input the data 19:34:03 <jhawkesworth_> argspec is great. just wish we could use for windows modules 19:34:20 <sdoran> Not sure if we want to address their issues directly, but it started the conversation about that field in docs. 19:34:29 <abadger1999> I think nitzmahone and jborean93 were figuring out how to replicate the framework for powershell. 19:34:34 <bcoca> the current state 'type: boolean' is only 'valid type, seems bad 19:34:34 <sdoran> abadger1999: That's what I told them to do. Hopefully they'll go with that. 19:34:54 <bcoca> sdoran: that still leaves the current state, which is bad imo 19:35:15 <sdoran> So why does it behave this way today? 19:35:23 <nitzmahone> I've built most of it a few times, but keep hoping we'll get functional controller-side argspec so we won't have to maintain a separate PS copy of it 19:35:34 <sdoran> Seems we should either expand it, or just pull from the arg spec to show that data in the documentation. 19:35:41 <sdoran> Rather than having to repeat yourself. 19:35:48 <jborean93> PowerShell does support types currently, just not as advanced as basic.py 19:36:38 <bcoca> sdoran: docs are already a huge repeat of argspec, including default/required/choices/etc 19:37:01 <bcoca> im not against unifying, im against having a 'type' field in docs that ONLY works for 1 type and errors for others 19:37:12 <sdoran> I got enticed yesterday when I found out the docs for callbacks actually provide defaults. :) 19:37:13 <bcoca> so we either remove type or implement it 19:37:45 <bcoca> sdoran: i kept it so we have single source there, i learnt from modules and havinig dupe info all over 19:39:34 <bcoca> so we have 3 options a) implement ful type: docs, b) remove type: c) leave current 'hybrid' state 19:39:40 <bcoca> im really -1 to c) fine with the other 2 19:39:44 <abadger1999> We can get rid of the type field and go back to using choices. But then we'd have to implement more complex docs-parsing logic to normalize those. The one-off for booleans is very useful. 19:39:53 <abadger1999> If you want, you could rename it, though. 19:40:01 <sdoran> I'm in favor of remove it or implement it. Seems really confusing to users currently. 19:40:03 <abadger1999> s/types: boolean/boolean: True/ 19:40:14 <abadger1999> Remove it and replace with booleans: True. 19:40:25 <abadger1999> It doesn't confuse most users because it is internal. 19:40:31 <bcoca> i woudl prefer implementing, so to give docs to users 19:40:32 <abadger1999> You have to look at the source code to see it. 19:40:45 <bcoca> abadger1999: no, you see it in docs 19:41:17 <abadger1999> Ugh, well that should be changed. 19:41:26 <abadger1999> oh well. 19:41:36 <sdoran> abadger1999: Do you mean if we changed to `booleans: True` we could omit that from the `ansible-doc` output? 19:41:39 <bcoca> - validate_certs 19:41:41 <bcoca> When set to "no", SSL certificates will not be validated for boto versions >= 2.6.0. 19:41:42 <bcoca> [Default: yes] 19:41:44 <bcoca> type: bool 19:41:45 <bcoca> version_added: 1.5 19:41:47 <bcoca> ^ example 19:43:06 <abadger1999> sdoran: Right now, we can spell this as choices: [True False] instead of types: boolean 19:43:16 <abadger1999> because that's really all it's useful for. 19:43:35 <bcoca> yes/no on/off also work, so its a small ie 19:43:38 <bcoca> lie 19:43:40 <abadger1999> I was speaking because of: [12:32:19] <gundalow> From a user point of view all that `documention.options.FOO.type = bool`does is expands to `choices: yes/no` 19:43:52 <gundalow> back, was in another meeting 19:43:54 <bcoca> i think he means html docs 19:43:59 <gundalow> yup 19:45:23 <gundalow> Last year when I was doing mass tidy up of module DOCUMENTATION I found loads of typos and junk in there, so I spent a load of time tidying it up and enforcing it all via https://github.com/ansible/ansible/blob/devel/test/sanity/validate-modules/schema.py#L43-L55 19:46:09 <bcoca> gundalow: we were discussing 3 opts a) allow the basic types, b) remove type: c) leave current 'hybrid' 19:46:10 <gundalow> in the Jinja2 that generated the module docs `type: bool` gets expanded to `choices: yes,no` 19:46:24 <bcoca> not true/false? 19:46:38 <gundalow> If we allow other types 19:46:45 <jborean93> I think at least we should be validating the types currently and throw an error if it is an invalid type 19:46:46 <gundalow> 1) what would that data be used for 19:46:58 <bcoca> @jborean93 modules do that via argspec 19:47:06 <sdoran> That already happens. 19:47:09 <jborean93> that's argspec I'm talking more doc validation 19:47:12 <bcoca> the issue here is docs, right now ONLY None or bool are allowed 19:47:22 <gundalow> 2) I think we should extend `validate-modules` to ensure that docs.type match argspec.type. Currently that validation only occurs for type bool 19:47:52 <gundalow> Or put another way, is their any use for supporting other documentation types apart from IDE auto completion? 19:48:02 <bcoca> well, 2 steps, a) allow types other than bool, b) validate against argspec 19:48:18 <bcoca> gundalow: users normally like to see the type expected 19:48:34 <sdoran> @gundalow Just general info for the user. It would be nice to know the data type of a field. 19:48:39 <gundalow> ok 19:48:39 <bcoca> myoption: < wtf to i feed this, type: list <= makes it a lot clearer 19:49:07 <bcoca> gundalow: check the docs for lookups, they have types, makes it clear what is expected 19:49:10 <gundalow> ok, I'm happy with that IFF `validate-modules` is updated to ensure the type in DOCUMENTATION matches the type in docs 19:49:12 <gundalow> ffs 19:49:17 <gundalow> ok, I'm happy with that IFF `validate-modules` is updated to ensure the type in DOCUMENTATION matches the type in argspec 19:49:54 <abadger1999> I think we should have someone work on controller-side argspec and just use that. 19:49:59 <bcoca> funny, we have full types on 'return' but not on input? 19:50:15 <abadger1999> return is train wreck 19:50:36 <bcoca> how so? 19:50:50 <abadger1999> sdoran: Do you want to take up controller -side argspec as a feature? 19:51:18 * gundalow doesn't see a proposal for docs from argspec, though I'm sure it's been discussed a few times 19:51:22 <bcoca> gundalow: if im reading this correctly? just adding the types to the code you showed enables them? 19:51:32 <bcoca> gundalow: yes, it has 19:52:49 <gundalow> bcoca: oh https://github.com/ansible/ansible/blob/devel/docs/templates/plugin.rst.j2#L121 may "just work" 19:53:07 <bcoca> it just works for ansible-doc also 19:53:11 <gundalow> noice 19:53:22 <bcoca> that might be simplest solution 19:53:38 <abadger1999> inconsistent, incomplete, no way to validate that the docs match the code, underspecified format for the entries that leave authors wondering how to speicfy things like nested levels and variable output.... 19:53:43 <gundalow> Yup, now that we have the improved html table for module options 19:54:00 <gundalow> abadger1999: You talking about RETURNS? 19:54:06 <abadger1999> gundalow: yep. 19:54:10 <gundalow> cool 19:54:22 <sdoran> @abadger1999 Sure! I have no idea what that is, but I'll learn. 19:54:23 <bcoca> format is specific, last i looked, the subentries for dict/list can themselves also specify type 19:54:54 <bcoca> only problme i see with types in returns is 'complex' < -=totally my fault, it should just have been dict 19:55:14 <gundalow> hum, so if we add this `validate-modules` will find lots of issues, so we need to either 1) Add `DOCUMENTATION.OPTIONS.foo.TYPE` to everything (prefered) or 2) add a load of `ignored.txt` 19:55:17 <abadger1999> sdoran: Cool. I think that's the proper way to address this (and nitzmahone jhawkesworth_ and jborean93's needs for a structure for powershell, and finally gets rid of our having multiple canonical locations for the information) 19:55:47 <bcoca> gundalow: 'adding this' means updating validate modules to add those as valid type fields 19:55:55 <bcoca> seems like that should 'just work'tm 19:56:04 <bcoca> just in 2 spots, options and suboptions defs 19:56:10 <sdoran> I'll need some guidance/input, but I'd be happy to implement it. 19:56:26 <gundalow> bcoca: sure, though will find loads of bad module docs that will need updating 19:56:43 <bcoca> how so? currently it is not allowed 19:56:53 <bcoca> so they'll all match 'None' by default 19:57:02 <abadger1999> sdoran: <nod> nitzmahone has probably thought the most on this. 19:57:08 <gundalow> oh, sorry, I meant when we ensure that the type in docs match the type defined in argspec 19:57:13 <abadger1999> sdoran: I've done a little thinking too. 19:57:24 <sdoran> I believe it. :) 19:57:27 <bcoca> gundalow: well, when people start adding them, PRs will error out 19:58:00 <gundalow> validate-modules will need to continue to pass on the existing modules 19:58:07 <abadger1999> sdoran: there's two foundations to it: (1) single point of informaton about a module's args for all consumers. (2) make this information efficiently available to the controller, not just to the modules. 19:58:17 <bcoca> existing modules should not have type: unless its boolean, as it currently complains if they do 19:58:31 <gundalow> validate-modules change part 1: Allow other types in schema.py (this is fine) 19:59:14 <gundalow> validate-modules change part 2: Ensure type in DOCUMENTATION matches argspec - This will throw up loads of errors as most module args haven't got type defined 19:59:27 <sdoran> But then we need to fix the thing that's using the `type` field so it doesn't blow up with something besides `bool` in there. 19:59:49 <bcoca> sdoran: we looked at plugin.rst, it should work fine 19:59:51 <gundalow> part 2 includes: and argspec.foo.type matches documentation 19:59:54 <sdoran> Could `type` be optional? 19:59:59 <sdoran> @bcoca roger 20:00:01 <bcoca> yes, default is string 20:00:04 <bcoca> just like argspec 20:00:05 <gundalow> hum, so could do 20:00:45 <gundalow> part 2 (alternaive) iff DOCUMENTATION.option.foo.type exists, ensure it matches argspec 20:00:56 <gundalow> ^ Will allow current modules to pass 20:01:22 <gundalow> though ensure someone doesn't add missmatched type in argspec 20:01:57 * gundalow isn't sure if he's being clear about part 2 vs part 2 (alternative) 20:02:28 <abadger1999> gundalow: rather than that.... write a script to add the information. 20:02:43 <gundalow> That would be great if someone could do that 20:02:48 <abadger1999> you have argspec with types. Just push that information into the module documentation. 20:03:07 <gundalow> ooooooook 20:03:18 <bcoca> part 3 20:03:47 <gundalow> so sounds like we are agreed that schema.py should be updated and just do a quick docs build to ensure types are presented OK. That should fix the #topic issue 20:03:47 <bcoca> #topic open floor 20:03:54 <abadger1999> anyhogun-1 20:03:56 <bcoca> anything else? over time alreayd, so you have 1 min 20:03:57 <abadger1999> gundalow: -1 20:04:09 <bcoca> gundalow: +1 20:04:14 <abadger1999> I'm +1 for controller side argspec. -1 to messing with docs. 20:04:28 <abadger1999> messign with docs will be lots of churn that we'll just throw out anyways. 20:04:44 <bcoca> +1 for docs, will work now, controller side argspec is much bigger project 20:04:50 <abadger1999> becaues we'll be throwing it out to implement controllerside argspec. 20:04:52 <gundalow> Does someone want to put together a proposal for controller side argspec? 20:05:04 <bcoca> abadger1999: not really since 3rd party already relies on current docs and how it works, specially for non ppython modules 20:05:05 <nitzmahone> Not for 2.7 :) 20:05:07 <abadger1999> I think we volunteered sdoran above ;-) 20:05:10 <gundalow> nitzmahone: exactly 20:05:17 <sdoran> I suppose that would be me since I volunteered to do it. 20:05:23 <gundalow> sdoran: :D 20:10:16 <bcoca> so both? vote? 20:11:53 <bcoca> #endmeeting