16:00:55 <sambetts> #startmeeting networking_cisco
16:00:56 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:59 <openstack> The meeting name has been set to 'networking_cisco'
16:01:38 <pc_m> o/
16:01:47 <sambetts> The agenda for today can be found
16:01:51 <caboucha> carol here
16:01:52 <sambetts> #link https://wiki.openstack.org/wiki/Meetings/networking-cisco
16:01:54 <tbachman> sambetts: hi!
16:02:03 <bradjones> o/
16:02:37 <sambetts> 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 <sambetts> #topic Roll call
16:02:47 <caboucha> o/
16:02:53 <pc_m> o/
16:02:55 <sambetts> o/
16:03:16 <bradjones> o/
16:04:41 <sambetts> Ok, I can see tbachman is here too, so lets move on
16:04:48 <sambetts> #topic Announcements
16:05:49 * tbachman wonders if his IRC is still live
16:05:56 <sambetts> 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 <sambetts> 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 <sambetts> tbachman: http://paste.openstack.org/show/585353/
16:07:37 <tbachman> sambetts: thx!
16:08:31 <sambetts> 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 <sambetts> 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 <sambetts> but I'll go into that further in the CI status topic
16:10:24 * tbachman gives a cheer
16:10:46 <sambetts> are there any other annoucements people have??
16:11:14 <bradjones> not from me
16:11:37 <sambetts> Okie doke, moving onto the next topic
16:11:42 <sambetts> #topic CI status
16:12:06 <sambetts> So like I said Cisco CI is now back up and running \o/
16:12:28 <tbachman> sambetts: congrats, and thanks for all the hard work chasing that (and people) down!
16:12:49 * pc_m yay
16:12:51 <sambetts> 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 <caboucha> agreed Sam did an outstanding job
16:12:59 <tbachman> nice!
16:13:16 <shwetaap> yea, Thanks Sam!
16:13:46 <sambetts> 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 <sambetts> so I think that needs further investigation so please disregard failures caused by that in the pnr-ncs job
16:14:52 <bradjones> sambetts: is that only for the stable newton tests?
16:15:03 <sambetts> it seems like it
16:15:14 <bradjones> ok
16:16:05 <sambetts> 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 <sambetts> pc_m: or just poor coding ;)
16:16:37 <bradjones> sambetts: you beat me to it ;)
16:16:43 * tbachman looks down at the ground, kicks rock
16:16:45 <pc_m> Well, it seems to be running, but for some patches it is timing out.
16:17:06 <pc_m> We need to request a longer run time, not sure how much more time we need.
16:17:18 <sambetts> ok, so we still need to persude infra to bump the timeout on that test, and maybe move it to experimental
16:17:38 <pc_m> Would be good with someone that has a good relationship with infra to get more time.
16:17:42 <pc_m> sambetts: yes
16:17:53 <pc_m> then, later can be put back to check queue.
16:17:53 <tbachman> pc_m: didn’t sdake offer to help with this?
16:18:02 <tbachman> or at least connect folks?
16:18:03 <pc_m> tbachman: yes.
16:18:12 <pc_m> I can ping him.
16:18:18 <sambetts> 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 <pc_m> We also need to (strongly) encourage people to run coverage locally, and ensure we don't make things worse.
16:18:56 <pc_m> 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 <sambetts> its something we all need to get better at heh
16:19:51 <pc_m> Yes, or we make the job voting, but that can be painful. Self policing would be better.
16:20:10 <sambetts> 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 <tbachman> 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 <pc_m> sambetts: Right now, it does a comparison based test. Runs on baseline, then on changeset and compares.
16:21:23 <pc_m> Difficulty is people can be adding/changing/deleting code.
16:21:24 * tbachman waves to SridarK
16:21:33 <SridarK> Hi all
16:21:41 <sambetts> o/ SridarK
16:22:25 <pc_m> 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 <pc_m> sorry, in cover.bash script in repo.
16:23:14 <pc_m> So, if a commit has more than 4 missing lines than previous run, it says the test fails.
16:23:15 <tbachman> 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 <tbachman> pc_m: I still have to try that idea on fixing testing of methods that use “pass"
16:23:57 <pc_m> Not great, as one can game it.
16:24:21 <pc_m> tbachman: Yes, would like to see if that pragma works. Should.
16:24:36 <tbachman> sometimes 100% also can be a bit cookoo. Testing a getter seems unnecessary, imho
16:24:58 <tbachman> pc_m: will try it
16:25:07 <sambetts> 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 <pc_m> 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 <tbachman> pc_m: cool
16:26:23 <pc_m> It won't complain that we haven't added coverage to the 20% of getters.
16:26:45 <pc_m> So it is a measure of if we are getting better or worse on a commit by commit basis.
16:26:52 <SridarK> sambetts: with the methods with just pass - we have this pattern on mixins that we inherit from too
16:27:23 <pc_m> Not my idea, was some script developed for another repo - I just ported it for networking-cisco.
16:27:26 <sambetts> SridarK: as in mixins that are "abstract classes" ?
16:27:39 <SridarK> pc_m: could the coverage - reflect a percentage rather than a pass or fail ?
16:27:51 <SridarK> sambetts: yes
16:28:32 <pc_m> 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 <sambetts> SridarK: ah, yes thats a harder case to test for
16:29:30 <sambetts> SridarK: unless you raise a NotImplemented error or something
16:29:39 <sambetts> SridarK: but there are still some edge cases
16:29:59 <tbachman> whatever we do, it won’t be perfect
16:30:04 <tbachman> but should cover the main use cases
16:30:07 <SridarK> sambetts: with respect to coverage - we should get less anal on some of these
16:30:40 <pc_m> SridarK: I think the current system does that. It is only detecting if coverage is getting better or worse.
16:30:49 <SridarK> tbachman: +1 yes and as u said earlier going for the 100% is not worth the effort
16:31:38 <SridarK> 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 <pc_m> 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 <sambetts> SridarK: correct
16:32:24 <pc_m> SridarK: not based on percentage, which is tough to measure.
16:32:31 <sambetts> 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 <pc_m> Based on # lines missing coverage, specifically the delta.
16:32:55 <SridarK> pc_m: ok makes sense
16:33:04 <sambetts> #action Submit patch to project-config to increase timeout on coverage job
16:33:12 <SridarK> sambetts: yes sorry lets move on
16:33:19 <pc_m> sambetts: Yes. #1 to get time increase. #2 getting people to pay attention to results.
16:33:37 <sambetts> ok awesome :)
16:33:47 <sambetts> #topic Sub/Driver team feedback
16:34:27 <sambetts> 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 <sambetts> so I'll pass the mic to you guys
16:35:32 <SridarK> 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 <sambetts> not really, ideally we need to put together one
16:36:36 <SridarK> 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 <SridarK> tbachman: i think u may have more updates on the L3 stuff from ur side as well
16:37:02 <caboucha> For Nexus Driver, only changes recently is refactor unit tests.
16:37:31 <tbachman> I’ve got a few more patches in the queue
16:37:38 <tbachman> I still need to provide updates for them
16:37:50 <tbachman> that said, I’ve been pulled onto a higher priority project for the week :(
16:37:57 <tbachman> hopefully I’ll be able to get back to the patches soon
16:38:04 <tbachman> but likely not before the 4.0.0 release
16:38:13 <sdake> pc_m what do you need?
16:39:07 <pc_m> sdake: Will chat after meeting.
16:39:10 <sambetts> 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 <sdake> pc_m roger
16:39:30 <tbachman> sambetts: sounds good. Do you have any thoughts on the time frame for 4.1.0?
16:39:55 <SridarK> 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 <sambetts> tbachman: your deadline is still the 15th right? or has that changed?
16:40:31 <tbachman> 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 <tbachman> 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 <SridarK> sambetts: would it be 4.0.x for the maintenance release ?
16:41:30 <tbachman> 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 <sambetts> SridarK: 4.1.0, unless everything in it is bug fixes
16:41:55 <tbachman> (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 <SridarK> sambetts: ok thx
16:43:51 <sambetts> tbachman: do you have any requirement on being included in the RedHat platform release for Newton?
16:44:52 <sambetts> 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 <tbachman> sambetts: I’d have to check on that
16:45:11 <tbachman> and good question
16:45:35 <tbachman> sambetts: will that be with the 4.0.0 release?
16:46:01 <sambetts> if we can get enough merged in time I'd like it to be the 4.1.0 release
16:46:16 <tbachman> sambetts: things should be better towards the end of this week
16:46:18 <sambetts> 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 <sambetts> ok, so on that note it brings us nicly onto
16:47:43 <sambetts> #topic Review Priorities
16:49:22 <sambetts> Ok, so I'd like to use this section to highlight reviews to focus on
16:50:04 <sambetts> 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 <sambetts> right now this is what I've got so far:
16:51:38 <sambetts> 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 <sambetts> 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 <sambetts> it%3A10
16:51:52 <sambetts> ah... that didn't work very well
16:52:00 <pc_m> shorten url...
16:52:05 <sambetts> https://goo.gl/8NwEhm
16:52:09 <pc_m> thanks
16:52:41 <sambetts> there are some issues and I have some other sections I want to add like, top 10 most recently approved patches
16:53:12 <sambetts> but it should allow us a cleaner view of what is ready for review and want isn't
16:54:48 <sambetts> 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 <sambetts> as well as what you can see on that dashboard
16:56:40 <sambetts> 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 <sambetts> so just need a rebase or recheck, and to see if they are still relevent
16:57:50 <sambetts> s/so/some
16:58:04 <sambetts> As we have 3 minutes left I'll going to move on
16:58:19 <sambetts> #topic Open Discussion
16:58:53 <sambetts> 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 <sambetts> 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 <sambetts> Thanks everyone for coming
17:00:55 <tbachman> sambetts: thanks!
17:01:06 <sambetts> see you in 2 weeks, same time, same channel
17:01:11 <sambetts> #endmeeting