15:00:03 <gundalow> #startmeeting Core Team Meeting 15:00:03 <zodbot> Meeting started Thu Jan 26 15:00:03 2017 UTC. The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:03 <zodbot> The meeting name has been set to 'core_team_meeting' 15:00:14 * jtyr is here ;o) 15:00:29 <gundalow> #chair abadger1999 allanice001 bcoca jimi|ansible jtyr mattclay nitzmahone Qalthos rcarrillocruz 15:00:29 <zodbot> Current chairs: Qalthos abadger1999 allanice001 bcoca gundalow jimi|ansible jtyr mattclay nitzmahone rcarrillocruz 15:00:33 <gundalow> jtyr: Hello 15:00:42 <gundalow> oh, did we have something on the agenda for you 15:00:45 * gundalow looks 15:00:55 <jtyr> yeah, ... the hosts module 15:01:05 <jtyr> nicely PEP8 compliant ... ;o) 15:01:18 <alikins> bloop 15:01:24 <gundalow> Sounds like a good place to start 15:01:27 <gundalow> morning alikins 15:01:35 <gundalow> #topic Adding etc_hosts module #19283 15:01:40 * nitzmahone lurks 15:01:41 <gundalow> https://github.com/ansible/ansible/pull/19283 15:02:10 <gundalow> nitzmahone: good very early morning to you :) 15:02:14 * allanice001 waves 15:02:44 <nitzmahone> :) 15:03:55 <gundalow> jtyr: I couldn't see mentioned is why this module v template or lineinfile? 15:04:51 <jtyr> gundalow: it's the same like yum_repository module ... everything could be done by templates or inline ... 15:06:41 <bcoca> yeah ... wish i could remove that module 15:08:04 <jtyr> if you want some arguments, here they are: it unifies formatting, it assures the columns contain the right values (common mistake of users to swap alias and domain) ... 15:08:43 <bcoca> a hosts_file role would ensure same things 15:09:17 <jtyr> yumrepo role would do the same as yum_repository module ... 15:09:22 <jtyr> that's not an argument ... 15:09:36 <jtyr> you can not force users to use primitives all the time ... 15:09:52 <jtyr> this is why modules are out there ... they make user's life easier ... 15:10:22 <jtyr> instead of having 1000 roles doing the same, you have one module doing it for everybody in the same way ... 15:10:29 <gundalow> jtyr: Nor do we want to force everyone to do everything with just a dozzen modules, though we want to ensure that we aren't adding in modules for the sake of it 15:10:50 <gundalow> You've made a very good point there 15:11:24 <bcoca> jtyr: yes it is, i have the same issues with yum_repo 15:11:26 <gundalow> jtyr: I assume it works fine with IPv6 addresses, might be worth just adding an example in for that 15:12:00 <jtyr> in this case IP4 is the same like IP6 ... 15:12:15 <jtyr> people who use IPv6 know that ... no need to add such example ... 15:12:17 <bcoca> it does not verify that they are valid IP? 15:12:39 <jtyr> bcoca: I can add that ... 15:12:59 <jtyr> using some python library which does that ... 15:13:07 <jtyr> do you know about some? 15:13:19 <bcoca> or ... you can use existing ip filters in a role ... 15:13:44 <jtyr> ;o) 15:13:52 <allanice001> jtyr, python validate does have it 15:14:31 <gundalow> Is that it built in module? 15:15:10 <allanice001> gundalow, i doubt it 15:15:18 <alikins> I'd like to see a etc hosts module that took a list/tuple of entries. I'd lean towards making that a separate module though just to keep the args and state logic sane. 15:15:32 <jtyr> allanice001: I was more thinking about something like this: import ipaddress; ipaddress.ip_address('999.1.1.1') 15:15:42 <jtyr> seems to be standard part of Py 15:16:48 <jtyr> ah ... 2.7+ ... ;o( 15:17:17 <gundalow> For the purpose of keeping this meeting moving I'm going to move onto another topic in 10 minutes 15:17:43 <allanice001> jtyr, here is what i use - https://validators.readthedocs.io/en/latest/ 15:17:58 <allanice001> but, it is a seperate requirement 15:18:10 <jtyr> exactly ... ;o( 15:18:31 <jtyr> it would be nice if it wouldn't build another dependency ... 15:18:56 <allanice001> agree 15:21:16 <jtanner> sorry, i've been on different screens and didn't even realize this was going on 15:21:45 <gundalow> -1 to adding extra dependencies 15:22:13 <jtanner> we had a hosts module in the past, but it caused a lot of issues due to the numerous types of schemas have in the file https://github.com/ansible/ansible/issues/5748 15:22:20 <bcoca> a role can do it w/o the extra deps ... 15:22:31 <jtanner> therefore dehaan removed the module. 15:27:13 <alikins> jtanner: that module was for setting hostname not manipulating /etc/hosts 15:27:24 <alikins> and the hostname module still exists 15:27:38 <jtyr> bcoca: let's remove all modules from Ansible and replace them by roles ... ;o) 15:27:59 <jtyr> bcoca: we already had the discussion that roles are not that convenient like modules .... 15:28:12 <jtyr> role != task ... 15:28:14 <jtanner> alikins: true, but that's just an example of how people have different views about the content of /etc/hosts 15:28:19 <bcoca> not all, but many 15:28:33 <bcoca> jtyr: that was before include_role 15:29:47 <jtyr> bcoca: ugly ... 15:30:27 <bcoca> pushes the maintenance burden outside the repo, makes customization easy for non programmers 15:30:36 <bcoca> imo 15:31:12 <jtyr> bcoca: but that doesn't reduce the fragmentation ... IMHO the biggest problem the Ansible community has ... 15:31:35 <jtyr> bcoca: like 1000 roles for nginx configuration in Galaxy ... 15:32:00 <bcoca> and as soon as we merge all modules prposed, we have the same issue but in anisble/ansible 15:32:15 <bcoca> which is why i want to push 'non core modules' to galaxy 15:32:22 <bcoca> but that is diff discussion 15:32:45 <jtanner> we can't keep up with the modules we already have, so i'm never going to default to "more modules == good" 15:33:20 <bcoca> modules that do stuff we dont already cover ... yes i can see the point of accepting those 15:33:23 <jtanner> http://jctanner.mynetgear.com:5000/modulestats 15:33:29 <jtyr> bcoca: I got one nginx role which is possible to use for any purpose (https://github.com/jtyr/ansible-nginx) ... using the config_encoder_config filters ... do you remember? ... the thing you don't want to have in Ansible ... ;o) 15:33:31 <bcoca> modules that have overlap ... im inclined to say no 15:34:06 <bcoca> jtyr: for the same reasons as i dont want modules that overlap, i dont want filters that do same 15:34:14 <bcoca> ^ s/modules/any plugin/ 15:35:08 <jtyr> bcoca: modules in roles in Galaxy ... sounds good ... this is what I'm currently doing with the config_encoder_filters .... https://github.com/jtyr/ansible-config_encoder_filters 15:35:31 <jtyr> bcoca: distributing it as a role dependency ... that works ... 15:35:39 <gundalow> .............................................. 15:35:39 <gundalow> .............................................. 15:35:40 <gundalow> .............................................. 15:35:41 <gundalow> OK 15:35:42 <bcoca> and i'm fine with that, that is what sharing is for 15:35:45 <gundalow> I'm moving us on now 15:35:45 <jtyr> bcoca: I can imagine to do the same for any other module ... 15:35:57 <gundalow> (I gave 10 minutes notice 20 minutes ago_ 15:36:00 <gundalow> ) 15:36:03 <bcoca> i just dont want to be overwhelemd more in ansible/ansible as most expect us to then maintain and deal with the issues of this code 15:36:12 * jtyr shuts his mouth up ;o) 15:36:25 <bcoca> jtyr: and galaxy is not currently best place to share, i agree 15:36:33 <gundalow> jtyr: Lets fall back to the standard process here, which is get two shipits and we can discuss again 15:36:35 <bcoca> ^ better tools are needed to share/install plugins 15:36:38 <alikins> whats the next topic? 15:36:59 <gundalow> #topic module_utils/basic.py: Support logical or condition in required_if #20220 15:37:04 <gundalow> https://github.com/ansible/ansible/pull/20220 15:37:57 <gundalow> I think this would be really useful. Since mentioning it on #ansible-devel yesterday, someone else said "that would be good for my modules as well" 15:38:32 <bcoca> i like the idea, have not looked at code 15:41:09 <gundalow> code looks fairly simple. I'll document it as part of developing_modules refactoring 15:41:52 <gundalow> It's a change to basic.py, so I'd like someone apart from me to look at it 15:42:56 * gundalow assumes the quietness is people looking at the code :) 15:44:11 <gundalow> ANy offers for review? 15:44:17 <gundalow> please add yourself, thanks 15:44:31 <gundalow> #topic 15:44:31 <gundalow> Edit 15:44:31 <gundalow> Refurbish developing modules content - stage 1 #20673 15:44:41 <gundalow> #topic Refurbish developing modules content - stage 1 #20673 15:44:50 <gundalow> https://github.com/ansible/ansible/pull/20673 15:45:07 <gundalow> This is the initial stage of a refurbishment of the module development documentation that Scott and I have been working on 15:45:48 <gundalow> basically dev_guide/developing_modules.html is now chopped into multiple pieces, so it's easier to update 15:45:59 * abadger1999 waves good morning 15:46:01 <gundalow> I'll be updating module checklist first (separate PR) 15:46:06 <gundalow> hey abadger1999 15:46:32 <gundalow> allanice001: ^ first cut of improving docs 15:46:39 <gundalow> no functional change, just moves the sections around 15:47:02 <allanice001> will look at it 15:47:25 <gundalow> allanice001: Thanks 15:47:32 <jtanner> would a module init script help with some of what that guide attempts to do? 15:47:43 <jtanner> ansible-module-init 15:47:54 <jtanner> makes a libarary dir with a stub module in it 15:48:00 <gundalow> jtyr: You mean something that generates a boiler plate, I like that idea 15:48:01 <jhawkesworth> hey. just read a little and might be worth directing readers to windows module writing section as its rather different from python modules (no zip, separate .py documentation etc) 15:48:38 <gundalow> jhawkesworth: Do you know where that is, I saw an into_windows, though that seemed to be user facingm rather than module developer facing 15:49:24 <gundalow> jhawkesworth: The windows stuff is here at the moment https://github.com/ansible/ansible/pull/20673/files#diff-284ac9a0338a9f568dab8b2269818418R135 15:49:25 <jhawkesworth> gundalow: I'll take a look iirc there's not much more than a windows module checklist 15:50:09 <gundalow> jtanner: I like that idea, lets ponder it a bit more 15:50:25 <jtanner> gundalow: another aspect of boilerplate generator is that we can evolve it into a tui that asks questions and fills in the blanks 15:50:49 <jtanner> we/community 15:50:56 <gundalow> jhawkesworth: I was considering having a separate developing_modules_windows page with the how to & specific checklist, how does that sounds 15:51:02 <gundalow> jtanner: +1 15:51:21 <jtanner> maybe have it create a role dir though instead of library, then we can use it to encourage include_role + galaxy 15:51:41 <bcoca> there will be repeats , i would have 'common' and then specific rules for each 15:51:43 <jhawkesworth> gundalow: sounds like a good idea to have separate windows page 15:51:50 <bcoca> the common are mostly interface/naming/scope related 15:52:46 <gundalow> So my current plan is 15:52:59 <gundalow> Into (which is there) Should this be a module 15:53:04 <gundalow> PAGE: General developing 15:53:13 <gundalow> PAGE: Developing AWS modules 15:53:18 <gundalow> PAGE: Developing Network modules 15:53:23 <gundalow> PAGE: Developing Windows modules 15:53:43 <gundalow> PAGE: Checklist (& coding guidelines) 15:53:51 <gundalow> PAGE: Python 3 15:53:59 <gundalow> PAGE: How to debug a module (not just for module authors) 15:54:16 <gundalow> PAGE: How to add and extends tests 15:55:18 <gundalow> So if you were developing a WIndows module you've read "General" + "Developing Windows modules" + "Checklist" + "How to add and extends tests" 15:55:40 <jhawkesworth> sounds good although windows module debugging probably different from python modules 15:56:02 <jhawkesworth> ... to do no ansibalz and powershell ISE 15:56:13 <gundalow> ah, good point 15:57:13 <jhawkesworth> also recent discussion maybe some adv topic for windows such as sensible way to call external programs (if you must), calling .net code and embedding c# code. 15:57:27 <jhawkesworth> but probably fit all that on windows modules page 15:57:28 * gundalow adds that to his notes 15:58:31 <jtanner> gundalow: created https://github.com/ansible/proposals/issues/49 15:58:32 <gundalow> jhawkesworth: Thanks 15:58:49 <gundalow> jtanner: Ace :) 15:59:03 <gundalow> For a first cut are people happy with https://github.com/ansible/ansible/pull/20673 15:59:29 <gundalow> In particular the new developing_modules.html page https://github.com/dharmabumstead/ansible/blob/fba6bfc2ea21ee47e9090ea900d386c1b35073e0/docs/docsite/rst/dev_guide/developing_modules.rst 16:01:27 <jhawkesworth> gundalow: also some chat about a 'model' module for windows devs demonstrating module param processing here https://github.com/ansible/ansible/issues/20505. 16:01:27 <bcoca> gundalow: will read, have not had time until now, can we reschedule for next meeting before approving? 16:02:18 <allanice001> i'm guessing no meetings next week due to ansible installs paris ? 16:02:22 <gundalow> bcoca: It's the same content, just moved round a little bit, Most is going to get rewritten 16:02:36 <gundalow> allanice001: only myself jimi|ansible and rcarrillocruz will be in Paris from the Core Team 16:02:37 <abadger1999> gundalow: developing_modules_general.rst isn't really... general. 16:02:44 <abadger1999> It's more tutorial, 16:02:50 <gundalow> abadger1999: it's SHIT 16:02:56 <abadger1999> heh :-) 16:02:57 <gundalow> and that's why it's going to be rewritten 16:03:23 <gundalow> All the above PR does it chop stuff into pieces so it's easier to improve 16:04:03 <gundalow> apart from correcting spelling mistakes I don't believe their are many actual changes in the PR, apart from moving stuff around and the intro page 16:04:09 <abadger1999> It's not a bad page to me but it's for a different audience. 16:04:42 <jtanner> https://github.com/ansible/proposals/issues/49 would reduce the reliance on that doc, imo. 16:05:32 <abadger1999> I'd probably move the content back into the main docs when you rewrite general. 16:05:50 <abadger1999> Until we split out a "tutorial" type introp to ansible from more referencey docs. 16:05:59 <abadger1999> *intro to 16:06:05 <gundalow> abadger1999: yup, I want to get a much clearer separation between user facing and dev_guide 16:06:38 <gundalow> did we want a different directory for docs for people with commit access 16:06:53 <abadger1999> copntributor rather than committer. 16:07:11 <abadger1999> I think it will end up being distinct... but I'm not sure if there's consensus. 16:07:44 <abadger1999> For instance, the module checklist is for contributors rather than for people writing their own custom modules. 16:08:07 * gundalow views the checklist as been good for everyone 16:08:12 <abadger1999> We could split it later after we see what it's like. 16:08:16 <gundalow> (that writes modules) 16:08:20 <allanice001> also, what prevents a galaxy like solution for distributing custom modules 16:08:26 <gundalow> +1 to making it a problem for the future 16:08:40 <abadger1999> allanice001: You can currently use galaxy for distributing modules. 16:08:54 <abadger1999> We should write a section about that and stick it in the main guide. 16:09:22 <bcoca> having module-init does not mean docs should not exist either 16:09:34 <bcoca> docs need to exist, then module-init can use them as rules to make life easier 16:09:44 <abadger1999> (Looked for it the other day and found the individual pieces but had to stitch it together from reading a cou0ple different pieces of the docs) 16:11:57 <abadger1999> yeah, module-init should follow the documented standards rather than the other way around. 16:13:13 <gundalow> I hope to get a first cut of new checklist done by the end of next week 16:13:59 <gundalow> Then realistically, the rest will have to wait till post 2.3 16:14:57 <gundalow> Anythine else 16:15:02 <gundalow> Anyone else got anything? 16:16:07 <allanice001> at last got back to pr#19421 16:16:12 <allanice001> and added your feedback 16:16:16 <allanice001> gundalow, ^ 16:17:38 <gundalow> Thanks 16:17:41 <gundalow> #endmeeting