14:01:42 <ralonsoh> #startmeeting networking
14:01:42 <opendevmeet> Meeting started Tue Sep 19 14:01:42 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:42 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:42 <opendevmeet> The meeting name has been set to 'networking'
14:01:44 <mlavalle> o/
14:01:45 <ralonsoh> hello all
14:01:51 <rubasov> o/
14:02:02 <elvira> o/
14:02:02 <haleyb> o/ (in another meeting if i'm slow)
14:02:09 <slaweq> o/
14:02:20 <ralonsoh> #topic announcements
14:02:25 <ralonsoh> #link https://releases.openstack.org/bobcat/schedule.html
14:02:34 <ralonsoh> This is the election week
14:02:44 <ralonsoh> but, at least for Neutron, the result is clear!
14:03:10 <ralonsoh> and we have RC1 released
14:03:18 <ralonsoh> along with the stable/2023.2 branch
14:03:22 <slaweq> \o/
14:03:23 <mtomaska> \o\/o/
14:03:31 <lajoskatona> cool
14:03:34 <ralonsoh> we are officially pushing code to Caracal right now
14:03:50 <ralonsoh> so please, remember to make your backports to 2023.2 too, if needed
14:04:12 <ralonsoh> last week, in advance, is the final release of the RC
14:04:32 <ralonsoh> and, as any week, please check the openinfra channel
14:04:35 <ralonsoh> #link https://openinfra.dev/live/#all-episodes
14:04:39 <bcafarel> o/
14:05:00 <ralonsoh> any other heads-up?
14:05:32 <ralonsoh> ok, let's jump to the next topic
14:05:36 <ralonsoh> #topic bugs
14:05:52 <ralonsoh> last week report is from mtomaska
14:05:57 <ralonsoh> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-September/035125.html
14:06:17 <ralonsoh> we have some pending bugs to review, not assigned yet
14:06:25 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2035168
14:06:34 <ralonsoh> I would lower the priority of this one
14:06:52 <ralonsoh> it is interesting to remove these tables but not mandatory
14:07:05 <mtomaska> sure it does not seem to be breaking anything
14:07:30 <ralonsoh> I think this is a low-hanging-fruit for anyone "playing" witht the DB migrations
14:07:38 <lajoskatona> is there a gain if we remove? speed, complexity... ?
14:07:54 <ralonsoh> nothing, to be honest
14:08:02 <ralonsoh> these tables are not consuming resources
14:08:05 <mtomaska> less testing. Maybe I should take a look how long those tests take?
14:08:05 <lajoskatona> ok, so really low hanging fruit
14:08:09 <SvenKieske> deleted code is good code ;)
14:08:14 <lajoskatona> :-)
14:08:29 <ralonsoh> no no, this is not deleting code but adding new migrations
14:08:53 <ralonsoh> ok, next one
14:08:56 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2035578
14:09:06 <ralonsoh> I will ping eolivare to know if he's on this one
14:09:18 <ralonsoh> this one seems to be related to the zuul configuration
14:09:27 <lajoskatona> he left comments on it
14:09:32 <ralonsoh> yes
14:09:56 <ralonsoh> I think they will need to have different zuul configs per stable branch
14:09:59 <ralonsoh> same as other projects
14:10:15 <ralonsoh> to add the supported (or not) OS and nodes to the branches
14:10:32 <ralonsoh> I'll ping him after this meeting
14:10:46 <ralonsoh> next one
14:10:49 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2035230
14:11:06 <ralonsoh> IMO, what is happening is that they are creating a port in a network without subnets
14:11:16 <ralonsoh> that matches with this output
14:11:39 <ralonsoh> but we need more feedback. Just the port creation API result is not enough here
14:12:05 <ralonsoh> in any case, any other review of this problem is always welcome
14:13:18 <ralonsoh> ok, next one
14:13:28 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2035573
14:13:46 <ralonsoh> I've closed this one as duplicated of LP#2016198
14:13:59 <ralonsoh> the problem: the fix for ^^ implies a DB migration
14:14:04 <ralonsoh> so we can't backport it
14:14:35 <ralonsoh> the problem is that if you send multiple HA network creation at the same time, there is a chance of race condition
14:14:51 <ralonsoh> that leads to the creation (try to) create 2 HA networks
14:15:10 <ralonsoh> the fix: create the network and the HAnetwork register in the same DB transaction
14:15:16 <ralonsoh> that guarantees the isolation
14:15:50 <ralonsoh> in any case, please review this one just to be sure I'm right (or not) in my conclusion
14:16:09 <ralonsoh> last one
14:16:14 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2035332
14:16:41 <ralonsoh> a "persistent" issue with OVN+DVR+VLAN networks
14:17:03 <ralonsoh> slaweq, if I'm not wrong, we are going to block that but in some conditions
14:17:10 <ralonsoh> when using port forwarding, right?
14:18:25 <ralonsoh> I'll check this week if the LRP options the bug is describing are correct
14:18:52 <ralonsoh> it is complicated the support matrix of redirect-type, reside-on-redirect-chassis and network types
14:18:54 <slaweq> only when FIP PF are also enabled
14:19:33 <ralonsoh> but I think this folk is misunderstanding the concepts here
14:19:37 <slaweq> https://review.opendev.org/c/openstack/neutron/+/892542
14:19:38 <ralonsoh> "My understanding is that `reside-on-redirect-chassis` is to force traffic to the gateway rather then DVR this should be `True` as Vlan networks will need to go through the chassis gateway for everything where geneve DVR can have this as false to allow for DVR."
14:19:54 <ralonsoh> ^ yes, this one
14:21:23 <ralonsoh> anyway, I'll talk to ltombaso to check if the bug description is correct or there is any misundertanding on how OVN FIP works with VLAN networks
14:21:45 <ralonsoh> I don't have any other bug in this list
14:21:52 <ralonsoh> do you have any other pending bug?
14:22:08 <opendevreview> Merged openstack/neutron master: Imported Translations from Zanata  https://review.opendev.org/c/openstack/neutron/+/895526
14:22:40 <aprats-> I don´t know if it is the right time to ask, I'm looking for reviews on this one https://bugs.launchpad.net/neutron/+bug/2029722
14:23:13 <ralonsoh> this one seems to be assigned and a patch submitted
14:23:27 <ralonsoh> if the bug is triaged, let's discuss it an the end of the meeting
14:23:32 <ralonsoh> in the on_demand section
14:23:49 <ralonsoh> This week bcafarel is the deputy, next week will be lajoskatona.
14:23:51 <ralonsoh> akc?
14:23:53 <lajoskatona> ack
14:23:54 <ralonsoh> ack?
14:24:21 <bcafarel> :) ack
14:24:25 <ralonsoh> thanks
14:24:31 <ralonsoh> #topic specs
14:24:46 <ralonsoh> because we are starting a new release (while closing the last one)
14:24:53 <ralonsoh> let's start reviewing the pending specs
14:24:58 <ralonsoh> #link https://review.opendev.org/q/project:openstack%252Fneutron-specs+status:open
14:25:11 <ralonsoh> we have "Add spec for partial support for OVN Interconnect RFE" on the plate
14:25:30 <ralonsoh> please let's continue with the revision efforts from the last release
14:26:10 <ralonsoh> ok, let's jump to the next topic
14:26:18 <ralonsoh> #topic community_goals
14:26:33 <ralonsoh> I'll skip the first one, "Add support for the service role in neutron API policies"
14:26:39 <ralonsoh> 2) Neutron client deprecation
14:26:43 <ralonsoh> lajoskatona, any update?
14:26:51 <lajoskatona> nothing since last week
14:27:02 <lajoskatona> The pending patches to neutronclient were merged
14:27:20 <lajoskatona> I have to jump into this topic and allocate some time to it
14:27:26 <lajoskatona> that's it
14:27:28 <ralonsoh> perfect, I'll remove them from the meeting logs
14:27:38 <ralonsoh> lajoskatona, thanks a lot
14:27:53 <ralonsoh> ok, last section
14:27:57 <ralonsoh> #topic on_demand
14:28:02 <ralonsoh> aprats-, please
14:29:02 <ralonsoh> aprats-, I think you wanted to talk about https://bugs.launchpad.net/neutron/+bug/2029722
14:29:05 <aprats-> Thx, pushed here https://review.opendev.org/c/openstack/neutron/+/890459, I just wanted to know what to do next so I can have this change merged :)
14:29:49 <lajoskatona> coming to IRC and advertising it is a good step :-)
14:29:57 <mlavalle> yes!
14:30:12 <ralonsoh> so if I'm not wrong, what you want is to have multiple nating
14:30:15 <ralonsoh> from https://launchpadlibrarian.net/680342877/Screenshot%20from%202023-08-02%2009-30-17.png
14:30:26 <ralonsoh> subnet B - subnet A - internet
14:30:28 <ralonsoh> right?
14:30:42 <aprats-> Only router-ext is natting
14:31:13 <ralonsoh> why not router LAN?
14:31:14 <aprats-> But yes, I want to have the subnet B to be able to use the nat of subnet A (If that make sense)
14:31:56 <aprats-> Some of our clients wanted to make some kind of DMZ with the subnet A
14:32:59 <ralonsoh> I think you'll need to add routes inside the VM to access to the subnet A interface
14:33:08 <ralonsoh> and from there, access the external GW
14:33:51 <ralonsoh> but if router LAN is nating between two internal networks, that won't add any default GW
14:34:14 <aprats-> Yes but it won't work, that's why I submitted this PR. We have a rule on the dvr that will only route traffic from directly attached networks
14:34:46 <ralonsoh> yes because this is the goal of the router for internal networks
14:35:06 <ralonsoh> the router won't egress any traffic via subnet A as a external network
14:35:45 <ralonsoh> unless, maybe, you mark IP 10.20.0.1 (router ext, subnet A) as GW of the VMs
14:36:03 <ralonsoh> did you try that?
14:36:37 <aprats-> Just to be clear, adding 0.0.0.0/0 via 10.20.0.1 on the router lan routes will solve the routing issue from test_lan to the router_ext
14:36:54 <ralonsoh> exactly
14:37:05 <ralonsoh> so what's the problem then?
14:37:07 <aprats-> Then there is still an issue, router_ext dvr won´t nat subnet B traffic
14:37:22 <aprats-> And that's this behavior that my code fixes
14:38:17 <ralonsoh> the problem is that your patch is adding snat to a router between internal networks
14:39:46 <ralonsoh> and that is not how it should work
14:39:46 <ralonsoh> actually you are adding this in the DVR router namespace only...
14:40:17 <ralonsoh> (sorry)
14:41:33 <ralonsoh> aprats-, I'm not sure about this code (and the lack of testing). I would need to deploy an environment to test it first, just to know that we don't introduce any strange backdoor there
14:41:35 <aprats-> From my point of view i'm not adding snat capabilities to an privte to private router. I'm whitelisting linked networks to use an actual snat
14:42:37 <ralonsoh> just one last question (we can discuss this offline)
14:42:39 <aprats-> Perhaps it needs more testing, perhaps it's not not in the right place (I'm fairly new here) and i'm willing to learn :)
14:42:56 <ralonsoh> how a router between two private network will have a GW?
14:43:03 <aprats-> It has not
14:43:06 <ralonsoh> if self._get_gw_ips_cidr():  # Check if router has a gateway
14:43:23 <aprats-> This code impact router_ext not router_lan
14:44:12 <ralonsoh> ok, as I said, I'll need manual testing (and better description and documentation in this patch)
14:44:21 <haleyb> sorry, am in another meeting, but i think it's a valid bug, but like aprats- mentioned, it seems there is a cleaner place to put this i just don't see it yet
14:44:50 <haleyb> but we can follow-up in the patch
14:44:50 <aprats-> What it does is that it lists routes on a external router and will allow networks routed to use the external gateway
14:45:14 <haleyb> s/routes/rules from what i remember right?
14:45:37 <ralonsoh> let's continue that in the patch
14:45:41 <haleyb> ack
14:45:49 <aprats-> ack
14:45:50 <ralonsoh> any other topic?
14:45:58 <haleyb> i had a quick one
14:46:02 <ralonsoh> please
14:46:30 <haleyb> now that 2024.1 is open, i did two patches for testing updates
14:46:43 <haleyb> https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/895516 to add 2023.2 tempest jobs
14:47:02 <haleyb> https://review.opendev.org/c/openstack/neutron/+/895515 for adding SLURP jobs
14:47:10 <haleyb> any reviews would be great
14:47:22 <frickler> note that devstack and grenade aren't ready yet for 2023.2
14:47:29 <ralonsoh> right, this is the second SLURP release
14:48:22 <lajoskatona> frickler: thanks for the info
14:49:36 <haleyb> frickler: so do you mean i can't checkout stable/2023.2 in devstack and install? haven't looked actually
14:49:46 <frickler> there is no branch yet
14:49:58 <frickler> waiting for nova and requirements repos to branch
14:50:14 <frickler> nova should hopefully get done later today
14:51:08 <slaweq> haleyb thx, I just commented in Your patch for neutron-tempest-plugin
14:51:20 <ralonsoh> but for now, the Neutron patch is valid and can be merged (I left a comment)
14:51:45 <haleyb> right, i figured after some time we could make it voting, will need to update CI dashboard
14:52:12 <ralonsoh> ok, any other topic
14:52:41 <ralonsoh> please remember that today there won't be CI meeting
14:52:48 <mlavalle> yeap
14:52:56 <ralonsoh> but if you have something urgent, you can ping anyone here in this channel
14:53:04 <ralonsoh> thank you for attending
14:53:13 <ralonsoh> #endmeeting