15:00:07 #startmeeting puppet-openstack 15:00:08 Meeting started Tue Apr 7 15:00:07 2015 UTC and is due to finish in 60 minutes. The chair is crinkle. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:11 o/ 15:00:12 The meeting name has been set to 'puppet_openstack' 15:00:30 #topic Review past action items - EmilienM to document sbadia's email in the wiki 15:00:43 EmilienM: completed? 15:00:55 o/ 15:00:56 yes 15:01:07 #link https://wiki.openstack.org/wiki/Puppet/PTL 15:01:28 great 15:01:35 #topic Review past action items - mgagne or dvorak runs a new thread on ML about Defaults for new config file parameters 15:01:47 I haven't seen this thread yet 15:01:54 I have not followed up on this action, sorry 15:01:55 crinkle: I still intend to write something up, probably later this week 15:01:57 hi 15:01:59 I will now 15:02:03 or that :) 15:02:09 dvorak: or you can do it =) 15:02:13 haha 15:02:17 dvorak and I are at a work offsite thing and will be told to close our laptops soon 15:02:36 either way is ok with me, I won't be able to get to it until the end of the week, feel free to do it before then if you get bored :) 15:02:46 alright 15:03:04 #action mgagne to start thread on defaults for new config file parameters 15:03:40 #topic puppet-neutron/L2: Discuss about https://review.openstack.org/#/c/159769 and https://review.openstack.org/#/c/106144 15:03:43 EmilienM: ? 15:03:55 I would like people to see https://review.openstack.org/#/c/159769 and https://review.openstack.org/#/c/106144 - I'm in favor of #2 but we need to agree 15:04:22 https://review.openstack.org/#/c/106144 is a really old patch and we should make it land sometimes 15:04:34 :D 15:05:08 EmilienM: I'll try to see if I can get an opinion on that one 15:05:43 #link https://bugs.launchpad.net/puppet-neutron/+bug/1426080 15:05:45 Launchpad bug 1426080 in puppet-neutron "neutron agents ml2 linuxbridge class does not modify ml2_conf.ini" [Undecided,In progress] - Assigned to Emilien Macchi (emilienm) 15:05:49 #link https://review.openstack.org/#/c/106144 15:05:53 #link https://review.openstack.org/#/c/159769 15:06:33 crinkle: I'm not sure we need more time on this topic, I just need people reviewing it in Gerrit 15:06:37 and give feedback 15:06:37 okay 15:06:42 so we can go ahead 15:06:54 #topic spredzy: creation of a FAQ that would be authoritative in case of doubt. 15:07:00 spredzy: ? 15:07:18 As I was doing some review I cam across https://review.openstack.org/#/c/169066/ 15:07:45 like https://wiki.openstack.org/wiki/Puppet/FAQ ? :-) 15:07:56 or something in specs, as a blueprint 15:08:08 where dvorak and mgagne disagreed, and someone is currently enabling OracleLinux adding option to $::operratingsystem and not using $::osfamily 15:08:24 I like the idea proposed by spredzy. it's long overdue IMO 15:08:33 aha 15:08:35 so they're all correct patches, but I think we should enforce some of them and have a link where the authoritaive answer is 15:08:41 mgagne: specs or wiki? 15:08:45 none 15:08:50 I would like to see something in rspec/lint about it 15:09:18 mgagne, we could have both a wiki and a specific rspec-lint-plugin for a specific rule 15:09:22 sure 15:09:43 because if it's in wiki, it won't be automatically enforced 15:09:44 and we could keep track of it else its hard to put a -1, because its written nowhere how to actually do it 15:10:08 +1 15:10:08 mgagne, right, but if the user wants clearer description a link to a wiki entry might be a good idea 15:10:18 sure 15:10:35 this seems less like an FAQ and more like a style guide 15:11:03 yep, whatever it's called 15:11:15 i think there could also be an FAQ for things that aren't lintable 15:11:34 we need to structure our style and enforce it otherwise people will enforce whatever they wish depending on the moon's phase 15:11:38 Such as when to use <||> or not 15:12:35 anything else on the subject? 15:12:36 we could in a first phase structure one we would create, let see if everything agrees on it and actually on a second phase implement it 15:12:44 would that be good w/ everybody ? 15:12:56 ack! 15:12:59 +/ 15:13:00 +1 15:13:09 +1 15:13:14 yep 15:13:14 sure, spredzy can you take that action item? 15:13:27 #action spredzy structure w/ the community what exactly will be created and propose a plan on next meeting 15:13:35 spredzy: thanks :D 15:13:48 yw :) 15:13:56 we can move on 15:13:58 okay moving on 15:14:03 #topic gchamoul: Proposition to produce rspec-puppet coverage reports for each openstack puppet modules 15:14:10 #link https://review.openstack.org/170712 15:14:21 #link https://review.openstack.org/171114 15:14:25 gchamoul: ? 15:14:52 the goal is to produce a coverage report in the rspec tests 15:15:03 gchamoul: can you provide more details in the commit about how you can run the tests? I know you can read the source but it would be nice to get a starter guide in the commit message 15:15:57 mgagne: yes, but we just need to add a line in the spec_helper.rb 15:16:06 mgagne: tests are run automatically at exit 15:16:11 gchamoul: oh, it's "only" a report at the end of execution? 15:16:12 to be able to get the coverage report! 15:16:48 mgagne: look at the end of the log file http://logs.openstack.org/12/170712/2/check/gate-puppet-tempest-puppet-unit-3.7/6dd7751/console.html 15:17:35 you will get the total number of ressources, the tested resources and a list of untested resources 15:18:15 gchamoul: I ran spec tests on my laptop without the additional coverage you did. I'm not sure someone can easily understand from the output what needs to be done. 15:18:24 so for the moment rspec-puppet doesn't filter the ressources coming from the fixture modules 15:18:35 oh, I was wondering 15:18:46 and we will need this PR https://github.com/rodjek/rspec-puppet/pull/258 15:18:47 but it's still good to have it 15:19:29 Shiny 15:19:58 mgagne: The information about the total number of resouces is interesting (and potentially an indicator of complexity) but the list of untouched resources is the main useful part. These represent both information about what your module is doing, and potential things you might want to test. 15:22:04 I'm ok with it if we can find a way to enforce it. My point is that due to the "unhelpful" output, until we have 100% coverage, I wouldn't force someone to add coverage. The barrier of entry is high enough (for an operator) that we shouldn't make it even harder for them to contribute 15:23:05 +1 for mgagne 15:23:48 today, I'm sure there is a gazillion uncovered resources and it would be unfair to ask someone to try find which ones HE introduced and test them. The output sucks and is not useful in tracking down WHERE the not-covered resources are. 15:24:29 that's my take on it 15:25:22 does the coverage report cause a failure if it's under-covered? 15:25:37 crinkle: nope! it's just informative! 15:25:48 then it doesn't seem harmful to me 15:25:57 who will enforce it? 15:26:11 mgagne, we could add it to msync 15:26:13 the line : at_exit { RSpec::Puppet::Coverage.report! } 15:26:19 spredzy: +1 15:26:21 a core telling someone that somewhere in the console.log is telling the coverage is lower than before? 15:26:23 mgagne: what do you mean by who will enforce it ??? 15:26:45 nothing needs to be enforced, only the output needs to be present 15:26:45 gchamoul: if it's not automated, it's useless 15:26:55 spredzy: than to me, it's useless 15:26:59 but the output isn't useful if we're not doing something with it 15:26:59 like coverage.io ? :) 15:27:13 if this line is present on every project is spec_helper.rb it will provide the information 15:27:18 crinkle: that 15:27:25 but what action do we take on the information? 15:27:38 if it's not enforced, it's noise and wasted effort 15:27:56 will someon take an action item to increase coverage to 100% on all the modules? because taht seems like a huge undertaking 15:28:25 Once we have those information, we can quantify it and do the actual effort to go toward the 100% 15:28:33 being able to value what have been done 15:28:39 crinkle: I am ok with that! 15:29:06 crinkle: I already opened a bugs about the rspec tests 15:29:06 okay then 15:29:09 * crinkle +0 15:29:30 yep, +0 here as I know I won't be able to contribute seriously to the effort 15:29:52 and I won't force someone else to add coverage 15:29:59 when we were updating rspec2->3 with sbadia. I identified some inconsistency within the tests in the modules 15:30:08 there are a lot 15:30:19 a lot of types/providers are not tested ... 15:30:20 sbadia: https://github.com/rodjek/rspec-puppet/pull/214 was adding https://coveralls.io/ support 15:30:24 for example! 15:30:48 gchamoul: yep (shared example, distro specific units, …) 15:30:57 yes! 15:30:58 Coverage was JUST added to rspec-puppet and isn't fleshed out much yet... 15:31:04 Hunner: oh cool, thanks for the link 15:31:28 if this depends on new features in rspec-puppet then we could be waiting a while 15:31:30 AFIK other OpenStack projects don't have 100% coverage (I'm not saying it's good though) 15:31:49 100% coverage or bust! ~ 15:32:05 I +0 too, I'll be happy to review but I won't help much on sending patches. 15:32:17 IMO, we have bigger fish to catch with better ROI 15:32:25 crinkle: yes for now ... the coverage percentage are irrelevant due to the bad filter on the fixtures 15:32:39 i think the discussion can be tabled for now if rspec-puppet isn't even ready for this 15:32:52 EmilienM: the goal is not to get 100% 15:33:42 gchamoul: can we specify the % ? 15:34:23 WRT coverage, are we getting actual failures that having more test coverage would fix? 15:34:28 EmilienM: nope, we actually cannot trick it! but I planned to send some PRs in the next days 15:34:32 if so, we could adjust our modules with existing coverage 15:35:04 mgagne: if you have any suggestion for bigger fish, go ahead 15:35:30 tests are never big fishes, but we still need them. 15:35:33 EmilienM: fixing consistency across our modules. Making sure we have the same common feature baseline across our modules 15:35:45 mgagne: that's a big fish too 15:35:52 with great ROI 15:36:16 EmilienM, mgagne: the tool we talked last week as well! 15:36:18 mgagne: is that we talked before with spredzy ? 15:36:27 so people don't contribute one by one those features over several months in each modules but with inconsistency 15:36:31 yep 15:36:46 that tool identifying all new parameters, the deprecated ones ... new default values and so on ... 15:37:25 this one also has a good ROI 15:37:31 we talked about it last meeting 15:38:01 yep! 15:38:08 is there an action we can take on this topic now, or should we move on? 15:39:19 crinkle: once the rspec-puppet coverage feature will be able to give us better infos, I will put that subject on a future agenda 15:39:27 again! 15:39:29 ok? 15:39:35 okay 15:39:37 I think the tests thing is more for medium-long term 15:39:44 in short term we should focus on consistency tools 15:40:02 #agreed gchamoul to revisit rspec-puppet coverage when new feature is landed in rspec-puppet 15:40:13 (ie spredzy's topic is short term) 15:41:17 okay 15:41:26 gchamoul: are you interested to contribute to this one? 15:41:33 the tool we mentioned last week 15:41:38 with mgagne 15:41:41 yes! 15:42:01 I was thinking and dreaming about this tools for a while now :D 15:42:06 =) 15:42:41 #action gchamoul starts working on "Defaults for new config file parameters" tool 15:42:45 * spredzy have to leave 15:42:46 gchamoul: sounds good? 15:42:58 perfect 15:43:15 moving on? 15:43:17 crinkle: we're all set for this topic I think 15:43:23 okay 15:43:31 #topic PTL election 15:43:42 we received one nomination as far as I saw 15:43:51 should we leave the nomination period open for another week, or call it? 15:44:47 what's the deadline for openstack projects? 15:44:48 i vote call it 15:45:01 * EmilienM abstains 15:45:05 maybe I am wrong but I don't think we will have more nomination.... 15:45:15 so call it! 15:45:21 mgagne: I'm not sure, we didn't start it in sync with the other projects 15:45:24 sbadia, President! :-p 15:45:29 "Nominations for OpenStack PTLs (Program Technical Leads) are now open 15:45:29 and will remain open until April 9, 2015 05:59 UTC." 15:45:32 gchamoul: ? 15:45:38 kidding!!!! 15:45:54 okay, let's leave it open till April 9 then 15:46:07 agree 15:46:13 +1 15:46:14 if there is no one else, so be it 15:47:00 I can send an email at the end of this meeting making a last call for nominations 15:47:05 EmilienM++ 15:47:06 +1 15:47:14 +100 15:47:23 #agreed PTL nominations to close on April 9 15:47:37 cool 15:47:39 Wait, we have to have our submission in by then 15:47:41 thanks crinkle 15:47:47 Not closing our own electing then 15:47:52 #actoin crinkle to send email reminding about nominations 15:47:58 #action crinkle to send email reminding about nominations 15:48:06 Hunner: right, last call to nominate, not elect 15:48:16 but if there's only one nominee then we don't have to decide how to elect 15:48:42 Ooo, nominate not elect. Right 15:49:40 should we use the rest of the 10 minutes for open discussion, bug triage, or review triage? 15:49:46 yes 15:49:54 I have something to say 15:50:00 EmilienM: go for it 15:50:07 crinkle: please change the topic :-) 15:50:14 on i thought you meant on this topic 15:50:18 #topic open discussion 15:50:20 about Summit, I asked for "Open Cloud Ecosystem Collaboration Day" which is a room for a full day. So we will have time and space to work together during a whole day. I did not have a reply yet, but i'll let you know. 15:50:44 crinkle: that's it thanks :-) 15:50:50 thanks EmilienM 15:51:26 are there bugs or reviews that anyone wants the group to look at? 15:51:49 yes https://review.openstack.org/#/c/170486/ :D 15:52:38 gchamoul: remove whitespaces ? :) 15:52:54 the whitespace was there already 15:53:01 indeed… 15:53:17 thanks mgagne 15:53:27 others? 15:53:38 thx mgagne 15:53:42 yw 15:53:58 oh wait! 15:54:16 msync ? 15:54:28 I would like you to take a look at this one https://review.openstack.org/164125 15:54:33 from spredzy 15:55:21 gchamoul: looks like you made a comment that hasn't been addressed yet 15:55:49 wth is that? o_O 15:56:11 mgagne: see https://github.com/puppetlabs/modulesync_configs/blob/master/README.md 15:56:19 crinkle: I think you are the best person to tale about this :D 15:56:27 s/tale/talk/ 15:57:03 mgagne: is the issue with the whole patch or the rakefile template? 15:57:05 mgagne: don't worry. it won't hurt! ;-) 15:57:22 I don't know what this tool does and where it came from 15:57:28 haha, mgagne you come from the past ? :p 15:57:37 yep 15:57:42 mgagne: from puppetlabs itself! 15:57:43 * mgagne goes back to his cave 15:57:48 ahah 15:57:56 mgagne: noooo :) 15:58:04 2 min left guys 15:58:07 I'm not subscribed to the RSS feed of puppetlabs organization on github 15:58:16 crinkle: I wanted to see the fix about the puppet-lint filter again! 15:58:20 it's a tool to synchronize common files across multiple repositories, so that if for example we need to pin a gem across all modules we can do it more easily 15:58:30 gchamoul: ? 15:59:00 mgagne: it might be worth having a longer discussion on whether we should be using it here, I'm not convinced we should 15:59:06 but we need to wrap up the meeting 15:59:09 #endmeeting