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