14:00:17 <slaweq> #startmeeting networking 14:00:17 <opendevmeet> Meeting started Tue Aug 8 14:00:17 2023 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 <opendevmeet> The meeting name has been set to 'networking' 14:00:21 <mlavalle> o/ 14:00:24 <lajoskatona> o/ 14:00:25 <slaweq> ping bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:00:26 <slaweq> o/ 14:00:28 <frickler> \o 14:00:30 <obondarev> o/ 14:00:35 <rubasov> o/ 14:00:38 <ykarel> o/ 14:00:42 <haleyb> o/ 14:00:50 <slaweq> ralonsoh is still off so I will chair today's meeting again 14:01:01 <bcafarel> o/ 14:01:24 <slaweq> I think we can start as we have pretty many folks there already 14:01:26 <slaweq> #topic announcements 14:01:41 <sahid> o/ 14:01:53 <slaweq> I just have regular reminder about release schedule 14:01:56 <slaweq> Bobcat / 2023.2 schedule: https://releases.openstack.org/bobcat/schedule.html 14:02:07 <slaweq> Next milestone is Aug 21-Aug 25 - Final release for non-client libraries 14:02:58 <slaweq> and also PTL and TC nominations will start in 3 weeks (also Aug 21-Aug 25) - please consider preparing Your nomination if You are interested in one of those positions 14:03:12 <slaweq> that's all announcements from me today 14:03:16 <slaweq> do You have anything else? 14:04:12 <slaweq> I guess this means "no" :) 14:04:15 <slaweq> #topic bugs 14:04:38 <slaweq> lucasagomes was bug deputy last week but he forgot to sent summary email 14:04:51 <slaweq> I just pinged him about it before this meeting so please expect email before EOD today 14:05:02 <lucasagomes> sorry folks, I will submit it soon! 14:05:11 <slaweq> in the meantime do You have any bugs You would like to discuss now? 14:05:26 <slaweq> or maybe lucasagomes have already something what would like to bring up here? 14:05:45 <frickler> amorin wanted to discuss one 14:05:51 <lucasagomes> I just started looking into the list, if I find something in the meantime I will bring it up 14:05:55 <amorin> hello! 14:06:00 <frickler> https://bugs.launchpad.net/neutron/+bug/2029722 14:06:02 <amorin> thanks for the ping :) 14:06:06 <slaweq> hi amorin 14:06:26 <amorin> yup, we discoverd something when using DVR 14:06:47 <amorin> some ip rules are set in order to reach the external gateway of the subnet 14:07:09 <amorin> in a 2 routers architecture, with custom routing rules, it prevent the routing to reach the gw correctly 14:07:15 <amorin> this is not affected no DVR 14:07:24 <amorin> this is not affecting* no DVR 14:07:46 <amorin> we were wondering if someone know why, for DVR, we are using the ip rule to reach the gw 14:07:55 <amorin> and a different routing table 14:07:59 <amorin> instead of the default one 14:09:22 <slaweq> I see that haleyb already started looking at it and I guess that he and maybe obondarev are the best guys to ask why it was originally done like that 14:09:53 <obondarev> there is a great set of articles describing DVR mechanism by Assaf Muller: https://assafmuller.com/category/dvr/ - amorin you may find answers there 14:10:17 <amorin> ack, will read that 14:10:23 <haleyb> it's been a while, but there are typically ip rules to deal with scoping of addresses. 14:10:28 <obondarev> currently I don't remember this detail on ip rule, sorry 14:10:48 <amorin> we implemented a patch to add an extra rule, it works 14:11:05 <amorin> but if the original idea of ip rule is not needed anymore, maybe we can totally get rid of it 14:11:27 <haleyb> as i mentioned in the patch, it could be a certain order of things shows the bug, sometimes we just don't account for things correctly 14:12:28 <haleyb> i think the rules are needed to account for address scopes 14:14:35 <slaweq> amorin so You can probably read Assaf's blog posts about it and we can continue that discussion in the LP and gerrit, is that ok for You? 14:14:37 <haleyb> we can just follow-up in the patch and bug, but i am following it 14:14:47 <amorin> sounds good, thanks 14:15:33 <slaweq> thx amorin for bringing it up here and thx haleyb for taking care of that LP 14:15:39 <slaweq> ok, I think we can move on 14:15:49 <slaweq> #topic community_goals 14:15:58 <slaweq> Consistent and Secure Default RBAC 14:16:29 <slaweq> Patch https://review.opendev.org/c/openstack/neutron/+/886724 should be ready to review now - it still requires neutron-lib bump in the upper-contraints but other than that it looks ok 14:16:41 <slaweq> so please take a look at it if You will have few minutes 14:16:56 <slaweq> I would like to hopefully get it merged in this cycle 14:17:13 <slaweq> next one 14:17:15 <slaweq> Neutron client deprecation 14:17:22 <slaweq> lajoskatona any updates on this one? 14:17:38 <lajoskatona> not much, I worked on the sfc part 14:17:49 <lajoskatona> this is for SDK: https://review.opendev.org/c/openstack/neutron/+/886724 14:18:08 <lajoskatona> the usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation 14:18:25 <lajoskatona> please check it, the patches without a 'tick' are something to review 14:19:03 <lajoskatona> this one for fwaas is ready: https://review.opendev.org/c/openstack/python-neutronclient/+/880629 as SKd was released for it 14:19:06 <slaweq> lajoskatona I think You gave wrong link "for SDK" :) 14:19:44 <lajoskatona> sorry, my mind was faster :-) 14:19:54 <slaweq> :) 14:20:12 <lajoskatona> otherwise I started to look into Horizon, and started to play to have SDK behind it 14:20:32 <lajoskatona> that's it for this topic from me 14:20:40 <slaweq> thx 14:20:50 <slaweq> I will finally try to find time to review those patches this week 14:21:06 <slaweq> with that I think we can move on 14:21:07 <lajoskatona> thanks in advance 14:21:11 <slaweq> to the next topic, which is 14:21:20 <slaweq> #topic on_demand 14:21:33 <slaweq> do You have any other neutron related topics to discuss today? 14:21:46 <mlavalle> nope 14:21:49 <frickler> I have a question about IPv6 metadata 14:21:58 <slaweq> frickler sure 14:22:18 <frickler> I see the tests are only done for OVS, and in my local test it doesn't work for OVN, is that a known gap? 14:22:51 <slaweq> yes, it is 14:22:59 <slaweq> OVN metadata agent don't support it (yet) 14:23:08 <frickler> so it is missing in the gap document 14:23:12 <slaweq> I have it on my todo list but not with high priority for now 14:23:36 <slaweq> right, I think we forgot about gaps document 14:23:39 <slaweq> to add it there 14:24:16 <frickler> ok, I can do a patch, need to add some DNS gaps, too, it seems 14:24:25 <frickler> also haleyb do you still plan to followup with https://review.opendev.org/c/openstack/neutron/+/876903 ? 14:24:26 <slaweq> thx frickler 14:24:51 <haleyb> frickler: i need to abandon that and work on a different fix, that didn't work :( 14:25:18 <haleyb> and we don't need to switch to the ec2 one 14:25:47 <opendevreview> Lucas Alvares Gomes proposed openstack/neutron master: [OVN] ovn-db-sync check for router port differences https://review.opendev.org/c/openstack/neutron/+/890799 14:25:50 <frickler> well not switch but add it as an option I though would be a good idea? 14:26:04 <frickler> *thought 14:26:39 <haleyb> i think the problem was that there is no dhcp response value for host routes in ipv6, so it doesn't work 14:27:22 <haleyb> and there was an issue with dnsmasq and addressing, just making sure one host at a time configures the address should be enough 14:27:29 <frickler> but do you need a specific route? wouldn't the default route from the RA be enough? 14:27:56 <haleyb> not when you have an isolated subnet, which is where the dnsmasq issue got into play 14:28:16 <racosta> In the IPv6-only case, the VM generates an LLA address automatically, and this local scope address is not known by ovn-southbound and neutron. At this point we have a hard time! In the current architecture, the metadata makes a proxy and uses the local address of the VM to find the corresponding port to forward and receive the traffic (Port_Binding table) - OVN case. 14:28:18 <haleyb> we decided to just fix it a different way 14:28:26 <frickler> ah, ok, maybe split those topics, then 14:29:54 <haleyb> i'll try and work on that in the next few weeks 14:30:13 <frickler> o.k., I'll wait for that, thx 14:31:25 <slaweq> ok, thank You both for bringing it up here and working on it 14:31:41 <slaweq> I also have 2 quick topics for today on demand section 14:32:13 <slaweq> first one, which I wanted to discuss also with ralonsoh but as he's not here yet, I will ask whole team here: 14:32:14 <slaweq> Do we want to add neutron-core to the openstacksdk/OSC "service-core" group? 14:32:20 <slaweq> See https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034608.html for more details 14:32:28 <slaweq> example patch in project-config: https://review.opendev.org/q/topic:add-cinder-core 14:32:56 <lajoskatona> good idea 14:32:57 <slaweq> IMO it would be good idea to add neutron-core team to that SDK/OSC group also but I wanted to know Your opinion about it 14:33:08 <mlavalle> good idea 14:33:13 <frickler> we have some individuals already added I think 14:33:25 <obondarev> +1 to add 14:34:21 <slaweq> frickler yes, I think that I am there and amotoki 14:34:28 <slaweq> but still having all neutron-cores in that service-core group would be good IMO 14:34:53 <frickler> yes, I'm all for it, just wanted to mention that it could simplify the list a bit 14:35:05 <slaweq> thx 14:35:43 <slaweq> ok, I will propose such patch and also ask ralonsoh to review it as Neutron PTL 14:35:52 <slaweq> and now second topic 14:36:42 <slaweq> As You probably noticed it's that time of the year where user survey questions are going to be prepared for next surver. We have list of current questions, see https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034596.html for details 14:37:00 <slaweq> and we have time until 18th of Aug to propose some changes there in Neutron related questions 14:37:48 <slaweq> I would like to ask You all to check what's there currently and maybe we can discuss about it on the next week's team meeting if we want to change something there 14:37:57 <slaweq> will that work for You? 14:38:29 <lajoskatona> +1 14:39:02 <frickler> can someone copy the questions into an etherpad? 14:39:26 <slaweq> frickler yes, I will prepare etherpad with those questions today or tomorrow morning 14:39:29 <mlavalle> will look at it 14:39:34 <slaweq> and will send link to it in this channel 14:39:38 <lajoskatona> thanks slaweq 14:39:40 <frickler> cool, thx 14:40:37 <slaweq> and with that we came to the end of the agenda for today 14:40:57 <slaweq> if You don't have any other topics for today, I will give You some time back 14:41:06 <mlavalle> \o/ 14:41:07 <slaweq> and please remember about CI meeting in 19 minutes 14:41:12 <slaweq> it will be on video this week 14:41:16 <lajoskatona> ack 14:41:18 <mlavalle> ack 14:41:19 <slaweq> #endmeeting