15:43:48 #startmeeting Helium Weekly 15:43:48 Meeting started Wed Aug 6 15:43:48 2014 UTC. The chair is edwarnicke. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:43:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:43:48 The meeting name has been set to 'helium_weekly' 15:43:59 Please #info in 15:44:01 #info edwarnicke 15:44:02 #info goldavberg for lispflowmapping 15:44:09 #info dkehnx - opflex 15:44:11 #info liemmn for aaa 15:44:12 #info oflibMichal for openflowjava 15:44:13 #info regXboi for :) 15:44:17 #info paulz for docs 15:44:17 #info Luis for integration 15:44:21 #chair regXboi LuisGomez tbachman 15:44:21 Current chairs: LuisGomez edwarnicke regXboi tbachman 15:44:24 #info Rafat for ODl-SDNi App 15:44:26 :) 15:44:28 guys 15:44:33 have to cut out soon 15:44:35 :( 15:44:35 #info brockners for SNBI 15:44:41 will get someone else for rep 15:44:41 #link https://wiki.opendaylight.org/view/Simultaneous_Release:Project_Expectations 15:44:56 #info link for project expectations 15:45:01 LuisGomez You seemed to be driving something... if so, please set the topic :) 15:45:26 #topic Q&A on M4 deliverables 15:45:28 #info priyanka for southplugin for opencontrail 15:46:02 #info so far we are asking projects to fill karaf features 15:46:26 #info abhijitkumbhare for Openflow plugin 15:46:44 #info there will be also components to cover those parts cannot be defined in Karaf 15:47:05 #info George Zhao for RM 15:47:29 gzhao__: :) Thank you so much for the Release Management work :) 15:47:29 #info ChristineH for snmp4sdn 15:48:14 so is there any other questions on deliverable? 15:48:56 #info Madhu will explain more in detail thr java test documentation and report we expect projects to fulfill 15:49:33 #info basically we are asking for some Junit test coverage 15:49:46 Is there any coverage % expectation? 15:49:59 LuisGomez: Until Sonar is fixed (or someone can explain how to work with the installed version) that is mechanically impossible for many projects 15:50:03 #info there is no % expectation yet 15:50:27 #info there is wiki on Sonar coverage: 15:50:44 We can't seem to get unit and integration test coverage in sonar... 15:50:53 #link https://wiki.opendaylight.org/view/CrossProject:Integration_Group:Code_Coverage_using_Jacoco 15:51:05 goldavberg: We have the same issues in controller and yangtools and bgpcep have also reported similar 15:51:23 #info unit test should work with this instruction 15:51:29 @edwarnicke bgpcep should be fixed 15:51:30 LuisGomez: hi. am in. 15:51:48 ttkacik: So bgppcep is reporting in sonar? 15:51:57 #info there are issues reporting PAX-EXAM test to Sonar but Madhu has workaround for that 15:52:20 Madhu: Do you have a pointer to your workaround? 15:52:27 +1 15:52:30 Madhu: I am talking about java test report already 15:52:37 LuisGomez: okay 15:52:43 after the sonar upgrade 15:52:52 we have the fix for both UT, IT and Pax-Exam 15:52:58 Does anyone know if there is a way to break down reporting from a project in sonar into logical units? 15:53:11 In controller it would be very helpful to be able to report by subsystem... 15:53:12 Madhu: excellent! 15:53:14 edwarnicke: define logical unit 15:53:26 adsal, mdsal, configsubsystem... 15:53:39 Logical unit being a collection of projects 15:53:48 (maven projects) 15:53:53 edwarnicke: its the way you organize the tests. 15:54:00 Madhu: Can you say more? 15:54:09 edwarnicke: looking for examples to talk :) 15:54:12 gimme a second 15:54:18 Madhu: Thank you :) 15:54:22 #info ovsdb sonar reporting : https://sonar.opendaylight.org/dashboard/index/14975 15:54:37 #info madhu says Sonar is now ready to handle UT and IT (PAX-EXAM) tests 15:54:39 in the above link it reports UT, IT and Pax-Exam results 15:54:41 edwarnicke: yes, it is 15:54:44 Folks, filling out the template now for GBP 15:54:52 yang tools patches were merged in 15:55:05 alagalah: Many thanks :) 15:55:11 #info https://sonar.opendaylight.org/drilldown/measures/14975?metric=tests shows all the tests being run 15:55:13 edwarnicke: Bloody traffic 15:55:46 #link https://sonar.opendaylight.org/drilldown/measures/14975?metric=tests is an example from ovsdb project which shows all the tests including UT, IT and Pax 15:56:04 to answer edwarnicke the logical subsystem can be grouped using pax-exam tests 15:56:34 #link https://sonar.opendaylight.org/drilldown/measures/14975?metric=tests&rids[]=15977 is an example of pax-exam tests for 3 subsystems in ovsdb logically grouped 15:56:45 neutron, plugin and library 15:56:51 OK... and what for unit tests 15:56:52 Sorry all.. Is meeting over? 15:57:03 under these groupings, the tests (cases) can be written to cover them all up 15:57:06 Madhu: How do I group unit tests? 15:57:12 edwarnicke: unit tests are unit tests :) 15:57:21 the definition of unit test is for a given unit. 15:57:31 that can go as granular as it wants to. 15:57:51 Madhu: How do I define that? 15:58:00 edwarnicke: define what ? 15:58:02 * edwarnicke is trying to figure out how to do it so it reports pretty :) 15:58:27 edwarnicke: unit tests by definition is granular per class/method. 15:58:38 so am not sure what you mean by grouping 15:58:42 OK 15:58:46 is your question purely from a reporting stand point ? 15:59:04 I want to take a bunch of maven projects, and put some in them into a 'group' in sonar 15:59:08 So I can see a group of them there 15:59:11 edwarnicke: in that case, Junit provides a concept called listeners 15:59:14 Reported as a unit 15:59:24 Madhu: Purely from a reporting standard 15:59:26 edwarnicke: yes. you can define your own groups in the listeners 15:59:33 How? 15:59:37 and the listeners can group it the way you want 15:59:46 edwarnicke: i will give a tutorial on that offline :) 15:59:53 Madhu: Thank you :) 16:00:09 LuisGomez: Where were we before we diverged :) 16:00:19 Madhu: does a PAX-EXAM IT test covers more or less a karaf feature? would you recommend that? 16:00:47 #link https://git.opendaylight.org/gerrit/#/c/9482/ fix to enable pax-exam results in sonar 16:00:55 please use that fix in other projects and start capturing results 16:01:02 Ed: we are discussing java test deliverables 16:01:40 LuisGomez: yes. pax-exam works very well with Karaf 16:01:44 and highly recommend it 16:01:55 Madhu: I haven't tried it... but it looks *very* sane :) 16:01:58 #info pax-exam and karaf features go really well together 16:02:18 #info pax-exam without karaf is a disaster :( and the following link will explain why 16:02:49 #info thats why we set PAX-EXAM IT in release check list 16:02:56 Madhu: second the pax-exam without karaf being a disaster :) 16:04:00 #link https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=integrationtest/src/test/java/org/opendaylight/ovsdb/integrationtest/ConfigurationBundles.java;h=f43dea7f331640a2f45f1505fe9efb2b1c2a5a5f;hb=master example of pax-exam without karaf definition 16:04:22 #info its literally a train wreck and it is very difficult to debug even a single missing dependency for the entire IT 16:04:49 #info Based on our "not-so-happy-experience" highly highly recommend Pax-exam with Karaf. 16:05:08 #info but ... highly recommend doing pax-exam testing. especially in a OSGi environment like ours 16:05:25 #info mere FailSafe UT & SureFire IT will not help 16:05:30 #undo 16:05:32 #Madhu is there a wiki for that? 16:05:50 goldavberg: wiki for pax-exam and karaf ? 16:05:58 Madhu: Are you going to provide instruction on the Docker based stuff you guys are doing at TWS this week? 16:06:00 mlemay: was owning that wiki i believe :) 16:06:10 edwarnicke: is it related to this discussion ? 16:06:25 #info 6 projects don't participate PAX-EXAM based on M4 status out of 20 reported. 16:06:28 #Madhu yes 16:07:05 goldavberg: mlemay will add the wiki for pax-exam with karaf i believe. if he cannot, i certainly will 16:07:38 Madhu: Will you be covering the dockerish tests on Mondays TWS? 16:07:43 #Madhu thx 16:07:48 there something already written here: https://wiki.opendaylight.org/view/OpenDaylight_Controller:Integration_Tests 16:08:08 LuisGomez: thanks 16:08:19 I added a Karaf paragraph i copied from MAthieu 16:08:23 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Integration_Tests wiki on using pax-exam 16:08:24 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:Integration_Tests 16:09:30 LuisGomez: Could that be cleaned up to at least have the karaf part show up in the Table of Contents? 16:09:32 gzhao__: some projects might not need PAX-EXAM 16:10:17 gzhao__: We do have some projects with significant non-osgi C code 16:10:30 gzhao__: So maybe its not YES/NO but rather YES/NO/NA 16:10:45 edwanicke: clean up possible but I would like Mathieu to review the Karaf section too 16:10:53 gzhao__: the tests are highly recommended for every project to be a matured project 16:10:54 LuisGomez: Yep :) 16:11:10 LuisGomez: Can we put in the topic queue that we need someone to look after the autoreleases 16:11:12 those who don't have a reasonable coverage (which has to be defined) will not be considered matured enough ... i hope. 16:11:17 So we don't have issues with that at the very end 16:11:34 +1 Madhu 16:11:45 Madhu: The Simultaneous Release Plan specifically *forbids* that kind of last minute change in expectations 16:11:55 Because its not OK to change requirements at the last minute 16:12:01 edwarnicke: what requirements ? 16:12:04 And we couldn't work out reasonable requirements at time of plan 16:12:10 And we *still* don't have them 16:12:15 edwarnicke: we are talking only about project maturity 16:12:21 Oh 16:12:24 not about simultaneous release :) 16:12:28 You mean the discussion about promotion to mature? 16:12:31 edwarnicke: how did u get that impression ? 16:12:33 Totally fair discussion :) 16:12:47 Madhu: I did... but I may have been reading to fast :) 16:12:47 edwarnicke: glad u c it as fair :) 16:13:00 we have to encourage good behaviour 16:13:03 Fair discussion... haven't thought enough about it to have a position for or against :) 16:13:17 and having a solid coverage and test results must be rewarded 16:13:20 Madhu: Agree... the question is smart ways to do it :) 16:13:21 with a cookie ;) 16:13:28 Chocolate chip? 16:13:37 edwarnicke: sorry, what is the autorelease topic? 16:14:10 LuisGomez: We have autorelease that are trying to do the weekly builds 16:14:17 and that we hope to use for the Helium Release 16:14:28 Currently, they include only the Hydrogen Projects 16:14:37 right 16:14:48 Additionally.. they will fail for reasons like version skew and other badness that is not obvious to the projects in isolation 16:14:53 So someone needs to: 16:15:03 1) Start bringing the new Helium projects in 16:15:18 2) Push fixes to them for the hygiene breakage 16:15:35 3) Make sure that when the dry runs on Thursdays break, that gets fixed by the projects on Friday 16:15:39 Does that make sense? 16:15:43 (its work... ) 16:16:01 who is in charge of all this? 16:16:06 Right now... no one 16:16:09 Which is why the ask 16:16:17 We need someone to take ownership of it 16:16:21 interesting :) 16:16:25 I will see if I can work on it 16:16:34 GiovanniMeo has been very helpful... but he doesn't have the cycles for it 16:16:45 gzhao__: How is your maven-fu ? :) 16:17:02 who is doing this for Hydrogen 16:17:22 LuisGomez: did i cover everything u wanted me to cover ? 16:17:26 gzhao__: GiovanniMeo was looking after it 16:17:28 #info PacketCable PCMM Thomas Kee 16:17:33 Madhu: sure 16:17:35 And regXboi and I were sort of helping 16:17:42 (for very liberal values of help ;) ) 16:17:57 and i have been supporting :) 16:18:03 moral support. lol 16:18:06 Madhu: :) 16:18:26 Madhu: They also serve who encourage :) 16:18:46 i really wish I can help on Helium auto releaase 16:18:59 gzhao__: Shall we action around getting you linked up with GiovanniMeo on this? 16:19:00 but M5 is going to be extremely challenging for us 16:19:07 Madhu: Me too... there's only so much time in the day 16:19:41 #info on the Test documentation front, i will append to the existing wiki. 16:19:48 LuisGomez: can u #action me on that ? 16:20:32 Madhu: When will you provide it by 16:20:33 ? 16:20:35 #action Madhu to publish java test documentation recommendations 16:21:31 asap :) 16:21:57 #info the test documentation recommendations are merely javadocs on the test cases 16:21:58 #action mlemay,madhu and luis to clean up PAX-EXAM documentation in general 16:22:53 #info the recommendations on test documentations will include Test plan (logical grouping) organization and Test case (individual @Test test-cases) organization and Javadocs for them 16:23:33 #info sonar will be the single source of truth for Code coverage, Test execution and Test Documentation. 16:23:34 LuisGomez: By when? 16:23:51 this week? 16:23:51 Madhu: Once we can get it working :) I have high hopes for your fixes :) 16:23:52 edwarnicke: don't we have Milestones just to track the when part ? 16:24:13 edwarnicke: it is working already and ovsdb-master sonar project is a living example :) 16:24:14 Madhu: If we have to wait for M5 for the helpful wiki page we may have a problem ;) 16:24:24 Madhu: Yep... hoping to emulate it :) 16:24:35 edwarnicke: fair enough and we are working on it. :) 16:25:01 highly recommend folks to please publish their UT/IT/Pax results to Sonar. 16:25:18 Madhu: We are all pulling in the same direction :0 16:25:20 :) 16:25:51 it is almost time 16:25:59 any other question? 16:26:14 gzhao__: Did we get you actioned on autorelease? 16:27:49 gzhao__, should we put you and action on you to investigate what is needed for autorelease? 16:27:58 edwarnick: on part of gzhao_, yes, we will do it. 16:28:23 Documentation is in red status, do all the project contacts provide document contacts to Paul 16:29:17 I have the project contacts, will be sending some new doc instructions out shortly 16:29:43 #action gzhao__ HelenYChen to pick up autorelease 16:29:44 LuisGomez, ok, I will work with GiovanniMeo 16:30:19 btw this is on M4 deliverable discussions ? or towards M5 ? 16:30:37 gzhao__: gzhao__ I sent an email introducing you 16:30:41 And setting the context 16:30:49 i have a question on how the project dependencies and missing the delivery deadlines are handled. 16:30:58 edwarnicke, thanks 16:31:14 gzhao__: Thank you :) 16:31:27 I can't tell you how happy it makes me that you are willing to pick this up 16:32:00 Madhu: go ahead with your question 16:33:48 if Project A is dependent on Project B's deliverable say in M4. and Project B missed M4 deadline 16:34:05 and Project A is completely blocked on that... how should we handle it ? 16:34:25 I believe if a project miss deadlines and deliveries, the community should help first and if this is not possible TSC is final responsble 16:34:28 Madhu: We work to fix it 16:34:32 Madhu: Hit me offline 16:34:33 its a possibility that Project A might and most certainly will slip M5 due to this... 16:34:34 LuisGomez, There are 2 projects API not frozen by M4, should we get a time set when it should be frozen 16:34:40 Madhu: I think I have a workaround for you 16:34:53 edwarnicke: it is not about me or ovsdb or openflowplugin :) 16:35:05 its a generic question that everyone should understand how to address such problems 16:35:09 OK :) Thought I have some good news there 16:35:19 Madhu: I would say the following minimally would be good practice 16:35:26 edwarnicke: it can be a good news ONLY if we can roll back 48 hrs 16:35:30 Project B need to communicate to Project A the situation 16:35:33 if u have a solution.. the entire world will be happy :) 16:35:47 And they need to work together to figure out the best thing they can 16:36:01 Madhu, Ed, do you really havea question here or you can fix this offline? 16:36:14 LuisGomez: the question is 16:36:30 if Project A is totally blocked by some other missing delivery 16:36:44 then should we extend the subsequent milestones for Project A alone 16:36:49 so that it has time to catch up ? 16:37:07 i like to honor the milestones to plan correctly 16:37:12 not do things willy nilly 16:37:40 Madhu: It depends on what you mean by honoring the Milestones 16:38:11 Madhu: If you mean "There are certain things like API freeze that the Simultaneous Release Plan puts at M4" thats doable 16:38:28 Madhu: But I don't magically know how to make things happen that haven't happened yet ;) 16:38:40 edwarnicke: thats exactly my question 16:38:52 anyways. i guess we have eaten up 10 more minutes 16:39:01 LuisGomez: if u want to call the meeting, am fine 16:39:04 lets take it to TSC 16:39:06 and get it resolved 16:39:16 i think project blocks should be reported to TSC who should make a decision 16:39:41 or recommendation at least 16:39:44 LuisGomez: A decision on what? 16:40:07 if a milestone needs to be moved for example 16:40:21 LuisGomez: I still haven't heard a crisp articulation of what is meant by 'Milestone should be moved' ? 16:40:59 we delayed the entire hydrogen last release 16:41:17 LuisGomez: I still haven't heard a crisp articulation of what is meant by "Milestone should be moved" 16:41:21 Could someone please provide one 16:41:23 LuisGomez: not just last releast.. we are doing it on stable/hydrogen as well 16:41:34 As its impossible to discuss the issue without it 16:41:44 edwarnicke: lets take it to TSC 16:41:47 to get a better voice 16:41:50 Madhu: Take what to the TSC? 16:41:55 I literally don't know what the question is 16:41:57 i have to run guys 16:42:00 And that's germaine 16:42:06 edwarnicke: u know the question... but i have to run now. 16:42:06 bye 16:42:12 Madhu: No I don't 16:42:19 You have not been clear about it 16:45:02 Ed, I think the question is how do we handle situation when a project gets blocked by another 16:45:12 maybe this has not happened yet 16:45:26 but I do not know the answer anyway 16:45:41 LuisGomez: OK... rereading I think I see Madhu's question 16:46:08 will write on OF plugin my interpretation of Madhu’squestion 16:46:18 Madhu: Where you asking about whether subsequent milestones should be moved (ie... move M5) for a particular project alone (just trying to understand the question, not suggesting thats a good idea) 16:46:24 as it is specific to OF plugin / OVSDB 16:47:12 Madhu is gone i think 16:47:46 anyway, should we close the meeting? 16:47:49 LuisGomez: Basically though... we have two kinds of things at Milestones: Requirements from the TSC (like API freeze) and a projects own plans ( deliverables ) 16:48:06 Holding the line on TSC requirements is a TSC thing 16:48:15 But I don't know what it can do about planned release deliverables 16:49:10 LuisGomez, I still need Helium M4 status from 5 projects. 16:49:29 Ed, my understanding is TSC is final responsible for simoultaneous release 16:50:08 so in the end, they can recommend the best way out in a block situation if it does not resolve by itself 16:50:14 LuisGomez: Setting mechanical requirements, yes 16:50:46 But there's literally nothing it can do other than distract on delivering actual code 16:50:55 It can say 'Don't change APIs going forward' 16:50:57 And that's good 16:51:05 But it can't magically make code appear 16:51:17 It can distract the folks who are writing code from writing code with politics 16:51:21 But it can't make code appear 16:51:34 thats true 16:51:54 So mechanical items like the M4 API Freez 16:51:58 That it can do something with 16:54:54 ok, i believe Madhu will rise his question next TSC call so we can have more discussion there 16:55:01 anything else? 16:55:37 gzhao__, have you reached the projects with no status? 16:55:56 I will follow up 16:56:28 for those they have not frozen API please ask them when 16:57:06 LuisGomez, will put that on my action list 16:57:32 #action gzhao__ to pursue projects with no status 16:57:58 ok, can we close the meeting now? 16:59:12 thanks everybody, we meet again next week 16:59:21 thanks, Luis 16:59:21 #endmeeting