16:00:55 #startmeeting networking_cisco 16:00:56 Meeting started Tue Oct 11 16:00:55 2016 UTC and is due to finish in 60 minutes. The chair is sambetts. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:59 The meeting name has been set to 'networking_cisco' 16:01:38 o/ 16:01:47 The agenda for today can be found 16:01:51 carol here 16:01:52 #link https://wiki.openstack.org/wiki/Meetings/networking-cisco 16:01:54 sambetts: hi! 16:02:03 o/ 16:02:37 the first thing I'm going to do is a roll call so if everyone here can response with a "o/" then it'll give us a record of the attendees 16:02:47 #topic Roll call 16:02:47 o/ 16:02:53 o/ 16:02:55 o/ 16:03:16 o/ 16:04:41 Ok, I can see tbachman is here too, so lets move on 16:04:48 #topic Announcements 16:05:49 * tbachman wonders if his IRC is still live 16:05:56 The biggest annouchment I think is that we are very close to cutting release 4.0.0, we had intended to release last week, but due to CI being down and wanting to get a couple of last patches in we've pushed back 16:06:40 I hope to push the last couple of patches in today if we can, I'll talk more about those in the review priorities topic 16:06:52 * tbachman wonders what he missed (CVO decided to hiccup) 16:07:22 tbachman: http://paste.openstack.org/show/585353/ 16:07:37 sambetts: thx! 16:08:31 The plan now is to release a 4.0.0 release ASAP and follow up with a 4.1.0 release with any further enhancments we want to get in, but releasing the 4.0.0 release gives us something to fall back to and means the finished drivers are out there ready to be used 16:10:06 The only other annouchment is that the Cisco CI is back up and posting results as of end of last week/beginning of this week 16:10:21 but I'll go into that further in the CI status topic 16:10:24 * tbachman gives a cheer 16:10:46 are there any other annoucements people have?? 16:11:14 not from me 16:11:37 Okie doke, moving onto the next topic 16:11:42 #topic CI status 16:12:06 So like I said Cisco CI is now back up and running \o/ 16:12:28 sambetts: congrats, and thanks for all the hard work chasing that (and people) down! 16:12:49 * pc_m yay 16:12:51 after the network and other testbed issues resolved we're seeing a good turn around on patches in around 30mins per patch :D 16:12:59 agreed Sam did an outstanding job 16:12:59 nice! 16:13:16 yea, Thanks Sam! 16:13:46 there seems to be only one hicup with the CI job for pnr-ncs, which I don't know if its a code issue or testbed issue, but I see seg faults which is weird for python code 16:14:39 so I think that needs further investigation so please disregard failures caused by that in the pnr-ncs job 16:14:52 sambetts: is that only for the stable newton tests? 16:15:03 it seems like it 16:15:14 ok 16:16:05 pc_m: any updates regarding the coverage job? I see that it is failing in most if not all patches, is it still because of the timeout issue? 16:16:25 pc_m: or just poor coding ;) 16:16:37 sambetts: you beat me to it ;) 16:16:43 * tbachman looks down at the ground, kicks rock 16:16:45 Well, it seems to be running, but for some patches it is timing out. 16:17:06 We need to request a longer run time, not sure how much more time we need. 16:17:18 ok, so we still need to persude infra to bump the timeout on that test, and maybe move it to experimental 16:17:38 Would be good with someone that has a good relationship with infra to get more time. 16:17:42 sambetts: yes 16:17:53 then, later can be put back to check queue. 16:17:53 pc_m: didn’t sdake offer to help with this? 16:18:02 or at least connect folks? 16:18:03 tbachman: yes. 16:18:12 I can ping him. 16:18:18 I can push on that if not, I've had quite a bit of experience with them working on refactoring the Ironic CI jobs 16:18:38 We also need to (strongly) encourage people to run coverage locally, and ensure we don't make things worse. 16:18:56 It works locally, since the recent fixes. 16:18:57 * tbachman again looks down at the ground, kicks rock with foot 16:19:04 * pc_m :) 16:19:19 its something we all need to get better at heh 16:19:51 Yes, or we make the job voting, but that can be painful. Self policing would be better. 16:20:10 pc_m: is there a way with the coverage job to make it focus only on the files/tests changed by a patch so as to reduce the run time? 16:20:12 one thing — is a number instead of a percent the right way to qualify this? 16:20:22 * tbachman isn’t even sure if a percent is doable…. just thinking out loud 16:20:58 sambetts: Right now, it does a comparison based test. Runs on baseline, then on changeset and compares. 16:21:23 Difficulty is people can be adding/changing/deleting code. 16:21:24 * tbachman waves to SridarK 16:21:33 Hi all 16:21:41 o/ SridarK 16:22:25 There is a missing coverage count limit that determines if pass/fail. Set to 4 lines right now, but could be changed in project-config. 16:22:36 sorry, in cover.bash script in repo. 16:23:14 So, if a commit has more than 4 missing lines than previous run, it says the test fails. 16:23:15 not saying that 4 lines isn’t the right thing (or 0 lines for that matter). Just throwing something out there. There are also sometimes issues I’ve seen with what it says is covered 16:23:43 pc_m: I still have to try that idea on fixing testing of methods that use “pass" 16:23:57 Not great, as one can game it. 16:24:21 tbachman: Yes, would like to see if that pragma works. Should. 16:24:36 sometimes 100% also can be a bit cookoo. Testing a getter seems unnecessary, imho 16:24:58 pc_m: will try it 16:25:07 my personal stance on the functions that just have pass in them, is that they are probably there because they are disabling some code that is inherited from the parent class, if that is the case we should have a UT to make sure that the parent code is being disabled 16:25:32 tbachman: Yeah, that's why I like the comparison. If we have 80% coverage (the 20% being getters), and we add code, it'll catch the missing coverage. 16:26:10 pc_m: cool 16:26:23 It won't complain that we haven't added coverage to the 20% of getters. 16:26:45 So it is a measure of if we are getting better or worse on a commit by commit basis. 16:26:52 sambetts: with the methods with just pass - we have this pattern on mixins that we inherit from too 16:27:23 Not my idea, was some script developed for another repo - I just ported it for networking-cisco. 16:27:26 SridarK: as in mixins that are "abstract classes" ? 16:27:39 pc_m: could the coverage - reflect a percentage rather than a pass or fail ? 16:27:51 sambetts: yes 16:28:32 The report will show percentage for baseline and changeset, but the test pass/fail indication is based on the # lines. To work with the job infrastructure. 16:29:11 SridarK: ah, yes thats a harder case to test for 16:29:30 SridarK: unless you raise a NotImplemented error or something 16:29:39 SridarK: but there are still some edge cases 16:29:59 whatever we do, it won’t be perfect 16:30:04 but should cover the main use cases 16:30:07 sambetts: with respect to coverage - we should get less anal on some of these 16:30:40 SridarK: I think the current system does that. It is only detecting if coverage is getting better or worse. 16:30:49 tbachman: +1 yes and as u said earlier going for the 100% is not worth the effort 16:31:38 pc_m: ok got it - so if we stay the same level of coverage percentage or get better - we will pass the test ? 16:31:52 IOW, if overall coverage is 80% with 2000 missing lines, and it goes to 2010 missing lines, then we know we didn't cover new/changed code. 16:32:08 SridarK: correct 16:32:24 SridarK: not based on percentage, which is tough to measure. 16:32:31 so without bikeshedding to much here, I think we can improve the coverage testing itself over time, but for now we need to push to get the existing job passing and failing consitently 16:32:45 Based on # lines missing coverage, specifically the delta. 16:32:55 pc_m: ok makes sense 16:33:04 #action Submit patch to project-config to increase timeout on coverage job 16:33:12 sambetts: yes sorry lets move on 16:33:19 sambetts: Yes. #1 to get time increase. #2 getting people to pay attention to results. 16:33:37 ok awesome :) 16:33:47 #topic Sub/Driver team feedback 16:34:27 So I added this topic as a chance for the individual driver/dev teams to give an update or feedback on whats going on with their plugin 16:35:22 so I'll pass the mic to you guys 16:35:32 I dont see Bob M around 16:36:11 * tbachman wonders if we have a list of all the driver/dev teams 16:36:31 not really, ideally we need to put together one 16:36:36 i can do a quick update on the L3 stuff - Bob & Shweta have been working thru the UT issues and i believe they are done with them, there are some issues on scale that i just started looking into along with Bob & Shweta 16:36:58 tbachman: i think u may have more updates on the L3 stuff from ur side as well 16:37:02 For Nexus Driver, only changes recently is refactor unit tests. 16:37:31 I’ve got a few more patches in the queue 16:37:38 I still need to provide updates for them 16:37:50 that said, I’ve been pulled onto a higher priority project for the week :( 16:37:57 hopefully I’ll be able to get back to the patches soon 16:38:04 but likely not before the 4.0.0 release 16:38:13 pc_m what do you need? 16:39:07 sdake: Will chat after meeting. 16:39:10 tbachman: ok, we'll push in what we can, your ok with us cutting a 4.0.0 release without all your patches in, we'll follow up with a 4.1.0 pretty soon 16:39:15 pc_m roger 16:39:30 sambetts: sounds good. Do you have any thoughts on the time frame for 4.1.0? 16:39:55 There has been a set of patches from the DFA folks to enable FWaaS with their fabric - these patches all just merged recently 16:40:09 tbachman: your deadline is still the 15th right? or has that changed? 16:40:31 sambetts: ack. But we’re releasing from our fork for this one, since they aren’t all going to be in there 16:41:03 we have a maintenance release (usually about 2 weeks afterwards), which is when I was thinking of cutting over, if things work out that way 16:41:27 sambetts: would it be 4.0.x for the maintenance release ? 16:41:30 sambetts: keep in mind — as long as I can get this stuff in upstream, we can create our own release artifacts (for now) 16:41:48 SridarK: 4.1.0, unless everything in it is bug fixes 16:41:55 (i.e. tho it would be nice to be part of the networking-cisco release, it’s not a requirement for us) 16:42:21 sambetts: ok thx 16:43:51 tbachman: do you have any requirement on being included in the RedHat platform release for Newton? 16:44:52 tbachman: I believe the deadline for getting our networking-cisco RPMs built for that release the 21st, anything after than will need to wait for a OSP maintainence update 16:44:56 sambetts: I’d have to check on that 16:45:11 and good question 16:45:35 sambetts: will that be with the 4.0.0 release? 16:46:01 if we can get enough merged in time I'd like it to be the 4.1.0 release 16:46:16 sambetts: things should be better towards the end of this week 16:46:18 but I want to get the 4.0.0 release done ASAP as something to fall back to 16:46:27 * tbachman has said things like that before, tho :P 16:47:38 ok, so on that note it brings us nicly onto 16:47:43 #topic Review Priorities 16:49:22 Ok, so I'd like to use this section to highlight reviews to focus on 16:50:04 I have been working on a gerrit dashboard that'll allow us a nicer view of the patches and their statuses for networking-cisco 16:51:34 right now this is what I've got so far: 16:51:38 https://review.openstack.org/#/dashboard/?foreach=project%3Aopenstack%2Fnetworking%2Dcisco+status%3Aopen&title=Networking%2DCisco+Reviews&Needs+Approval=NOT+label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Cjenkins+NOT+owner%3Aself+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%2D1&Needs+Reverify=label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D%2D1+lab 16:51:44 el%3AVerified%3C%3D%2D1%2Cjenkins&No+Negative+Feedback+%28top+10%29=NOT+label%3AWorkflow%3E%3D1+NOT+label%3AWorkflow%3C%3D%2D1+label%3AVerified%3E%3D1%2Cjenkins+NOT+owner%3Aself+NOT+label%3ACode%2DReview%3C%3D%2D1+NOT+label%3ACode%2DReview%3E%3D2+limit%3A10&Everything+else%2C+Not+WIP+%28top+10%29=NOT+label%3ACode%2DReview%3E%3D2+NOT+label%3ACode%2DReview%2D2+NOT+label%3AWorkflow%3C%3D%2D1+lim 16:51:50 it%3A10 16:51:52 ah... that didn't work very well 16:52:00 shorten url... 16:52:05 https://goo.gl/8NwEhm 16:52:09 thanks 16:52:41 there are some issues and I have some other sections I want to add like, top 10 most recently approved patches 16:53:12 but it should allow us a cleaner view of what is ready for review and want isn't 16:54:48 For me the reviews I'd like to focus on are tbachman's ASR + ACI patches as they are the thing we need to merge ASAP to get them into the 4.1.0 release 16:55:18 * tbachman owes some updates to some of those patches 16:55:52 as well as what you can see on that dashboard 16:56:40 there are a large number of WIP patches and older patches with a lot of negative feedback I'd like to clean up 16:57:28 so just need a rebase or recheck, and to see if they are still relevent 16:57:50 s/so/some 16:58:04 As we have 3 minutes left I'll going to move on 16:58:19 #topic Open Discussion 16:58:53 Any one got any thing they want to cover here? OR Any thing that they would like added to the agenda for the meeting in 2 weeks time? 16:59:27 Btw feel free to update https://wiki.openstack.org/wiki/Meetings/networking-cisco yourself if you think of anything to add in the meantime 17:00:53 Thanks everyone for coming 17:00:55 sambetts: thanks! 17:01:06 see you in 2 weeks, same time, same channel 17:01:11 #endmeeting