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