18:00:22 #startmeeting new-module-review 18:00:22 Meeting started Wed Apr 13 18:00:22 2016 UTC. The chair is gregdek. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:22 The meeting name has been set to 'new-module-review' 18:00:32 If people send me a private message with their various alias s + timezone I'll create something 18:00:36 * gundalow waves 18:00:47 olá 18:01:29 we needs google map with location pins 18:01:40 :D 18:01:41 * MichaelBaydoun waves back 18:01:49 ohai 18:02:42 ok, let's see... /me rummages around for an agenda 18:03:50 I added a rough one to MEETINGS.md 18:04:32 Looks good to me. Let's do it! 18:04:39 #topic Review of actions from previous meeting 18:05:18 https://meetbot.fedoraproject.org/ansible-meeting/2016-04-06/new-modules.2016-04-06-18.02.html 18:06:21 Hmm... not looking so good on some of these, I'm afraid. 18:06:24 * gregdek gregdek to create notes on standing meeting and how to show up to get help with your new module 18:06:32 I didn't do this. 18:06:59 So I'll re-action it. 18:07:22 Actually, I'm not sure from context what was promised there. 18:07:59 I *think* what I meant there was to put this into the weekly meeting email. 18:08:03 gregdek: https://meetbot.fedoraproject.org/ansible-meeting/2016-04-06/new-modules.2016-04-06-18.02.log.html 18:08:21 18:12? 18:09:28 Yeah. 18:09:29 https://github.com/ansible/community/issues/51 18:10:02 I've added this to 51. The clear intention was to add this to the weekly notes we send out to the list: "come get help with your module review at the new modules meeting." 18:10:08 I've now added that to the ticket. 18:10:14 Next: 18:10:27 * gregdek gregdek will close extras/1337 as dup of extras/1868 (gregdek, 18:20:15) 18:12:19 Looks like klj613 actually responded. 18:12:27 Which means maybe we should hold off on that. MichaelBaydoun? 18:12:41 agreed 18:13:03 So will leave this one open for now. 18:13:17 With luck, he'll close it himself and get behind yours; let's give him that chance. 18:14:11 Next: ACTION: gundalow and thaumos will test extras/1868 within the next week (gregdek, 18:22:24) 18:14:15 thaumos: you around? 18:14:35 yes sir 18:14:49 Done lots of reviewing, MichaelBaydoun has been great at responding to stuff. It's looking close, but not quiet there yet 18:14:56 There is still dev work being done on the above 18:15:01 have one more bug to squash 18:15:02 ^^ I echo gundalow 18:15:05 Looks like gundalow tested, made some comments, and MichaelBaydoun has also been responding. I assume you're waiting on that? 18:15:09 OK, so it's ongoing. 18:15:24 In the previous meeting there was some discusion about renaming it. Though we've decided it is correct to be ec2_... 18:15:29 Given the amount of work we're doing here, I think it probably makes sense to close 1337 anyway. 18:15:46 If there's broad agreement that 1868 is close. It's certainly received more attention. 18:16:46 No one seems to be in a hurry to do that, though, so I guess we'll wait. :) 18:16:49 Moving on: 18:17:00 * gregdek gregdek to write up new new module guidelines before next meeting (gregdek, 18:49:30) 18:17:08 I also did not do this. Sigh. Let's see if I have a ticket: 18:17:48 (half_joking_action) write bot to create tickets based on meeting actions 18:17:57 ;) 18:18:26 Not the worst idea tbh. 18:18:29 But in the meantime: 18:18:32 :D 18:20:06 as long as it is not against ansible/ansible .... 18:20:13 It's not. :) 18:20:29 https://github.com/ansible/community/issues/78 18:20:52 That's going to be a sweeping change that will require bot changes too, so it could take a while. 18:21:00 And will require some coordination. 18:22:12 OK, moving on: 18:22:17 * gregdek gregdek will propose current_release placeholder 18:23:09 So in discussing this, there was a bit of pushback. Our current systems are not set up to do this. 18:23:22 So it will require a full proposal in ansible/proposals, which is not what I was hoping for. 18:24:18 (sorry, afk, can someone else lead?) 18:24:34 #chair gundalow 18:24:34 Current chairs: gregdek gundalow 18:24:42 OK 18:24:46 (back in 5 i hope, sorry) 18:24:55 :) 18:25:31 Any new modules? 18:25:42 yup, extras/2015 18:25:45 simple one 18:25:59 #topic Next Module 18:26:37 basic create/destroy database in influxdb 18:26:56 since influx is gaining alot of attention lately 18:26:57 #info New module https://github.com/ansible/ansible-modules-extras/pull/2015 InfluxDB database module 18:27:20 Just having read :) 18:28:10 kamsz: How easy is to get get influxdb installed, I've never used it before? 18:28:15 Thinking about how we get it tested 18:28:27 gundalow: you can get it in docker if you want it asap 18:28:39 https://github.com/tutumcloud/influxdb 18:29:05 just docker run it and it's ready to go with the defaults 18:29:32 cool, added a comment to the PR 18:29:37 * gregdek is back :) 18:29:54 i've a module that'll allow writing points to the influxdb, but it's wip 18:30:18 and i was thinking about moving influxdb_argument_spec into module_utils 18:30:29 bcoca: ^ 18:30:39 I wonder if that's premature... 18:30:51 that's why i did it in the module 18:31:22 later on it'll be easy to move it elsewhere 18:31:26 Yep. +1. 18:31:44 18:31:56 abadger1999: except xxx as y doesn't work on python 2.4 thus fails in travis 18:31:59 :p 18:32:37 if you have a dep on py>=2.6 then you can add the module to the 2.4 exclude list for travis 18:32:42 not premature 18:32:47 kamsz: We'd need to change the blacklist in .travis.yml as well. 18:32:57 och, okay 18:32:59 didn't know that 18:33:18 No problem -- just adding to the group knowledge ;-) 18:33:38 I know there is no agreement, and perhaps still opposite to my feelings, but I still feel modules in -extras should not have code in ansible itself 18:33:50 ^^^ 18:34:04 sounds reasonable 18:34:18 which may indicate a need for us to move some of that logic capabilities into the module repos themselves, so that it need not live in ansible proper 18:34:32 We've discussed extras/module-utils. 18:34:38 sivel: module_utils/ec2.py 18:34:45 ^ not really doable 18:35:04 In that case, no. In many other cases, yes. 18:35:10 yeah, we would need to think about it, but I feel that if we put code into ansible to support a module, it should become a -core module 18:35:21 very few, all modules in extras also depend on basic.py 18:35:31 well, that is a bit different, in that core do aslo 18:35:44 if a core module requires it, having it in ansible seems reasonable 18:35:45 I agree with sivel here. Having code in utils is a much higher burden, and from my perspective requires greater commitment. Kind of not what extras is for. 18:35:46 i understand the want, i just don't think it is feasable 18:35:56 +1 18:36:12 my feelings are if it is only in -extras, it should not have accopanying action or utils in ansible proper 18:36:17 sivel: I don't think there's a way to avoid that with current ansible... (otherwise you just have to abandon having shared code). But for 2.2 someone could work on adding other directories for module_utils. 18:36:36 Have to decide how it's presented to the module writer, though. 18:36:43 yeah, not saying it is currently feasible, just saying, we should 18:36:56 From a testing & maintance point it's going to be a PITA having code split between two individualy versioned and released repos 18:36:57 otherwise the line is very blured between extras and core 18:37:00 I think we're placing far too high a burden on accepting modules into ansible-extras. The point was to be a lightweight place for proving new modules, and it's not that at all currently. 18:37:12 :P 18:37:23 which becomes totally obsolete the seconds 1 module is accepted to core that shares code with modules in extras 18:37:38 I think if there is a dep to have code in ansible, we should require the module to go into core, which has more stringent requirements for being accepted 18:37:47 gregdek: noted 18:37:52 then no modules in extras ? 18:38:10 again, I am only saying pure extras modules. I eralize everything requires basic 18:38:47 i think that makes it that every fringe module associated with a group that shares code now needs to be in core 18:38:51 such as I want to have an action plugin for the expect, module, but because it is in extras, I fundamentally disagree with adding it to ansible 18:39:00 ec2_vpc_left_side_private_mananger.py is now a core module? 18:39:30 does it require changes to the shared code? if so, then probably yes 18:39:44 or we find a better way to place code outside of the core repo 18:39:52 i think core/extras division does not have to be on code organization, it is a logical distinction on what we commit to support and what we support 'when we can' 18:39:52 again, just my feelings here 18:39:53 I think we should sovle this in a core meeting. 18:40:03 How about -- "anything in module_utils must be used by at least one module in core". 18:40:05 yeah agreed 18:40:26 cloudstack is now core? 18:40:30 but if we put code in ansible and the module in extras, we have effectively just agreed that part of the code is core and will be treated with higher priority potentially 18:40:31 identify: what's the problems? Then we can code ansible core to make solution for those. 18:40:39 gregdek: -1 18:40:48 and yeah, cloudstack is a prime example of that. 18:40:56 #action abadger1999 discussion between the code split between core, modules & extra in the next Core meeting 18:40:58 sivel: i'm fine treating shared code with higher priority 18:41:01 abadger1999: Thanks :) 18:41:44 going back to the exceptions if i may 18:41:57 yesterday we had a discussion about handling it 18:42:14 someone suggested to use get_exception() (sorry, i don't recall the name) 18:42:19 due to python3 compatibility 18:42:21 #topic exceptions 18:42:23 sounds right, function in basic.py 18:42:40 that was me I believe, in association with bcoca 18:42:59 since i'm slighly confused now which way i should go 18:43:00 it is the compat function to handle exceptions across py2 and py3 18:43:15 it is perfectly fine to continue using, and probably even recommended 18:43:24 except xxx as yyy or get_exception() - which one is more preferable? 18:43:47 +1 on get_exception() that way we are following a standard 18:44:44 I think "except as e" when it will only run on python2.6 and above. 18:45:05 yes , is for 2.4, as e for 3, 2.6 and 2.7 work with both 18:45:07 The get_excetion() way is ugly to me. 18:45:16 so get_exception i think is the only real way to go forward 18:45:19 but the only thing we can do when python-2.4 compat is needed. 18:45:37 it is kinda ugly, but at least it is something we can call a standard, and then there is no confusion how to handle it 18:46:12 ^ least ugly solution 18:46:17 * gundalow -> AFK for 5. Could someone please #info #action as needed so we have a record of the "solution" 18:46:18 there is no good one 18:46:19 I would say it's never wrong to use get_exception() 18:46:33 and then we can have fewer exemptions to the syntax checks also 18:46:38 But I don't really want to require it if some can point at the module needing pyhton-2.6+ already 18:46:55 Same with ternaries, imports of stdlib items from alternate locations, etc. 18:46:58 I think "not required, but recommended" is still a good approach 18:47:03 im fine requireing it, makes it uniform 18:47:17 easier to debug and not have to remember if module is already 2.6+ 18:47:19 but I prefer standardization 18:47:47 I think it makes our porting to python3 burden less i nthe long term if we have a smaller list of modules that need to use pyhton-2.4 idioms and everything else can use the python2.6+ idioms. 18:47:55 and exceptions are one of those things. 18:48:27 so, get_exception() is the way to go? 18:48:38 And we'll add to the guidelines? 18:48:40 Not for me, but I may be outvoted. 18:48:57 (personally i find as x less ugly too and more human like :p) 18:50:10 i dont feel strongly about this one, but i do prefer it 18:50:19 the downsides of handling such a variety of py versions. I do the same in a project that supports py2.4-py3.5 18:50:28 more of a stylistic annoyance, which is not something i'll fight for, i can adapt 18:50:30 but don't have a fancy helper 18:50:50 sivel: wait till py4 compatibility is an issue 18:51:23 just going to find a job fishing or something 18:51:44 street fruit market is a good idea 18:52:05 * gregdek is still hoping for an answer that enough people can say yes to... 18:52:27 I think the answer is to use get_exception() from basic.py 18:52:40 bcoca: ? 18:52:44 my heart says as x, but my mind says get_exception() 18:53:00 im fine either way, do prefer it, but not sure we need to mandate it 18:53:10 I think we shouldn't use get_exception() in python-2.6+ only code but would be willing to accept it as okay. 18:53:22 they are module guidelines right? 18:53:34 :) 18:53:35 Can we make it mandatory in 2.4 and not mandatory for 2.6+? 18:53:49 More and more non-essential modules are python2.6+ because their libraries depend on it. 18:53:51 my concern is the confusion that could create 18:54:05 Worse confusion if there's no rule and no answer. 18:54:25 If we're going to get people to port those to python3, the less barriers and ansible-only stuff we throw at them the better. 18:54:29 And we continue to say arbitrarily "bcoca prefers x" or "abadger1999 prefers y" depending on who looks at it. 18:54:31 we'll have confusion either way, justnot about exceptions (with ...) 18:54:33 if you use `as ` you must list py>=2.6 as a requirement, and actually have a reason for it 18:54:36 I am fine with that 18:54:46 bcoca: yep, that's another one. 18:54:51 not just, I didn't want to write it to work for py24 18:54:54 abadger1999: long list 18:55:00 sivel: :D 18:55:02 Any rule we can point to and say "this is the rule" is a good rule. :) 18:55:06 dict comprehensions, ternary inline ifs 18:55:06 with, ternary, set comprehensions, .... exceptions are just one of them. 18:55:09 etc 18:55:18 sivel: +1 18:55:26 Or maybe new modules should be 2.6+ only! 18:55:32 Rip the band-aid off. :) 18:55:34 HA! 18:55:34 i'm good with sivel suggestion 18:55:38 I think the module guidelines already documented you can use py2.6+ features if the underlying python module requires it 18:55:39 gregdek: +100 18:55:44 but you must list it, and have a valid reason 18:55:49 or at least they did 18:55:54 because I made gregdek add that :) 18:56:06 gregdek: Don't be a tease ;-) 18:56:14 So... maybe srs? 18:56:17 actually ... most extras shoudl be fine being 2.6+ unless they deal with system things instead of just 'applications/apis' 18:56:32 New things are new things. Right? 18:56:39 gregdek: if you can sell that to whoever should make that decision, I'd be all for it. 18:56:44 New modules for AWS as of X date: boto3. 18:56:54 New modules for ANsible as of X date: python 2.6. 18:56:57 so new module to manage selinux, needs to be 2.4, new one to manage trendycloud2.0.io ... might as well by py4 18:57:14 gregdek: not as simple as date 18:57:20 Fair enough. 18:57:29 so, you can use python2.6 syntax, if the underlying python modules require py2.6+. But it must be documented as requiring py2.6+ with a valid reason, and .travis.yml will need to have the exclusion extended 18:57:33 oh god trendycloud is that merged yet! i saw that on hackeroverstackflow. must switch everything 18:57:51 sivel: +1 Sounds good. 18:57:51 But maybe it's time to start looking at what those parameters could be. 18:57:58 rbergeron: i do have hackernews module .... 18:58:09 anyway. 18:58:12 gregdek: there ya go, I got a +1 from abadger1999. 18:58:18 ^ also have task that browsers hacker news jobs while async task installing packages runs 18:58:20 * gundalow returns 18:58:25 did we agree anything? 18:58:27 in the absence of deprecating 2.4, can someone restate the rule so we can make it a rule? :) 18:58:45 sivel> so, you can use python2.6 syntax, if the underlying python modules require py2.6+. But it must be documented as requiring py2.6+ with a valid reason, and .travis.yml will need to have the exclusion extended 18:58:47 Is that the rule? 18:59:01 modules that deal with traditional systems and tools should still be 2.4, modules that deal with 'newer' services and APIs can be 2.6+ 18:59:01 yes. it doesn't state get_exception() specifically though 18:59:15 so extend as needed :) 18:59:18 sivel: 2 rules 18:59:19 Well, it's a rule that covers many sub-cases, which we can enumerate. 18:59:35 (Or at least I imagine it to be. I don't actually know what I'm talking about, of course.) 19:00:08 ^ that covers python version, next rule: if module is not already 2.6+ it MUST use get_exception, else you SHOULD use `as e` or get_exception (never `, e`) 19:02:02 OK. 19:02:42 https://github.com/ansible/community/issues/79 19:02:53 We'll make a PR to the guidelines. 19:03:09 do we all agree on py2.4? abadger1999? 19:03:31 or do we leave it on case by case? 19:03:32 yes, agreed. 19:03:48 jimi|ansible? 19:04:10 if there's corenercases in the future, we can revisit then but this looks like it should cover reasonable people doing reasonable things. 19:04:15 anyone know how much longer rhel5 is supported? 19:04:47 March 2017 19:04:48 abadger1999: agreed, just want to make sure we have no oposition, as this can be a pain 19:05:02 and extended support? 19:05:19 https://access.redhat.com/support/policy/updates/errata 19:05:30 (Want to wrap up in 5 if we can so we can move onto community meeting) 19:05:32 bcoca: for further illusrations of how this works, please see how many times windows xp had an EOL date that got extended :) 19:05:34 For rhel4 we did end of production 3 I think. 19:05:49 So march 31, 2017 if we do the same 19:06:29 extended support 3 years beyond 19:06:32 extended lifecycle support is 2020 but I'm going to pretend that no one will ask us for that. 19:06:32 rbergeron: life = (number of people not upgraded * whining coeficient ) ^ number of bugs 19:06:36 https://access.redhat.com/support/policy/updates/errata 19:07:06 errr, 10 years beyond, yikes 19:07:09 ok, so i'm fine then with limiting 2.4 support from now on 19:07:25 * bcoca starts writing virus to kill any OS running 2.4 by end of 2017 19:08:07 :D 19:08:33 * jimi|ansible reads back 19:09:06 +1 19:09:36 LOL 19:09:39 To the whole thing? 19:09:46 fast and clean response 19:09:54 to the rule regarding py2.4 syntax 19:09:55 jimi|ansible: you're a fast reader 19:09:58 was there further discussion? 19:10:17 nope, last 20 lines shold be enough 19:10:25 No, that was the gist. :) 19:10:31 Took a while to get there though. 19:10:52 Anyway. kamsz hope that clarified things a little bit. 19:10:55 jimi|ansible: greg really wanted us to extend suport to rhel4 and py2.3 but we didnt want to 19:11:01 o_O 19:11:02 gregdek: yeah 19:11:02 staaaahp 19:11:12 thanks guys, again i've managed to start fiercy discussion 19:11:12 also php4 ... 19:11:16 jimi|ansible: I wanted to kill 2.4 support for all new modules. :) 19:11:33 (Actually, I still want that. But perhaps not ready.) 19:11:37 i once started up a RHEL 4 vm to diagnose a bug and then was like waaiiittttt.... 19:11:48 but yeah, too soon 19:12:04 maybe once EL5 is EOL, regardless of whether it's in extended support, so 2017 19:12:21 i think this is good rule to start 'phasing out' 19:12:31 most new apps/clouds don't work with 2.4 systems anyways 19:12:55 +1 to "phasing out" currrent modules and core sysadmin functions continue to work but we chip away at the periphery 19:13:36 gregdek: I think the idea's approved. 19:13:43 ok, i think we are all on same page and happy to see the beginging of the end of 2.4 support! 19:14:21 the only thing i'd also say is that any modules that don't work on py2.4 should have a big prominent note 19:14:39 Easily achieved with docs building changes, yes? 19:14:45 yep 19:14:56 Something to consult with docschick on maybe. 19:15:22 already needs a `requriements` entry 19:15:24 Page is crimson red if 2.4 support. >:-) 19:15:39 with flashing banner 'WARNING' 19:15:44 gregdek: i was going for 'catacomb black' 19:15:57 ANYWAY our li'l community meeting is now 15m late, so imma call this meeting done. 19:16:10 thanks guys! 19:16:13 Already captured this proposal in a github issue, so that's that. 19:16:16 Thanks kamsz! 19:16:19 #endmeeting