14:59:55 <mlavalle> #startmeeting neutron_l3
14:59:55 <openstack> Meeting started Thu May 19 14:59:55 2016 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:58 <openstack> The meeting name has been set to 'neutron_l3'
15:00:14 <carl_baldwin> hi
15:00:15 <haleyb> hi
15:00:18 <tidwellr> hi
15:00:20 <pavel_bondar> hi
15:00:21 <mlavalle> #chair carl_baldwin
15:00:32 <openstack> Current chairs: carl_baldwin mlavalle
15:00:39 <mlavalle> #chair tidwellr
15:00:40 <openstack> Current chairs: carl_baldwin mlavalle tidwellr
15:00:46 <AndroUser2> Hi
15:00:50 <mlavalle> hi everybody
15:01:32 <mlavalle> Meeting agenda is in our new shiny etherpad: https://etherpad.openstack.org/p/neutron-l3-subteam
15:01:44 <mlavalle> #topic Announcements
15:02:08 <mlavalle> Newton-1 is just 2 weeks away
15:02:48 <mlavalle> any other annoucments from the team?
15:03:19 <mlavalle> #topic Bugs
15:03:25 <carl_baldwin> Not from me.
15:03:53 <mlavalle> First up is https://bugs.launchpad.net/neutron/+bug/1543094
15:03:54 <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:04:02 <tidwellr> hi
15:04:24 <mlavalle> 2 patchsets merged, right?
15:04:48 <mlavalle> this one is pending, as far as I understand:
15:04:55 <mlavalle> #link https://review.openstack.org/#/c/292207/
15:04:55 <tidwellr> yes, the unit and tempest tests have been adjusted to not assume any particular allocation stategey
15:05:17 <carl_baldwin> That was a lot of work.  Nice job!
15:06:05 <tidwellr> I'm now seeing the following issue across various jobs (http://paste.openstack.org/show/497738/) with  https://review.openstack.org/#/c/292207/
15:06:55 <tidwellr> this is failure showing up across different tests every time it gets checked by jenkins
15:07:10 <tidwellr> still working through that
15:07:20 <haleyb> tidwellr: i've actually seen that error before, tried a revert of the change but it didn't remove the failure
15:08:07 <tidwellr> haleyb: are you giving me the good news that my change isn't causing this? ;)
15:08:15 <pavel_bondar> tidwellr: when did you see it first time?
15:08:33 <tidwellr> it's been showing up since I first proposed the patch
15:08:47 <tidwellr> as far as I can recall
15:09:02 <haleyb> tidwellr: i guess so.  that failure has been intermittent for a few weeks for me, just can't reproduce it at-will
15:09:37 <tidwellr> haleyb: it seems to happen somewhere with every recheck on this patch
15:09:48 <carl_baldwin> I've also seen it outside of the context of this patch.
15:10:00 <carl_baldwin> haleyb: Is there a bug already filed for this issue?
15:10:29 <tidwellr> there must be something this patch does that exacerbates the issue, maybe we can learn something from diving in on this patch
15:10:51 <haleyb> carl_baldwin: i think so, i'll look.  That error message was added in https://review.openstack.org/#/c/281116/
15:11:53 <haleyb> i'll look in logstash too
15:12:48 <tidwellr> if we can get past this then we can get on with merging https://review.openstack.org/#/c/292207/
15:13:59 <carl_baldwin> That'd be great.  I'll spend a little time looking in to this today.
15:14:29 <tidwellr> carl_baldwin haleyb: thanks for the insights
15:14:38 <carl_baldwin> haleyb: Let me know if you find the bug.
15:14:39 <haleyb> has 9.5K hits in logstash in last 24 hours
15:14:49 <carl_baldwin> yikes!
15:14:51 <tidwellr> haleyb: wow!
15:15:16 <carl_baldwin> I think we need to bump this bug up in priority and call it a gate failure.
15:15:34 <tidwellr> haleyb: how much in the last 48 hours?
15:17:08 * haleyb plays jeopardy song while waiting
15:17:29 <haleyb> 20K
15:18:40 <tidwellr> wow, and I thought it was an issue introduced by the ipam patches I've been proposing
15:19:00 <carl_baldwin> OK, let's first make sure we know the bug number for this and then stick the logstash queries in there.
15:19:07 <carl_baldwin> Then, I'll start looking in to it.
15:19:27 <carl_baldwin> My quick search through launchpad didn't find the bug.
15:20:34 <mlavalle> tidwellr: should we move on?
15:20:47 <carl_baldwin> haleyb: let me know if I should file a bug.
15:20:52 <tidwellr> I have nothing else to add
15:20:55 <carl_baldwin> mlavalle: We can move on and take this out of band.
15:21:04 <haleyb> carl_baldwin: i didn't find a bug either
15:21:26 <mlavalle> Next bug is https://bugs.launchpad.net/neutron/+bug/1564335
15:21:27 <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:21:44 <pavel_bondar> hi
15:21:55 <pavel_bondar> I have uploaded new version of patch recently
15:22:14 <pavel_bondar> #link https://review.openstack.org/#/c/300984/
15:23:05 <pavel_bondar> It fixes the first part of the issue
15:23:38 <pavel_bondar> To address the second part (correct SLAAC deallocation) more discussion might be needed.
15:24:21 <pavel_bondar> Currently via update_port we can not deallocate addresses for auto-addressed subnets
15:24:21 <carl_baldwin> I'll review this patch.
15:25:22 <carl_baldwin> pavel_bondar: why is that?
15:26:08 <pavel_bondar> Currently and previously if auto_addressed ip is not present in fixed_ips list it is not deleted on update
15:26:23 <pavel_bondar> this worked this way for a while
15:26:44 <pavel_bondar> so I am not sure that it is save to silently change this befavior
15:27:14 <pavel_bondar> *behavior
15:27:27 <carl_baldwin> So, the auto IP from the subnet being deleted is not passed in fixed_ips on update and so it isn't deleted?
15:27:43 * carl_baldwin just trying to understand.
15:28:14 <pavel_bondar> no
15:29:35 <pavel_bondar> probably we can discuss it in main neutron channel later, I assume it will take a lot of time
15:29:38 <carl_baldwin> pavel_bondar: Could we take some time after the meeting to discuss this?
15:29:46 <pavel_bondar> yeah, sure
15:29:46 <carl_baldwin> pavel_bondar: Let me know what time works for you.
15:30:01 <pavel_bondar> in 1 hour from now
15:30:34 <mlavalle> ok, we'll move on...
15:30:48 <mlavalle> Next bug is https://bugs.launchpad.net/neutron/+bug/1566383
15:30:49 <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:30:52 <carl_baldwin> pavel_bondar: ok
15:31:09 <mlavalle> haleyb: you are up
15:31:52 <haleyb> mlavalle: that series is in master, just doing backports now to stable/mitaka
15:32:24 <mlavalle> haleyb: so I will remove it from our list, ok?
15:32:36 <haleyb> yes, we can remove from agent if it's there
15:33:02 <haleyb> s/agent/agenda
15:33:09 <mlavalle> cool
15:33:18 <mlavalle> moving on
15:33:34 <mlavalle> The last one for today is a new one: https://bugs.launchpad.net/neutron/+bug/1581918
15:33:35 <openstack> Launchpad bug 1581918 in neutron "Sometimes DHCP agent spawns dnsmasq incorrectly" [High,In progress] - Assigned to Kevin Benton (kevinbenton)
15:34:02 <mlavalle> kevinbenton has proposed this fix: https://review.openstack.org/#/c/316615/
15:34:32 <mlavalle> it seems ready to merge
15:35:06 <mlavalle> anything else to comment?
15:35:40 <carl_baldwin> I'll have another look at the patch set.
15:35:42 <carl_baldwin> Nothing more.
15:35:50 <mlavalle> ok, moving on
15:36:01 <mlavalle> #topic Routed Networks
15:36:12 <carl_baldwin> Hi
15:36:23 <irenab> mlavalle: you skipped the RFE section
15:36:31 <carl_baldwin> I feel like this is moving along well.  But, I've been distracted from it for the last day.
15:36:32 <carl_baldwin> :(
15:36:47 <carl_baldwin> I did respin the Nova spec.
15:36:58 <mlavalle> irenab: we'll go back to it when the routed networks update ends
15:37:05 <irenab> ok
15:37:45 <carl_baldwin> I think we need to let Nova know about the updates.
15:38:16 <carl_baldwin> I also have a patch up for IPAM on create port with binding info
15:38:20 <carl_baldwin> I think it is ready to go.
15:38:26 <mlavalle> ++
15:38:28 <carl_baldwin> But, we need mlavalle 's patch first.
15:38:38 <carl_baldwin> ... which I've failed to review for the last 24-48 hours.
15:38:58 <mlavalle> I addressed your comments last night. I also completed all the unit tests.
15:39:32 <carl_baldwin> Actually, the Nova spec has two more TODOs to flesh out.  On testing and documentation.  I wanted a little feedback from Nova on this.
15:39:37 <mlavalle> No worries, I introduced a small failure in the unit tests last night. I know what the problem is and I will roll an update in 1 hour or so
15:39:40 <carl_baldwin> mlavalle: Thanks, I'll have a look today.
15:39:54 <carl_baldwin> mlavalle: Ping me when the update is ready.
15:40:03 <mlavalle> carl_baldwin: will do
15:40:52 <carl_baldwin> After that, I need to complete IPAM when port binding info is first provided on port update.  I'm about half way through that, I think.
15:40:57 <carl_baldwin> That's all from me.
15:41:21 <mlavalle> ok, moving on
15:41:27 <mlavalle> #topic RFE's
15:41:39 <mlavalle> irenab: you are up. Thanks for the patience
15:41:49 <irenab> thank you
15:42:01 <irenab> I wanted to provide short update on 	▪	https://bugs.launchpad.net/neutron/+bug/1566191
15:42:02 <openstack> Launchpad bug 1566191 in neutron "[RFE] Allow multiple networks with FIP range to be associated with Tenant router" [Wishlist,Triaged]
15:42:40 <irenab> after discussion with yamamoto, he did modification on this patch https://review.openstack.org/#/c/292318/
15:43:18 <irenab> The proposed way should both allow reference implementation keep the existing single FIP support and allow midonet plugin to allow multiple FIPs
15:43:36 <carl_baldwin> irenab: I'll take a look.
15:44:17 <carl_baldwin> Do you have a tl;dr summary?
15:44:19 <irenab> Regardless of this fix, if the use case is interesting to other plugins, we may keep discussion at RFE and make the implementation more complete
15:44:44 <irenab> Basically, it sets flag if to fail or not at validation phase
15:45:06 <irenab> the flag is to_fail by default and will be set to not_fail at midonet plugin
15:45:18 <mlavalle> that makes sense
15:45:50 <irenab> this will allow existing integration to keep working, while we may provide more robust support in Newton
15:46:53 <irenab> Please let me know how to proceed with RFE
15:46:58 <carl_baldwin> irenab: My concern is that it is not discoverable.  But, maybe that's ok.
15:47:35 <irenab> with current fix, it will behave gracefully if not supported and we may add discovery in Newton. Do you agree?
15:48:49 <irenab> I think the current fix provides sort of win win :-
15:48:55 <carl_baldwin> irenab: We'll take this to the patch.  I don't want to make this too hard.  Sorry if it has been painful.
15:49:23 <irenab> carl_baldwin: thanks, lets keep discussion there
15:49:47 <carl_baldwin> irenab: ok, thanks!
15:49:49 <mlavalle> ok, for the sake of time, let's move on
15:49:58 <mlavalle> #topic BGP Dynamic Routing
15:50:15 <mlavalle> tidwellr: you are up again
15:50:31 <tidwellr> the only thing I had was a quick question regarding the process for handling RFE's
15:50:33 <Na_> hi
15:51:23 <tidwellr> we're starting to see some RFE's related to BGP, and I'm sitting on a couple myself, perhaps I can take this offline with carl_baldwin
15:51:38 <tidwellr> just not sure what to do with them at this point
15:52:11 <Na_> tidwellr: About the CLI transition, no progress so far, but vikram and I taked with amotoki today, he will help to review Richard's patch about adding osc plugin to python-neutronclient, if this patch is merge, we can start the CLI transition work, moving bgp CLI from neutron to openstack.
15:52:17 <tidwellr> we've almost got the repository stood up with devstack and gate_hook in place, so we're almost ready to get rolling
15:52:27 <carl_baldwin> tidwellr: we need to make another pass at them.  Figure out which ones will require changes to the neutron repo and which ones are BGP only.  Then, prioritize.
15:52:53 <carl_baldwin> tidwellr: Maybe we can shoot to have them all in order by next week's drivers' meeting on Thursday?
15:53:03 * carl_baldwin doesn't think he can help get them in order by today.
15:53:25 <tidwellr> carl_baldwin: sure, next week is fine
15:53:42 <tidwellr> we're not ready to get rolling with development in the repo quite yet
15:54:07 <carl_baldwin> tidwellr: Could you find some time to discuss it before then?
15:54:14 <tidwellr> I have time
15:54:40 <tidwellr> I should get my RFE's captured as well
15:55:19 <tidwellr> Na_: thanks for the update
15:55:27 <tidwellr> that's all I had
15:55:30 <Na_> tidwellr: Richard is busy, maybe we need to take over his patch if he still have no time this week. But I think, since the CLIs keep in python-neutronclient repo, we do not have to meet the target N-1  because it has dependency on OSC transition. It should align with OSC transiton's plan.
15:56:01 <mlavalle> ok, we'll move on
15:56:08 <mlavalle> #topic FWaaS
15:56:27 <mlavalle> Anyone from the FWaaS team around?
15:56:31 <SridarK> Hi
15:56:38 <mlavalle> Hi :-)
15:56:55 <SridarK> We are looking thru the spec that njohnston filed
15:57:13 <SridarK> need some more time to have a model in place that we can discuss with u folks
15:57:24 <SridarK> we will shoot to have something for next week
15:57:44 <mlavalle> SridarK: ok, we'll keep you in next week's agenda
15:57:50 <SridarK> mlavalle: thx
15:58:01 <mlavalle> #topic Open discussion
15:58:08 <Na_> hi
15:58:19 <mlavalle> Just a couple of minutes left. Anything to bring to the team?
15:58:28 <steve_ruan> https://bugs.launchpad.net/neutron/+bug/1525059
15:58:29 <openstack> Launchpad bug 1525059 in neutron "[RFE] Add support for external vxlan encapsulation to neutron router" [Wishlist,In progress] - Assigned to Na Zhu (nazhu)
15:58:38 <steve_ruan> Need for review
15:59:00 <steve_ruan> please help, thanks
15:59:11 <mlavalle> steve_ruan: do you have gerrit link?
15:59:22 <steve_ruan> 4 patches,
15:59:37 <steve_ruan> all link is attached this bug
15:59:45 <mlavalle> ok, thanks
15:59:57 <mlavalle> we ran out of time
16:00:03 <carl_baldwin> bye
16:00:03 <mlavalle> #endmeeting