15:00:29 <tidwellr_> #startmeeting neutron_l3
15:00:29 <pavel_bondar> hi
15:00:30 <openstack> Meeting started Thu May 12 15:00:29 2016 UTC and is due to finish in 60 minutes.  The chair is tidwellr_. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:32 <vikram_> hi
15:00:33 <openstack> The meeting name has been set to 'neutron_l3'
15:00:42 <njohnston__> o/
15:01:02 <tidwellr_> #topic Announcements
15:02:10 <tidwellr_> Newton-1 is coming up in a couple weeks
15:02:54 <tidwellr_> this cycle is moving quickly, so tick tock :)
15:03:07 <carl_baldwin> I have one announcement
15:03:07 <tidwellr_> any other announcements?
15:03:23 <carl_baldwin> I'm moving the subteam meeting agenda page to etherpad
15:03:34 <tidwellr_> +100
15:03:34 <carl_baldwin> #link https://etherpad.openstack.org/p/neutron-l3-subteam
15:03:38 <vikram_> +1
15:04:03 <carl_baldwin> I've got it almost all moved except I need to decide which URL shortener to use on the really long bug query URLs.
15:04:41 <carl_baldwin> I see some activity there already.  Nice!
15:05:03 <tidwellr_> thanks carl_baldwin, this is very nice
15:05:41 <carl_baldwin> After the meeting, I'll take everything off of the wiki and leave a link to the etherpad.
15:06:40 <tidwellr_> thanks for doing this, it's easy to just put off doing these housekeeping things
15:06:55 <tidwellr_> any other announcements?
15:07:02 <njohnston__> Hopefully we can change eavesdrop.openstack.org to point to this agenda as well
15:07:09 <carl_baldwin> tidwellr_: yup, the wiki had a lot of old cruft on it.  It will be easier to do weekly maintenance on the page now.
15:07:23 <carl_baldwin> njohnston__: Good point.
15:07:37 <carl_baldwin> #action carl_baldwin will update eavesdrop to point to the new page.
15:09:00 <tidwellr_> alright, moving on
15:09:06 <tidwellr_> #topic Bugs
15:09:08 <carl_baldwin> I only started the etherpad 20 minutes ago and look how much it has helped.
15:09:31 <tidwellr_> https://bugs.launchpad.net/neutron/+bug/1543094
15:09:33 <openstack> Launchpad bug 1543094 in neutron "[Pluggable IPAM] DB exceeded retry limit (RetryRequest) on create_router call" [High,In progress] - Assigned to Ryan Tidwell (ryan-tidwell)
15:10:20 <tidwellr_> so, the meat of the fix really is ready to go
15:10:43 <carl_baldwin> tidwellr_: Do you think we should merge the unit test fixes now?
15:11:00 <tidwellr_> carl_baldwin: I'm thinking yes
15:11:27 <tidwellr_> I posted https://review.openstack.org/#/c/312655/ to flush out test failures
15:11:47 <tidwellr_> it's only finding tempest test failures at the moment
15:12:05 <carl_baldwin> +2 on the test changes.  Needs to recheck though.
15:12:25 <tidwellr_> I meant to investigate that, were there some gate failures recently?
15:12:33 <carl_baldwin> tidwellr_: Are the tempest test changes needed for the meat of the fix?
15:13:05 <carl_baldwin> #action carl_baldwin will review https://review.openstack.org/#/c/292207 today
15:13:40 <tidwellr_> carl_baldwin: unfortunately yes, if we merge https://review.openstack.org/#/c/292207/ we'll have failures in the dsvm-api job
15:14:26 <carl_baldwin> tidwellr_: okay
15:14:40 <tidwellr_> I have https://review.openstack.org/#/c/312771/ to clean up the tempest tests, there are 2 tests that have me perplexed
15:15:07 <tidwellr_> once we get them cleaned up then we can merge https://review.openstack.org/#/c/312771/, which then unlocks the rest of the neutron chain
15:15:54 <carl_baldwin> I now see the depends-on.  Nice.
15:16:07 <carl_baldwin> tidwellr_: Do you need any help with the failures?
15:17:33 <tidwellr_> I could use some help with the tests I pointed out in my review comment
15:18:00 <carl_baldwin> johnbelamaric: pavel_bondar:  Any chance one of you could take a look?
15:18:16 <carl_baldwin> #link https://review.openstack.org/#/c/312771/
15:18:16 <tidwellr_> I've seen those failure on both https://review.openstack.org/#/c/292207 and https://review.openstack.org/#/c/312655/
15:18:46 <carl_baldwin> tidwellr_: You pointed them out in your comment on May 9th to 312771, right?
15:18:51 <tidwellr_> yes
15:18:56 <johnbelamaric> carl_baldwin: sure. pavel_bondar will be more useful than me but I will take a look too
15:19:19 <pavel_bondar> carl_baldwin: I'l try to take a look
15:19:29 <tidwellr_> pavel_bondar: thanks!
15:20:00 <carl_baldwin> pavel_bondar: Thanks.  I won't ask you to spend a lot of time on it but if you can provide any insight with a quick look in to it, it might help.
15:20:12 <carl_baldwin> johnbelamaric also ^
15:20:58 <tidwellr_> just to be clear we're walking about tempest test failures that occur when IP allocation is not sequential
15:21:41 <tidwellr_> anyway, that's all I had on this bug
15:21:46 <tidwellr_> anything else to add?
15:22:27 <tidwellr_> https://bugs.launchpad.net/neutron/+bug/1564335
15:22:28 <openstack> Launchpad bug 1564335 in neutron " [Pluggable IPAM] delete subnet in ml2 plugin does not comply with pluggable ipam (deletes ip allocations directly from db)" [High,In progress] - Assigned to Pavel Bondar (pasha117)
15:23:10 <pavel_bondar> fix is here #link https://review.openstack.org/#/c/300984
15:23:43 <pavel_bondar> need to address comment from Brian, but any additional reviews are welcome
15:23:55 <carl_baldwin> pavel_bondar: ack
15:24:02 <carl_baldwin> I will review it today.
15:24:25 <tidwellr_> awesome, it looks like you're close on this one
15:24:58 <pavel_bondar> tidwellr_: yeah, looks close
15:25:09 <tidwellr_> cool, anything else to add?
15:25:30 <pavel_bondar> no
15:25:36 <tidwellr_> https://bugs.launchpad.net/neutron/+bug/1566383
15:25:38 <openstack> Launchpad bug 1566383 in neutron "The creation fip does not endure restarting of l3-agent" [High,Fix released] - Assigned to Brian Haley (brian-haley)
15:26:17 <carl_baldwin> Just backports now, right?
15:26:26 <tidwellr_> looks that way
15:26:44 <haleyb> yes, master changes merged
15:26:52 <carl_baldwin> haleyb: good work
15:27:06 <haleyb> backports are stuck because of some tempest bugs
15:27:18 <haleyb> or neutron bugs with tempest
15:28:05 <tidwellr_> sounds like we're good on this one, can we move on?
15:28:12 <haleyb> yup
15:28:17 <tidwellr_> https://bugs.launchpad.net/neutron/+bug/1572474
15:28:18 <openstack> Launchpad bug 1572474 in neutron "[Pluggable IPAM] Deadlock on simultaneous update subnet and ip allocation from subnet" [High,In progress] - Assigned to Pavel Bondar (pasha117)
15:29:02 <tidwellr_> this will be fixed when we fix the first bug we talked about, I think
15:29:23 <pavel_bondar> and backportable fix is here #link https://review.openstack.org/#/c/309067/
15:29:41 <tidwellr_> ooh, a backportable fix
15:29:44 <carl_baldwin> pavel_bondar: I'll review this today also.
15:30:07 <pavel_bondar> it had +2 from carl, but I had to rebase it
15:30:18 <pavel_bondar> carl_baldwin: thanks!
15:30:37 <tidwellr_> I'd like to understand this, so I'll try to take a look too
15:31:09 <pavel_bondar> tidwellr_: thanks!
15:31:46 <tidwellr_> anything else on this one?
15:32:00 <pavel_bondar> no
15:32:07 <tidwellr_> #topic Routed network segments
15:32:27 <carl_baldwin> Hi
15:32:47 <carl_baldwin> The patch to allow associating a subnet merged!
15:33:09 <carl_baldwin> I've also posted a patch starting to handle the IPAM.  It needs integration with mlavalle 's patch.
15:33:19 * tidwellr_ cues applause
15:34:04 <carl_baldwin> Actually, another patch merged last night too.  It was a refactor in IPAM that will allow drivers to consider more than one subnet at a time.
15:34:05 * mlavalle pushed next revision last night
15:35:00 <tidwellr_> carl_baldwin: so, should the reference driver be considering just 1 subnet at a time?
15:35:01 <carl_baldwin> mlavalle: Do you know if it was rebased past https://review.openstack.org/#/c/304886/ ?
15:35:18 * mlavalle looking
15:35:24 <carl_baldwin> tidwellr_: The reference driver should now be enhanced to take advantage of this.
15:35:46 <carl_baldwin> Anyone want to take this on?  I haven't started a patch but I'd be willing to help.
15:36:05 <carl_baldwin> It is low hanging fruit but might be a little more complex than other low hanging fruit.
15:36:36 <tidwellr_> carl_baldwin: I suppose this impacts the bug fix we discussed earlier where we're changing the allocation algorithm?
15:37:07 <carl_baldwin> tidwellr_: It does.
15:37:23 <mlavalle> carl_baldwin: no, this one merged after I pushed last night
15:37:27 <carl_baldwin> Although that bug fix can still work, just not as efficiently.
15:37:38 <tidwellr_> carl_baldwin: duly noted :)
15:37:43 <carl_baldwin> mlavalle: How much trouble would it be to rebase again?
15:38:03 <carl_baldwin> tidwellr_: I hate to give it to you.  I know you've been very busy lately.  But, I wouldn't stop you either.
15:38:05 <mlavalle> carl_baldwin: none. I'll do it over the next few minutes
15:38:18 <carl_baldwin> mlavalle: thanks.
15:38:49 <carl_baldwin> Next steps for me are to pile the rest of what I've got on mlavalle 's patch and start integrating host / segment awareness in to my IPAM stuff.
15:39:09 <carl_baldwin> mlavalle: That puts the focus on you.  You can handle it.
15:39:11 <carl_baldwin> :)
15:39:23 <mlavalle> I hope :-)
15:40:35 <carl_baldwin> Anything else from others on this topic?
15:40:47 <carl_baldwin> I think the work is moving along very nicely.
15:40:59 <tidwellr_> sounds like it
15:41:22 <carl_baldwin> Let's move on.  We've got a couple more things to discuss.
15:41:26 <tidwellr_> k
15:41:30 <tidwellr_> #topic BGP Dynamic Routing
15:41:31 <carl_baldwin> ... not routed networks related.
15:42:17 <Na_Zhu> hi
15:42:21 <tidwellr_> carl_baldwin: could use a +2 on https://review.openstack.org/#/c/312324/
15:42:24 <carl_baldwin> Looks like there are some reviews to do.  I can help.
15:42:27 <vikram_> hi
15:42:41 <tidwellr_> I've got the code pulled over and using neutron-lib everywhere now
15:42:55 <vikram_> I have mentioned about the links over the etherpad..
15:43:14 <vikram_> tidwellr_: nice work.. i troubled you a lot ;(
15:43:19 <tidwellr_> vikram_: I need to plow through some of those reviews as well
15:43:33 <Na_Zhu> the CLI side has no update this week
15:44:11 <tidwellr_> Na_Zhu: for my benefit, the CLI is staying in python-neutronclient?
15:45:08 <Na_Zhu> tidwellr: yes, but need add osc plugin to python-neutronclient, Richard is doing that
15:45:11 <carl_baldwin> time check.  We need time for fwaas.
15:45:39 <vikram_> tidewellr_: Yes it will be but need to port to OSC plugin as well
15:45:45 <tidwellr_> ok, well I didn't have much that we can't take offline
15:45:54 <Na_Zhu> tidwellr: the neutron-*aas owners need re-factor the code to align with the osc plugin
15:46:20 <tidwellr_> Na_Zhu: thanks for the update, that helps me
15:46:21 <vikram_> I think we are on right track and hope can make to N-1
15:46:54 <tidwellr_> yes
15:47:03 <vikram_> that all from my end..
15:47:15 <tidwellr_> alright, let's move on then
15:47:22 <tidwellr_> #topic FWaaS
15:47:30 <SridarK> Hi
15:47:31 <carl_baldwin> SridarK: ping
15:47:38 <SridarK> thx for some airtime
15:47:50 <njohnston__> thanks!
15:47:51 <SridarK> With the merge of #link https://review.openstack.org/#/c/223343/ FWaaS Agent is out of L3Agent. We look for a cleaner model to integrate service agents into L3Agent.
15:48:26 <SridarK> We would really like some help to see what the approach should be for us to integrate into L3Agent
15:48:45 <SridarK> #link https://bugs.launchpad.net/neutron/+bug/1580239
15:48:47 <openstack> Launchpad bug 1580239 in neutron "[RFE] Add agent extension framework for L3 agent" [Wishlist,Triaged]
15:49:09 <njohnston__> We figure that a good understanding of the right design approach will save us all time in the long run.
15:49:22 <carl_baldwin> SridarK: I'm not very familiar with the L2 analog to this.  Is there any documentation I could review?  Did you guys look in to it already?
15:49:46 <carl_baldwin> There is an L2 agent extension mechanism, right?
15:49:52 <njohnston__> There is not much documentation, as the L2 version was done while ther separate neutron-qos branch was in operation
15:49:56 <SridarK> njohnston__: can u pls help - njohnston__ has used this in the context of qos
15:50:26 <njohnston__> #link https://review.openstack.org/#/c/195439/ The change creating the L2 agent extension
15:50:50 <njohnston__> but it was never specced out
15:51:05 <carl_baldwin> njohnston__: thank you
15:51:14 <SridarK> carl_baldwin: The FWaaS agent maps router ids to router info and then accesses the router ns to program iptables
15:51:45 <njohnston__> carl_baldwin: There was later an API laid over it in Mitaka
15:51:45 <SridarK> so some cleaner mechanism to load in a service agent would be ideal
15:51:57 <njohnston__> #link https://review.openstack.org/#/c/263819/ Spec for L2 agent extension API
15:52:24 <njohnston__> #link https://review.openstack.org/#/c/267591/ Implementation for L2 agent extension API
15:52:53 <njohnston__> the API was needed to allow extensions to gain access to resources the L2 agent had, like OVS flow cookies
15:54:09 <carl_baldwin> You guys are pretty far ahead of me on this.  What do you think is needed?  Do you know enough that you could attempt to spec something out?
15:54:55 <SridarK> carl_baldwin: we can certainly help on this but would appreciate someone from the L3 team to work with us on this
15:55:02 <njohnston__> I think we could spec something out, yes, but I think implementation may be better done with someone more familiar with the internal complexities of the L3 agent.
15:56:48 <njohnston__> I will draft up a spec over the next couple of days and post it to the specs repo early next week.
15:56:52 <SridarK> carl_baldwin: we are in a spot as fwaas is broken now after removing the albeit ugly inhertiance model so really could use all the help we can get
15:58:22 <carl_baldwin> understood.  We had been talking about getting that inheritance out of there for many cycles.  It was time to do it.
15:58:32 <SridarK> carl_baldwin: understand
15:59:08 <njohnston__> carl_baldwin: Just to be clear though, there is some inheritance involved using the L2 model as well, as L2 extensions inherit from the OVSAgentExtensionAPI class.  But it's cleaner
15:59:10 <carl_baldwin> I can give some guidance and some help if you guys can drive it forward.
15:59:34 <SridarK> carl_baldwin: thx much appreciated
15:59:54 <carl_baldwin> njohnston__: inheritance may be acceptable as long as it is a class like that which is designed for it.
16:00:00 <njohnston__> ok, good
16:00:09 <carl_baldwin> we can take this to the neutron room if needed.
16:00:11 <carl_baldwin> #endmeeting
16:00:24 <tidwellr_> #endmeeting