14:00:40 <liuyulong> #startmeeting neutron_l3
14:00:41 <openstack> Meeting started Wed Sep 11 14:00:40 2019 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:44 <openstack> The meeting name has been set to 'neutron_l3'
14:01:39 <liuyulong> #chair liuyulong_
14:01:39 <openstack> Current chairs: liuyulong liuyulong_
14:02:09 <liuyulong> #chair haleyb
14:02:09 <openstack> Current chairs: haleyb liuyulong liuyulong_
14:02:14 <liuyulong> #chair slaweq
14:02:15 <openstack> Current chairs: haleyb liuyulong liuyulong_ slaweq
14:02:23 <haleyb> hi
14:02:26 <liuyulong> Just in case, :)
14:02:52 <liuyulong> #topic Announcements
14:03:24 <liuyulong> I have no announcement this week.
14:04:29 <liuyulong> If you guys have, please tap the keyboard directly. : )
14:05:07 <ralonsoh> hi
14:05:12 <slaweq> I have one short thing
14:05:21 <slaweq> (or 2)
14:05:28 <slaweq> just a reminders:
14:05:30 <slaweq> Shanghai PTG planning etherpad
14:05:32 <slaweq> https://etherpad.openstack.org/p/Shanghai-Neutron-Planning
14:05:38 <slaweq> Shanghai Forum brainstorming etherpad
14:05:40 <slaweq> https://etherpad.openstack.org/p/neutron-shanghai-forum-brainstorming
14:05:49 <slaweq> please put there Your proposals for topics
14:06:54 <slaweq> that's all from me :)
14:07:49 <liuyulong> I have a lot of ideas.
14:09:43 <liuyulong> Any other announcements?
14:09:53 <liuyulong> OK, let's move on.
14:10:05 <liuyulong> #topic Bugs
14:11:00 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009261.html
14:11:19 <liuyulong> Nate Johnston was our bug deputy last week, thanks.
14:11:30 <njohnston> my pleasure
14:11:53 <liuyulong> Most of those bugs are related to CI. IMO
14:12:48 <njohnston> I agree, I think the one most aligned with L3 is: https://bugs.launchpad.net/bugs/1842937
14:12:49 <openstack> Launchpad bug 1842937 in neutron "Some ports assigned to routers don't have the correspondent routerport register" [Undecided,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:14:00 <liuyulong> Yes, it is
14:15:06 <ralonsoh> sorry, I was in other chat
14:15:16 <ralonsoh> I have a patch in gerrit for this
14:15:17 <ralonsoh> one sec
14:15:34 <ralonsoh> #link https://review.opendev.org/#/c/680413/
14:15:40 <ralonsoh> the point is this patch is not solving the problem
14:15:55 <liuyulong> I'm looking at that. :  )
14:16:07 <ralonsoh> but mitigating it: when the port, during the sync, does not have all the ips (and subnets)
14:16:23 <ralonsoh> although in the Neutron DB the information is correctly populated
14:16:44 <ralonsoh> this patch is forcing the DHCP agent to retrieve, at this point, the correct information from the server
14:16:59 <liuyulong> One small concern is that we may take care of such DB query, do not make it slow like others once we had.
14:17:47 <ralonsoh> that's the point
14:18:03 <ralonsoh> if the port does not have this information, we'll force a full resync
14:18:15 <ralonsoh> this is going to be slower, for sure
14:18:51 <ralonsoh> this is happening ONLY when the port information is not correct/not totally populated
14:19:31 <ralonsoh> eventually, if the port does not have those IPs, the server will generate other IPs and the agent will resync the whole subnet
14:20:57 <liuyulong> This new query is related to remove router interface only?
14:21:17 <ralonsoh> remove? no, we are not removing it
14:21:24 <ralonsoh> the DHCP port is present in the system
14:22:22 <liuyulong> OK, I may have to take a deep look of that patch.
14:22:51 <liuyulong> One more interesting thing is that I noticed our local queens performance, the attach interface API will takes more than 60s+.
14:23:35 <liuyulong> That's will be another story.
14:26:58 <liuyulong> Next
14:27:03 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1843285
14:27:05 <openstack> Launchpad bug 1838760 in neutron "duplicate for #1843285 Security groups don't work for trunk ports with iptables_hybrid fw driver" [High,Confirmed] - Assigned to Slawek Kaplonski (slaweq)
14:27:57 <liuyulong> #undo
14:27:58 <openstack> Removing item from minutes: #link https://bugs.launchpad.net/neutron/+bug/1843285
14:28:09 <liuyulong> Wrong link.
14:29:22 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1842327
14:29:23 <openstack> Launchpad bug 1842327 in neutron "Report in logs when FIP associate and disassociate" [Medium,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:29:34 <liuyulong> This patch looks good to me now.
14:29:58 <liuyulong> For the log one.
14:30:09 <liuyulong> #link https://review.opendev.org/#/c/679667/
14:30:30 <liuyulong> And it has a l3_db change here: https://review.opendev.org/#/c/680976/
14:31:11 <ralonsoh> yes, the second one requested by Terry
14:31:16 <ralonsoh> Ryan
14:31:30 <ralonsoh> and makes sense to implement this patch https://review.opendev.org/#/c/680976/
14:31:52 <ralonsoh> we should have only one place to decide if FIP is associated, disassociated or nothing
14:33:11 <liuyulong> Make sense, I've changed these code a long time ago.
14:34:15 <liuyulong> And once we have a potential consensus which is updating the floating IP by empty "{}" API input, l3 plugin which change nothing, and no errors.
14:35:42 <liuyulong> So please consider such scenario. And maybe make sure that association_event will not be added for such scenario.
14:36:05 <ralonsoh> ok
14:37:59 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1843025
14:38:01 <openstack> Launchpad bug 1843025 in neutron "FWaaS v2 fails to add ICMPv6 rules via horizon" [High,In progress] - Assigned to Brian Haley (brian-haley)
14:38:56 <liuyulong> It is fixed IMO, just need a backport.
14:38:58 <haleyb> i just did a cherry-pick on that one
14:39:42 <haleyb> so maybe it's just a duplicate?
14:40:20 <liuyulong> No, I noticed the bug assignee change, so I have no actions. : )
14:40:57 <liuyulong> OK, that's all bugs from me.
14:41:22 <liuyulong> Any other bugs?
14:42:40 <liuyulong> OK, let's move on.
14:42:47 <liuyulong> #topic On demand agenda
14:43:47 <liuyulong> Last week I started the topic of "IPv6", and I read lots of neutron specs about floating IPv6.
14:44:25 <liuyulong> #link https://review.opendev.org/#/q/status:abandoned+project:openstack/neutron+branch:master+topic:bp/ipv6-router-and-dvr
14:44:58 <liuyulong> #link https://review.opendev.org/#/q/ndp
14:45:25 <liuyulong> We have this merged and implemented:https://review.opendev.org/#/c/139731/
14:46:01 <liuyulong> Bad link, it should be this: https://review.opendev.org/#/c/101306/ "
14:46:02 <liuyulong> Support Router Advertisement Daemon (radvd) for IPv6"
14:46:27 <liuyulong> #link https://review.opendev.org/#/c/139731/
14:46:31 <haleyb> that and floating IPv6 are different things
14:46:39 <liuyulong> this is the spec for floating IPv6.
14:47:06 <liuyulong> haleyb, yes, just a gerrit query. : )
14:47:48 <haleyb> i think only one plugin supports floating IPv6, we had decided years ago not to do it in the core code
14:49:07 <haleyb> is there a use case for doing it?  it's not like there's a shortage of IPv6 addresses :)
14:49:36 <liuyulong> Yes, IIRC, midonet may support floating IPv6.
14:50:52 <liuyulong> After the L3 meeting last week, Donny Davis gave me their IPv6 deployment details.
14:50:55 <haleyb> i know swami has been working on "fast exit" IPv6 w/DVR, which would be useful
14:51:28 <liuyulong> They uses the BGP.
14:52:13 <liuyulong> But it may also need some extra works.
14:52:31 <haleyb> right, it's a good use of BGP, assuming your infrastructure supports it
14:53:10 <liuyulong> 1. Access the public network until the user apply or pay for it.
14:53:32 <liuyulong> 2. Qos for IPv6 traffic to external world.
14:54:39 <liuyulong> Oure IPv4 floating IP has both abilities now.
14:56:23 <haleyb> so floating IP allocation costs $$ ?
14:57:08 <liuyulong> To achive these, neutron may need some new resource "IPv6 address" or "Floating IPv6 Address" and the QoS binding for it.
14:57:31 <liuyulong> haleyb, no, bandwidth costs money.
14:58:15 <haleyb> liuyulong: i was wondering how the user "paid" for external access in 1) above
14:58:26 <haleyb> one way is to charge for a floating IP address
14:59:16 <liuyulong> It can be one way.
14:59:46 <haleyb> i hope not to have floating IPv6
15:00:11 <liuyulong> In my experience, pay for some bandwidth is more popular in China.
15:00:38 <haleyb> we are at time
15:01:01 <liuyulong> OK, then let's end here.
15:01:05 <liuyulong> #endmeeting