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