14:00:25 <mestery> #startmeeting networking
14:00:26 <openstack> Meeting started Tue Aug 11 14:00:25 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'networking'
14:00:38 <regXboi> moo
14:00:43 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:00 <mestery> Lots of bugs to discuss today, some Liberty-3 items as well
14:01:03 <mestery> So, lets get rolling
14:01:12 <mestery> #topic Announcements
14:01:16 <mestery> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
14:01:21 <mestery> Liberty-3 is 3 weeks away
14:01:24 <obondarev> hi
14:01:27 <mestery> Thus, the FF is 3 weeks away
14:01:34 <mestery> #info Liberty-3 and the FF are 3 weeks away
14:01:51 <mestery> #link https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Liberty_Release_Notes
14:01:55 <salv-orl_> aloha
14:02:06 <mestery> #info Liberty Release Notes can begin to be populated for things which have already landed
14:02:26 <mestery> It's going to be a long 3 weeks I suspect :)
14:02:34 <mestery> Or a fast 3 weeks
14:02:41 <regXboi> I vote for #2
14:02:45 <mestery> Any other announcements anyone wants to share with the team?
14:03:09 <regXboi> we've got convergence on the multinode DVR job in the pipeline
14:03:14 * regXboi is dancing
14:03:17 <mestery> \o/
14:03:18 <mestery> yay!
14:03:20 <regXboi> #link http://goo.gl/EAugSi
14:03:35 <mestery> #info The multinode DVR job has converged with the single node DVR job
14:03:46 <mestery> regXboi: Is the plan to propose a patch to remove the single node DVR job later this week?
14:04:03 <regXboi> mestery: yes - I'm planning that for Friday am, if all goes well
14:04:12 <dougwig> O/
14:04:15 <regXboi> mestery: and make the multinode voting
14:04:17 <mestery> regXboi: Excellent, thanks for jumping in on DVR!
14:04:26 * mestery teases dougwig with a red bull
14:04:42 <mestery> OK, lets move on in the agenda now
14:04:46 <mestery> #topic Bugs
14:04:49 <mestery> First up:
14:04:56 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1477192
14:04:56 <openstack> Launchpad bug 1477192 in neutron "neutron test_multi_prefix_slaac failing in the gate with ping failures starting around 7/22" [High,Confirmed] - Assigned to Henry Gessau (gessau)
14:04:56 <uvirtbot> Launchpad bug 1477192 in neutron "neutron test_multi_prefix_slaac failing in the gate with ping failures starting around 7/22" [High,Confirmed]
14:04:57 <uvirtbot> Launchpad bug 1477192 in neutron "neutron test_multi_prefix_slaac failing in the gate with ping failures starting around 7/22" [High,Confirmed] https://launchpad.net/bugs/1477192
14:05:27 <mestery> HenryG: I assigned this one to you to have an IPv6 minion examine further. Ack if that sounds manageable.
14:05:50 <ihrachyshka> late o/
14:06:29 <HenryG> ack
14:06:34 <mestery> Thanks HenryG
14:06:35 <mestery> Next up
14:06:38 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1461172
14:06:38 <openstack> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed]
14:06:38 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed]
14:06:40 <uvirtbot> Launchpad bug 1461172 in neutron "neutron.tests.functional.agent.test_l3_agent.MetadataL3AgentTestCase.test_access_to_metadata_proxy times out intermittently" [High,Confirmed] https://launchpad.net/bugs/1461172
14:06:58 <mestery> This one looks to have 21 failures from the logstash query in the description
14:07:22 <mestery> I'll assign this to the L3 team for further triage unless someone wants in on it
14:07:22 <amuller> mestery: if you look at https://bugs.launchpad.net/neutron/+bugs?field.tag=functional-tests
14:07:43 <amuller> we currently have 4 bugs reported on 4 different tests in the functional job failing every so often
14:07:52 <amuller> each individual test doesn't have a high failure rate
14:07:53 <mestery> amuller: Ack on that
14:07:57 <mestery> Correct
14:08:07 <amuller> but the 4 combined...
14:08:25 <mestery> That's where the fun starts amuller, math always makes things fun ;)
14:08:35 <amuller> I'd appreciate anyone picking up any of those 4
14:08:36 <mlavalle> mestery: we'll llok at this bug in the L3 team
14:08:42 <mlavalle> look^^^^
14:08:48 <mestery> mlavalle: Thanks mlavalle
14:08:59 <mestery> OK, next up
14:09:04 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1439696
14:09:05 <openstack> Launchpad bug 1439696 in neutron "Referencing a lb-healthmonitor ID for the first time from Heat would fail" [High,Confirmed]
14:09:11 <uvirtbot> Launchpad bug 1439696 in neutron "Referencing a lb-healthmonitor ID for the first time from Heat would fail" [High,Confirmed]
14:09:12 <uvirtbot> Launchpad bug 1439696 in neutron "Referencing a lb-healthmonitor ID for the first time from Heat would fail" [High,Confirmed] https://launchpad.net/bugs/1439696
14:09:22 <mestery> dougwig: This looks like an LBaaS V1 bug to me, I think you concurred in the bug
14:09:42 <mestery> dougwig: Given we have to keep LBaaS around for Liberty before removing it in Mitaka, I suspect this one needs a patch.
14:10:17 <dougwig> mestery: ok, i'll find someone to look at this one. no status update now.
14:10:28 <mestery> dougwig: Yup, sounds good, thanks.
14:10:42 <mestery> Next up
14:10:44 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1404743
14:10:44 <openstack> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed]
14:10:44 <uvirtbot> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed]
14:10:46 <uvirtbot> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed] https://launchpad.net/bugs/1404743
14:11:02 <dougwig> lb or ovs?
14:11:07 <mestery> This one has a large number of hits using the logstash query provided (475 last time I looked)
14:12:28 <mestery> dougwig: OVS
14:12:50 <mestery> Next up
14:12:59 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1378732
14:12:59 <openstack> Launchpad bug 1378732 in neutron "migrate_to_ml2 script doesn't work for Juno release" [High,Confirmed] - Assigned to Mark McClain (markmcclain)
14:13:01 <uvirtbot> Launchpad bug 1378732 in neutron "migrate_to_ml2 script doesn't work for Juno release" [High,Confirmed]
14:13:02 <uvirtbot> Launchpad bug 1378732 in neutron "migrate_to_ml2 script doesn't work for Juno release" [High,Confirmed] https://launchpad.net/bugs/1378732
14:13:38 <mestery> markmcclain: From the trail in the bug, it's unclear if this one is still relevant. If you get a moment, can you eyeball and update please?
14:14:05 <mestery> And finally we have
14:14:07 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1163569
14:14:07 <openstack> Launchpad bug 1163569 in OpenStack Security Notes "security groups don't work with vip and ovs plugin" [High,In progress] - Assigned to Steven Weston (steve.weston)
14:14:13 <mestery> dougwig: Another LBaaS V1 bug for triaging :)
14:14:13 <uvirtbot> Launchpad bug 1163569 in ossn "security groups don't work with vip and ovs plugin" [High,In progress] https://launchpad.net/bugs/1163569
14:14:14 <uvirtbot> Launchpad bug 1163569 in ossn "security groups don't work with vip and ovs plugin" [High,In progress]
14:14:15 <mestery> It's your lucky day
14:14:41 <dougwig> aye. is this a feature by design, or a simple oversight when it was first implemented?
14:14:45 <salv-orl_> mestery: this is so old my hairs were still brown when it was filed
14:15:00 <mestery> salv-orl_: Heh :)
14:15:12 <mestery> dougwig: Unsure, it's possible we mark this as Incomplete for now.
14:15:16 <mestery> dougwig: Lets circle back post meeting on this one.
14:15:17 <salv-orl_> definetely lbass v1
14:15:36 <mestery> That's all I had for High priority bugs not currently "In Progress"
14:15:43 <dougwig> this one is tricky, since third party drivers might run afoul of the iptables rules we'd add.
14:15:43 <dougwig> ok.
14:15:52 <mestery> Yup
14:16:12 * mestery doesn't see emagana or Sam-I-Am so skips a doc update
14:16:22 <mlavalle> mestery: did you assign https://bugs.launchpad.net/neutron/+bug/1404743 to someone?
14:16:22 <openstack> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed]
14:16:24 <uvirtbot> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed] https://launchpad.net/bugs/1404743
14:16:25 <uvirtbot> Launchpad bug 1404743 in neutron "sporadic test failures due to VMs not getting a DHCP lease" [High,Confirmed]
14:16:34 <mestery> mlavalle: I did not, are you up for that one?
14:16:51 <mlavalle> mestery: we are looking at it in the l3 team
14:16:53 <regXboi> mestery: there is another bug in the offing relating to SSH failures - let me try and dig up the logstash query and file it
14:17:04 <mestery> regXboi: Thanks
14:17:06 <mestery> mlavalle: Sounds good!
14:17:14 <salv-orl_> btw, that's not as critical as it seems. Failure occur in bursts. so you have a lot of hits on the same job
14:17:18 <mlavalle> mestery: I will change the tag, same for the other one you gave us
14:17:27 <mestery> mlavalle: Thanks
14:17:41 <mestery> salv-orl_: Your wisdom is, as always, most welcome :D
14:18:12 <mestery> OK, lets keep things moving
14:18:30 <mestery> #topic Why Third-Party CI Systems Should Not Be Allowed To Vote -1 (e.g. the section of the meeting most likely to lead to Bike Shedding)
14:18:37 <mestery> #link https://review.openstack.org/207198
14:18:58 * dougwig gets out his rollers.
14:19:06 <mestery> I know armax has some issues with my strong language here, which I'm fine fixing, but who wants to defend voting -1 from third-party CI systems?
14:19:27 <salv-orl_> mestery: I stopped voting with my CI for a while now
14:19:31 <dougwig> i will. a -1 from a reliable 3rd party CI is a useful thing, as it affects query filters.
14:19:33 * mestery hugs salv-orl_
14:19:39 <dougwig> that said, i don't vote -1 either.
14:19:45 <salv-orl_> nobody looks at that vote unless it's a -1. If that's an honest -1 they ignore it
14:19:53 <xgerman> we might want that in Octavia with our Sonar thing
14:19:58 <salv-orl_> if it's a ci issue they bark
14:20:25 <xgerman> it’s not like official OpenStack tooling has a lot of static code analysis tools
14:20:35 <salv-orl_> I need my CI to know when something breaks our plugins. Not to warn other developers that they're breaking my plugin.
14:20:44 <mestery> Yup
14:21:05 <dougwig> i'd like folks to see if they're making a backwards incompatible change.  not to have all 20 plugin maintainers play constant catchup.
14:21:14 <salv-orl_> still, if people working on the reference control plane would keep in mind the DB classes are meant to be purely mgmt plane, that would be great
14:21:32 * salv-orl_ rant over
14:21:42 <mestery> I'm honestly agnostic to this change, but that's my take on third-party CI in general.
14:21:58 <mestery> I won't repeat my rant from the summit on this topic, mostly to spare the handful of people paying attention here
14:22:01 <mestery> OK
14:22:04 <anteaya> xgerman: we are open to building openstack tooling that meets code analysis needs
14:22:14 <anteaya> if someone is willing to offer the spec and build it
14:22:23 <anteaya> we will offer reviews
14:22:49 <dougwig> anteaya: i think they're using a proprietary tool to do the analysis.
14:22:57 <mestery> bleah!
14:22:57 <dougwig> does that still work?
14:23:01 <xgerman> it’s open source - ish
14:23:04 <mestery> ish?
14:23:05 <anteaya> I have no interest in propietary toolking
14:23:12 <ajo> anteaya (offtopic) a python code indexer like linux cross ref project would also be amazing for openstack too ;)
14:23:21 <dougwig> anteaya: that was my guess. :)
14:23:23 <anteaya> well it has to be open scource to be considered openstack infra tooling
14:23:31 <anteaya> dougwig: okay thanks
14:23:46 <mestery> Folks, I'd just like to close on this "third party CI voting"
14:23:47 <xgerman> #link http://15.126.130.201/sonar/
14:23:51 <johnsom> We are trying out sonarqube which is LGPLv3
14:23:53 <anteaya> ajo: I have no argument, spec, agreement, build
14:23:53 <mestery> I didn't see anyone other than dougwig jump in to defend it
14:24:04 <dougwig> it is 8am, who else is here? :)
14:24:10 <xgerman> 7 am
14:24:20 <mestery> I guess I'll reference the meeting in the review since, per usual, this meeting has low attendance /cc dougwig
14:24:42 <mestery> Lets move along
14:24:43 <mestery> #topic Liberty-3 BPs and Specs
14:24:51 <mestery> 3 weeks left
14:24:53 <mestery> #link https://launchpad.net/neutron/+milestone/liberty-3
14:25:12 <mestery> I've created a handy dandy gerrit dashboard for folks who wanted one
14:25:12 <mestery> #link https://goo.gl/x9bO7i
14:25:31 <mestery> #info PLEASE UPDATE YOUR TOPIC IN PATCHES YOU HAVE FOR LIBERTY-3 BPs SO THE GERRIT DASHBOARD WORKS
14:25:36 <mestery> MOAR YELLING
14:25:53 <regXboi> mestery: MOAR ???
14:25:56 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071786.html
14:26:01 <mestery> regXboi: It's a meme ;)
14:26:08 <carl_baldwin> mestery: Is this link the qos pecan only dash?
14:26:12 <mestery> ^^^ For those who want to read more than a tl;dr here
14:26:12 <mestery> Meh
14:26:29 <vikram_> #join /openstack-neutron
14:26:30 <mestery> carl_baldwin: That link is for all Essential/High/Medium L3 BPs
14:26:57 <mestery> As you can see, it really needs some love from folks with patches to update their topics
14:27:12 <mestery> For it to be more useful than it is
14:28:01 * mestery thinks we should have a poll on how people discover patches to review
14:28:42 <mestery> Next up
14:28:50 <mestery> #topic Merging QoS and pecan back
14:29:16 <mestery> ihrachyshka promised me a feature/qos "merge into master" commit this week yet
14:29:22 <ihrachyshka> I guess here I need to say smth...
14:29:22 <mestery> I remain hopeful we can fold that back in soon enough
14:29:42 <ihrachyshka> so basically, we plan to squash remaining patches prior to merge-back in next hours.
14:29:57 <ihrachyshka> then I'll create a merge-back patch + send an email with some info/links
14:30:05 <ajo> I tested it manually, and looking good after fixing a nit
14:30:12 <ajo> which is up for review & merge :)
14:30:13 <ihrachyshka> and then I expect other cores to jump on it, and do review :)
14:30:17 <mestery> ajo ihrachyshka: Nice work
14:30:39 <ihrachyshka> mestery, we will need you to push remaining things, but I guess that's about it until we are in master
14:30:42 <ajo> I will put down some instructions on how to test it, and a video to show how it works
14:30:52 <ihrachyshka> ajo++
14:31:02 <mestery> I should note that when this merge commit comes out, please do not nitpick it. The plan would be to merge it and if people really want to bike shed on it, lets file a bug to fix post-merge back.
14:31:12 <mestery> ihrachyshka: Thanks for the update
14:31:22 <ihrachyshka> we hope that documentation we provide will be enough to start with reviews, but anyway, we'll be avail to answer questions
14:31:29 <mestery> ihrachyshka: Excellent
14:31:35 <ihrachyshka> mestery, I am for nitpicking
14:31:38 <dougwig> i don't think merge commits have diffs, anyway.
14:31:41 <ihrachyshka> as long as it does not block the merge
14:31:47 <ihrachyshka> we are happy to handle it post-merge
14:31:47 <mestery> ihrachyshka: You can borrow dougwig's paint brush
14:32:01 <ihrachyshka> dougwig, you fetch it, then git diff origin/master...HEAD
14:32:14 <mestery> ihrachyshka: We'll have it in the merge queue before anyone can do that :P
14:32:36 <dougwig> ihrachyshka: real work tends to scare away bike shedding.  :)
14:32:36 <ihrachyshka> meh. I will digress.
14:32:58 <mestery> Thanks
14:33:56 <mestery> I know kevinbenton salv-orl_ and blogan are working on some (final?) patches for feature/pecan
14:34:02 <mestery> So we can fold that back into master in an experimental state
14:34:07 <mestery> Maybe next week
14:34:27 <salv-orl_> mestery: I think there are still a bit of TODOs to address to make it functionally equivalent with the eventlet wsgi framework
14:34:41 <salv-orl_> we'll se how many of them will be squashed in this week and then we'll reassess next week
14:34:52 <mestery> salv-orl_: Ack on that, I expect this one to get a FF exception already anyways, now I've said it :P
14:35:13 <salv-orl_> mestery: at the end of the day is an optional, self contained, component
14:35:27 <mestery> salv-orl_: Yup
14:35:37 <salv-orl_> getting rid of it is a simple as doing git rm -rf neutron/newapi
14:36:00 <mestery> #topic Open Discussion
14:36:13 * mestery passes coffee around
14:36:36 * xgerman hands dougwig a redbull
14:36:43 <dougwig> need some eyeballs on the new lbaas horizon work: https://review.openstack.org/#/c/206797/
14:36:46 * salv-orl_ recalls happy meetings when something else was being passed around
14:36:46 * mestery smacks the redbull out of dougwig's shaking hand
14:36:50 <dougwig> it's in a new repo, so it's easy to miss.
14:37:45 <amuller> maybe this is the forum to bring up https://review.openstack.org/#/c/210766/, which adds a very opionated testing coverage doc to Neutron
14:38:08 <amuller> or opinionated if you insist on correct spelling
14:38:34 <amuller> I'd appreciate if anyone can sit down and give that doc some thought
14:38:45 <mlavalle> salv-orl_: i am working on a new feature where i have added an attribute to ports in the old wsgi / api implementation. do I need to reimplemennt in the new pecan framework?
14:38:50 <salv-orl_> amuller: opiated works too for me.
14:39:07 <ajo> salv-orl_ I will take it opiated too..
14:39:08 <ajo> ;)
14:39:14 <salv-orl_> amuller: the obvious comment from somebody pedant like me is that as long as you're happy to maintain it that's ok for me
14:39:31 <amuller> salv-orl_: that is one thing I can commit to yes
14:39:37 <salv-orl_> mlavalle: kevinbenton has a mechanisms for loading existing extensions in pecan, so that's ok
14:39:56 <mlavalle> salv-orl_: :-)
14:40:07 <amuller> salv-orl_: reviewers will have to keep our various .rsts in mind, if a patch adds tests to something that is marked as X there, then that patch should also update the .rst
14:40:16 <mestery> amuller: At some point it would be fun to look at OVS sandbox for testing or even the container stuff marun is working on for non-neutron stuff. That holds promise for multinode testing on a single host :)
14:40:25 <mestery> amuller: But that's all future stuff, not exactly relevant to this doc right now.
14:40:34 <amuller> mestery: aye
14:40:49 <mestery> amuller: Thanks for your continued efforts on Neutron testing, this doc is fantastic to see
14:41:15 <mestery> OK, that about does it.
14:41:21 <mestery> With less than 3 weeks until FF, the pressure is on.
14:41:35 <mestery> Thanks for your continued support and efforts on OpenStack Neutron.
14:41:37 <mestery> #endmeeting