14:00:21 <liuyulong> #startmeeting neutron_l3
14:00:21 <openstack> Meeting started Wed Sep  4 14:00:21 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:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:25 <openstack> The meeting name has been set to 'neutron_l3'
14:00:36 <njohnston> o/
14:00:40 <liuyulong> hi
14:00:45 <haleyb> hi
14:01:17 <liuyulong> #chair haleyb
14:01:18 <openstack> Current chairs: haleyb liuyulong
14:01:21 <liuyulong> #chair liuyulong_
14:01:22 <openstack> Current chairs: haleyb liuyulong liuyulong_
14:01:32 <liuyulong_> #topic Announcements
14:01:58 <ralonsoh> hi
14:02:33 <slaweq> hi
14:02:40 <liuyulong> I have no announcement this week.
14:03:08 <liuyulong> One thing to share is my "Travel Support" are accepted.
14:03:43 <liuyulong> I have received a reservation for the flights.
14:04:49 <slaweq> liuyulong: so You will be in Shanghai for sure, right?
14:04:59 <liuyulong> If you have applied, you should have same notification email.
14:05:04 <liuyulong> slaweq, yes, I will be there.
14:05:12 <slaweq> great
14:05:29 <liuyulong> OK, next topic.
14:05:35 <liuyulong> #topic Bugs
14:06:06 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009002.html
14:06:25 <liuyulong> Lajos Katona was our bug deputy last week, thanks.
14:07:10 <liuyulong> IMO, most of them were talked in last meeting.
14:08:09 <slaweq> liuyulong: there was no meeting this week
14:08:19 <liuyulong> And we have critical bugs today.
14:08:36 <slaweq> ahh, sorry, You are talking about last L3 meeting :)
14:08:37 <liuyulong> slaweq, I mean L3 meeting last week. : )
14:08:43 <slaweq> yes, sorry
14:09:10 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1842482
14:09:11 <openstack> Launchpad bug 1842482 in neutron ""test_get_devices_info_veth_different_namespaces" fails because veth1_1 interface has a link device in the same namespace" [Critical,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:09:39 <ralonsoh> yes, path under review
14:09:41 <ralonsoh> one sec
14:09:47 <liuyulong> I have take a look for the fix https://review.opendev.org/679917 and https://review.opendev.org/679939
14:09:57 <ralonsoh> #link https://review.opendev.org/#/c/679939/
14:10:02 <ralonsoh> no no, PS2 of https://review.opendev.org/#/c/679939/
14:10:27 <liuyulong> They are same now except commit message.
14:10:34 <ralonsoh> not now
14:10:43 <ralonsoh> please, review PS2
14:10:45 <liuyulong> OK
14:11:58 <liuyulong> I see now, a new upload at the meeting begining.
14:13:04 <liuyulong> Add seems we now have the root cause.
14:13:59 <liuyulong> We need some compatibilities for new kernel version?
14:14:14 <ralonsoh> well, I can't see in iproute2 where this is changing
14:14:22 <ralonsoh> but at least we can contain it
14:14:58 <slaweq> ralonsoh: I don't think it's in iproute2 directly, I was comparing packages versions on passed and failed job's node and iproute2 was the same
14:15:22 <slaweq> kernel was different
14:15:26 <ralonsoh> slaweq, pffff now I'm lost
14:15:42 <ralonsoh> yes, I know this but where is the problem/change?
14:16:03 <ralonsoh> actually now it's working as it should
14:16:05 <liuyulong> But do we have 3.x kernel functional test now?
14:16:20 <ralonsoh> using centos images
14:17:08 <ralonsoh> but the change is from  4.15.0-55-generic to 4.15.0-60-generic
14:17:25 <slaweq> liuyulong: in u/s CI we don't have any functional job running on Centos
14:17:31 <slaweq> only Ubuntu
14:17:39 <slaweq> we have one scenario job running on Fedora
14:18:07 <slaweq> and one job running on Centos which uses TripleO installer instead of devstack (this one is non-voting)
14:18:43 <liuyulong> This two jobs can hit this code path?
14:19:23 <ralonsoh> this test is the only place in Neutron using this parameter
14:19:44 <ralonsoh> could be excessive, but I implemented it to fully check the feature
14:22:00 <liuyulong> I mean the real code path, not the test case. The 3.x kernel should not care about this issue found by this gate failure?
14:23:04 <ralonsoh> I don't know, for now, this is the only problem found
14:24:48 <liuyulong> How about add functional test for centos? Maybe fullstack test as well?
14:25:41 <ralonsoh> what this fullstack test will check?
14:27:12 <liuyulong> ralonsoh, fullstack is not related to this case. It is just an new quality assurance for neutron in centos.
14:27:18 <slaweq> liuyulong: as I would like to have more tests on Centos instead of Ubuntu, I'm not sure if we can add yet another jobs just with different OS TBH :)
14:28:25 <liuyulong> What's the next kernel version for CentOS 8.x ?
14:28:26 <haleyb> slaweq: maybe we can move the fedora ones to centos?
14:29:00 <slaweq> haleyb: You mean neutron-tempest-iptables_hybrid-fedora ?
14:29:07 <slaweq> to be neutron-tempest-iptables_hybrid-centos
14:29:09 <slaweq> ?
14:29:41 <haleyb> yes, maybe the other one i was thinking of was in ovn
14:30:49 <slaweq> haleyb: TBH I'm not sure if it's good idea
14:31:03 <slaweq> maybe when Centos 8 will be released we can change it
14:31:24 <slaweq> but I think that is more topic for CI meeting instead of L3 :)
14:31:40 <haleyb> :)
14:32:18 <liuyulong> In my own experience, OpenStack clouds are mostly deployed on CentOS in China. But the community user survey shows it is Ubuntu.
14:34:29 <liuyulong> CentOS 8.x will use the 4.1x+ kernel according to RHEL 8 news.
14:35:50 <liuyulong> OK, I have no bugs today.
14:35:59 <liuyulong> Any updates?
14:38:40 <liuyulong> OK, let's move on.
14:38:45 <liuyulong> #topic On demand agenda
14:39:00 <liuyulong> I'd like to query some information about IPv6.
14:40:03 <liuyulong> How does your cloud use the neutron current IPv6 stack?
14:40:54 <ralonsoh> (my cloud has 2 servers, sorry)
14:40:56 <haleyb> in what way?  external traffic?
14:41:21 <liuyulong> Yes, mostly external traffice.
14:42:02 <liuyulong> ndp proxy has been used?
14:42:48 <liuyulong> neutron does not have such proxy now.
14:43:01 <haleyb> afaik, instances doing external IPv6 use provider networks
14:43:13 <liuyulong> A flat network for IPv6?
14:43:33 <haleyb> prefix delegation is the best way to connect externally
14:44:30 <clarkb> donnyd and logan- both run clouds with ipv6 as primary VM connectivity method for us and can likely share their approaches
14:44:32 <haleyb> liuyulong: well, just an external shared network
14:45:24 <donnyd> FN uses the BGP agent and I run BGP on my edge
14:45:35 <liuyulong> Instance with multiple NICs, and one have IPv6 address from such network. It is one solution. : )
14:46:42 <haleyb> donnyd: nice, thanks for the info. liuyulong - so we might want to talk to tidwellr
14:46:45 <liuyulong> donnyd, what's that 'FN' stand for?
14:47:16 <donnyd> This way I am able to properly do tenant networking and use routers for each tenant. The neutron dynamic routing agent adds BGP routes at my edge for each tenant when the router is connected
14:47:21 <donnyd> Fort Nebula
14:47:55 <donnyd> Happy to share more in depth if needed
14:48:17 <liuyulong> donnyd, so do you mean the "neighbor discovery" will be implemented by using bgp?
14:49:34 <donnyd> no. I mean the tenant networks all get their own /64 and that /64 is advertised at the edge router via bgp
14:49:48 <donnyd> inside the tenant they use DHCP stateless
14:50:23 <donnyd> liuyulong: We can take this offline if clarkb wants to get back to the meeting
14:51:04 <liuyulong> donnyd, thank you very much for your sharing.
14:51:39 <liuyulong> Our locally implementation is now tring to enable ndp_proxy in edge router.
14:52:04 <liuyulong> s/trying
14:52:45 <liuyulong> And we can also do some QoS work in this edge router, something like floating IP.
14:53:43 <haleyb> liuyulong: i think there were some old patches to do proxy NDP, many years ago, don't know if i can find them
14:53:55 <liuyulong> But looks BGP is easy to use, : )
14:54:06 <donnyd> Better to do QOS somewhere else
14:54:14 <donnyd> so it scales with the rest of the infra
14:54:42 <donnyd> and in my model all the security group stuff still works, and you could even use FWaaS and it would probably work without issue
14:55:32 <donnyd> I have ran into a couple issues with it, but as you can see from the Openstack CI.. it works
14:55:46 <liuyulong> security group is in compute node, it should not be influenced.
14:56:15 <liuyulong> donnyd, may I get a link for this?
14:56:46 <donnyd> https://docs.openstack.org/neutron-dynamic-routing/latest/
14:57:15 <haleyb> liuyulong: you would probalby need to look as the "IPv6 Fast Exit" patch as well if you're using DVR
14:58:40 <liuyulong> haleyb, OK, add me to the list
14:59:02 <haleyb> https://review.opendev.org/#/c/662111/
14:59:29 <liuyulong> for the ndp_proxy we also meet some issue which is related to the ipv6 neigh table.
14:59:40 <liuyulong> OK, let's end here.
14:59:47 <liuyulong> #endmeeting