15:01:29 <carl_baldwin> #startmeeting neutron_l3
15:01:29 <sc68cal> o/
15:01:29 <openstack> Meeting started Thu Feb 26 15:01:29 2015 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:31 <pavel_bondar> hi
15:01:33 <openstack> The meeting name has been set to 'neutron_l3'
15:01:38 <carl_baldwin> #topic Announcements
15:01:44 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:01:59 <carl_baldwin> March 19th is the big day.  Kilo-3
15:02:05 <carl_baldwin> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
15:02:11 <carl_baldwin> Any other announcements?
15:02:34 <carl_baldwin> #topic Bugs
15:02:43 <carl_baldwin> Anything super-important here?
15:03:23 <carl_baldwin> If not, we’ll move on and spend a little extra time on bugs next week.
15:03:40 <carl_baldwin> #topic L3 Agent Restructuring
15:04:37 <carl_baldwin> My last patch here is https://review.openstack.org/#/c/158495/.  I need to turn my attention mostly away from this so I’ll just be care-and-feeding the patches that I currently have up.
15:04:55 <carl_baldwin> I know there are loose ends and I encourage you to continue working on those loose ends.
15:05:02 <carl_baldwin> mlavalle: Your patch is next in line.
15:05:14 <carl_baldwin> mlavalle: I liked it overall when I reviewed it the other day.
15:05:18 <carl_baldwin> mlavalle: Anything to discuss?
15:05:30 <mlavalle> carl_baldwin: I saw your feedbacb and will work on it today. That's all
15:05:36 <mlavalle> for today
15:05:38 <carl_baldwin> #link https://review.openstack.org/#/c/147744/26
15:05:59 <carl_baldwin> mlavalle: Thanks.  I didn’t see anything major in there.  Just minor cleanup.
15:06:05 <mlavalle> :-)
15:06:59 <carl_baldwin> Anything else?
15:07:30 <carl_baldwin> #topic neutron-ipam
15:07:43 <carl_baldwin> johnbelamaric: tidwellr: salv-orlando: ping
15:07:50 <johnbelamaric> carl_baldwin: pong
15:07:56 <tidwellr> pong
15:08:14 <carl_baldwin> Did we reach a conclusion on the discussion from yesterday?
15:08:31 <johnbelamaric> I believe so - it's in the review comments now.
15:08:38 <tidwellr> I think so
15:09:10 <johnbelamaric> any status on the reference driver? salv-orlando here?
15:09:20 <carl_baldwin> johnbelamaric: Do you have a link handy?  I haven’t seen the review since the comments have been added.
15:09:26 <johnbelamaric> one sec
15:09:57 <pavel_bondar> #link https://review.openstack.org/#/c/153236/8/neutron/db/db_base_plugin_v2.py that one?
15:10:00 <carl_baldwin> johnbelamaric: I thought we made some progress in salv-orlando ’s ML thread from the week.
15:10:57 <johnbelamaric> pavel_bondar: yes, that's it
15:11:17 <carl_baldwin> pavel_bondar: Thanks, I think johnbelamaric ’s comment there is correct.
15:11:23 <johnbelamaric> carl_baldwin: yes, I think progress is being made i just haven't seen a new patch since then. maybe I missed it
15:11:59 <carl_baldwin> johnbelamaric: To me, the progress was more around narrowing down the scope for Kilo so that we don’t have to worry about all of the possibilities.
15:12:17 <johnbelamaric> carl_baldwin: ah yes, I see your point.
15:12:24 <carl_baldwin> I haven’t seen a new patch either but I expect one will come soon.
15:12:36 <johnbelamaric> pavel_bondar: how is the dbbase plugin coming - are you blocked waiting on reference driver or you can proceed?
15:13:10 <pavel_bondar> I still have work to do, but as soon as refence driver appears I could start testing
15:14:09 <pavel_bondar> biggest part that left to do is rollback on exception, since ipam call is done in separate transaction
15:14:22 <johnbelamaric> pavel_bondar: ok
15:14:35 <salv-orlando> aloha people. sorry for being late.
15:14:48 <carl_baldwin> salv-orlando: hi
15:15:02 <pavel_bondar> salv-orlando: hi
15:15:32 <johnbelamaric> salv-orlando: hi
15:16:30 <carl_baldwin> salv-orlando:  Are there still open issues from the ML thread you started this week?
15:17:03 <salv-orlando> carl_baldwin: that thread has been inconclusive so far, which means
15:17:16 <salv-orlando> that for kilo we'll just adopt the same algorithm that we have, based on av ranges
15:17:24 <salv-orlando> adding only retry on deadlock
15:17:27 <salv-orlando> easy and simple
15:17:38 <salv-orlando> also reliable. Maybe not efficient but reliable
15:17:50 <salv-orlando> we can have fun in the next release and experiment with different things
15:18:20 <carl_baldwin> salv-orlando: I agree.  I think that is one mini-conclusion that came out of the thread.
15:18:34 <carl_baldwin> salv-orlando: You’re right though, the meat of the discussion was inconclusive.
15:19:54 <salv-orlando> carl_baldwin: it's not easy to reach any sort of agreement on this matter.
15:20:19 <carl_baldwin> salv-orlando: indedd
15:20:19 <johnbelamaric> salv-orlando: with pluggable, we don't need to - we can have multiple drivers and let experience show which algo is best :)
15:20:25 <carl_baldwin> s/indedd/indeed/
15:21:31 <salv-orlando> johnbelamaric: yeah pretty much. But we're also free to change the internal behaviour of the driver without worrying about affecting anything at the mgmt layer
15:21:55 <johnbelamaric> salv-orlando: yes, good point too
15:22:06 <salv-orlando> so I'm not worried at all about just sticking with what we have - and defer optimization to the next release
15:22:56 <carl_baldwin> salv-orlando: I think we’re all in agreement.  I’m glad to have a direction that could get us to Kilo.
15:23:11 <carl_baldwin> Anything more to discuss?
15:23:28 <pavel_bondar> one question about passing subnetpool_id, since it should be property of Pool, it should present in Pools init(), right?
15:24:16 <pavel_bondar> So should we update Pool interface and include it into __init__?
15:24:45 <pavel_bondar> I can add it to interface review page, and we could discuss it there
15:25:22 <carl_baldwin> pavel_bondar: Yes, please do.
15:25:47 <pavel_bondar> ok
15:26:28 <carl_baldwin> Anything else to discuss here?
15:27:06 <carl_baldwin> #topic neutron-ovs-dvr
15:27:14 <johnbelamaric> carl_baldwin: see #link https://review.openstack.org/#/c/147479/14/neutron/manager.py
15:27:15 <carl_baldwin> mrsmith: Swami: Rajeev:  ping
15:27:25 <mrsmith> Pong
15:27:27 <johnbelamaric> for a discussion of subnetpool_id, driver laoding, etc
15:27:39 <carl_baldwin> #undo
15:27:40 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x883d590>
15:27:59 * carl_baldwin looking...
15:28:05 <johnbelamaric> carl_baldwin: doesn't have to be now - can be addressed later
15:28:25 <johnbelamaric> carl_baldwin: just wanted to bring it to your attention in relation to pavel_bondar's question
15:28:35 <carl_baldwin> johnbelamaric: Thanks for pointing it out.  It is still early for me here, I hadn’t seen it.
15:29:02 <carl_baldwin> #topic neutron-ovs-dvr
15:29:11 <carl_baldwin> mrsmith: hi, anything to discuss here?
15:29:42 <mrsmith> Working on the non-voting test diffs between centralized
15:29:43 <carl_baldwin> Rajeev got me looking at a bug that might be due to the weak reference tracking of the fip namespace.  I don’t have any insight yet.
15:29:48 <mrsmith> Slow progress
15:29:54 <mrsmith> Ok
15:30:21 <carl_baldwin> #link https://bugs.launchpad.net/neutron/+bug/1425639
15:30:23 <openstack> Launchpad bug 1425639 in neutron "A functional floating ip stops working sometimes if another floating ip is created and deleted." [Undecided,In progress] - Assigned to Rajeev Grover (rajeev-grover)
15:30:23 <mrsmith> There has been some improvement from swamis patches
15:30:34 <amuller> there's those 3 DVR bugs I found, I don't have time to add tests to those patches.
15:31:02 <carl_baldwin> amuller: Could you link them here for posterity?
15:31:16 <amuller> coming up
15:31:29 <carl_baldwin> I was swamped last week and didn’t have time to look at them at all.  Sorry about that.
15:31:49 <amuller> #link https://bugs.launchpad.net/neutron/+bug/1423777
15:31:50 <openstack> Launchpad bug 1423777 in neutron "TRACE when removing a floating IP from a DVR router that has no floating IPs" [Undecided,In progress] - Assigned to Assaf Muller (amuller)
15:31:59 <amuller> #link https://bugs.launchpad.net/neutron/+bug/1423775
15:32:00 <openstack> Launchpad bug 1423775 in neutron "TRACE when restarting openvswitch if using OVS DVR agent" [Undecided,In progress] - Assigned to Assaf Muller (amuller)
15:32:05 <amuller> #link https://bugs.launchpad.net/neutron/+bug/1423774
15:32:06 <openstack> Launchpad bug 1423774 in neutron "Fix TRACE when removing a DVR router port from a VLAN network" [Undecided,In progress] - Assigned to Assaf Muller (amuller)
15:32:15 <carl_baldwin> amuller: Thanks.
15:32:48 <amuller> all 3 have patchs up, marun -1 because they have no tests to mitigate regressions. I agree with him but I don't have time to deal with that.
15:33:00 <carl_baldwin> amuller: ack
15:33:02 <amuller> I was hoping someone could take those off my hands
15:33:17 <mrsmith> I can try to find some cycles
15:33:29 <amuller> mrsmith: thanks
15:33:30 <mrsmith> I'll take a look at least
15:34:04 <mrsmith> Functional or unit?
15:34:24 <carl_baldwin> mrsmith: I’ll keep looking in to bug 1425639.  I suspect we’ll need to get some more logging added for when we can catch the bug in the gate and check queues.
15:34:25 <openstack> bug 1425639 in neutron "A functional floating ip stops working sometimes if another floating ip is created and deleted." [Undecided,In progress] https://launchpad.net/bugs/1425639 - Assigned to Rajeev Grover (rajeev-grover)
15:35:36 <mrsmith> amuller: functional or unit tests?
15:35:49 <amuller> mrsmith: depends on the case
15:35:56 <mrsmith> K
15:36:13 <amuller> whatever is more appropriate. If you find yourself mocking out the entire world maybe a functional test would be better
15:37:48 <carl_baldwin> Anything else on DVR to discuss here?
15:38:52 <carl_baldwin> #topic Open Discussion
15:39:55 <amuller> carl_baldwin: pc_m just +2'd https://review.openstack.org/#/q/topic:bug/1425759,n,z
15:39:56 <amuller> on the vpnaas repo
15:40:17 <amuller> I want to ask to merge these ASAP so we can start moving from though gigantic chain before K3...
15:40:27 <amuller> moving through*
15:40:28 <carl_baldwin> amuller: I think we can get those in quickly.
15:41:04 <amuller> carl_baldwin: Sounds good :)
15:41:27 <pc_m> I think we'll be OK, although am a little concerned as the impression is that we'll have seperate processes, for the AdvancedService instance, if > 1 agent for a service, however the test failure seems to imply instance was shared by two processes.
15:42:15 <amuller> a singleton cannot be shared across different processes
15:42:22 <pc_m> Not an issue currently, as we have only one agent per service. Something we need to keep an eye on though.
15:42:58 <pc_m> amuller: Right, so I'm having a hard time understanding how the functional test failed.
15:43:32 <amuller> Me too :) The only thing I can think of is that somehow, two tests were running at the same time in the same process (Which shouldn't happen according to my understanding)
15:43:48 <amuller> or there was some shared point in time where one tests did not finish and the other already started
15:43:54 <amuller> that would screw up the first test
15:44:21 <pc_m> though that would imply two agents in same process...
15:44:22 <amuller> one test*
15:44:29 <amuller> pc_m: each test has its own agent
15:44:34 <amuller> initialized in the test setUp
15:44:48 <carl_baldwin> pc_m: I think the test runner may run multiple tests in the same process.  I don’t know for sure how it works but it doesn’t surprise me.
15:45:13 <amuller> mind you we dont actually start the L3 agent like you do through the CLI, but the test setUp does create a L3 agent instance, which initializes its own self.conf
15:45:14 <pc_m> carl_baldwin: must be. Only way I could account for the issue.
15:45:21 <amuller> so each L3 agent instance has its own conf object
15:49:16 <amuller> carl_baldwin: who can I contact for FWaaS repo merge?
15:49:41 <pc_m> amuller: dougwig, SumitNaiksatam
15:50:22 <carl_baldwin> amuller: https://review.openstack.org/#/admin/groups/500,members
15:50:53 <salv-orlando> amuller: also any neutron drivers
15:51:07 <amuller> salv-orlando: Like yourself? :)
15:51:17 <salv-orlando> as long as I'm there, yes
15:55:32 <carl_baldwin> I think we’ll call it a meeting.
15:55:49 <carl_baldwin> Thanks, everyone for all your work.
15:56:08 <carl_baldwin> #endmeeting