14:00:52 <haleyb> #startmeeting networking 14:00:52 <opendevmeet> Meeting started Tue Aug 27 14:00:52 2024 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:52 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:52 <opendevmeet> The meeting name has been set to 'networking' 14:00:53 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:56 <mlavalle> \o 14:01:01 <rubasov> o/ 14:01:06 <ralonsoh> hello 14:01:08 <obondarev> o/ 14:01:09 <sean-k-mooney> o/ 14:01:13 <ihrachys> o/ 14:01:13 <elvira> o/ 14:01:13 <ykarel> o/ 14:01:46 <haleyb> #topic announcements 14:02:24 <haleyb> I had forgotten to mention i was going to be out yesterday, i'll catch-up with the pings today 14:02:33 <frickler> \o 14:02:41 <haleyb> I will also be out Thursday but will at least change my nick :) 14:02:44 <cbuggy> o/ 14:02:54 <slaweq> o/ 14:03:05 <haleyb> We are now in Dalmatian release week (R - 5) 14:03:11 <haleyb> Work on libraries should be wrapping up! 14:03:24 <haleyb> Non-client library freeze was last week 14:03:32 <haleyb> Client library freeze: August 29th 14:03:39 <haleyb> Dalmatian-3 milestone: August 29th 14:04:09 <haleyb> Only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL 14:04:24 <haleyb> i.e. after D-3 14:04:44 <ihrachys> what's the timeline for release branch spin-off? 14:05:49 <haleyb> when they will tag it? that should be thursday 14:06:01 <lajoskatona> o/ 14:06:36 <ihrachys> sorry. was the note about master branch applying to client / lib only? 14:07:24 <ihrachys> context: I have a feature. I don't have a requirement to land it for dalmatian. but I would like to be able to land it earlier. so if master is locked, I'd like to understand when it gets unlocked. 14:08:41 <frickler> branch creation patches will be proposed next week by the release team iiuc 14:08:56 <haleyb> ihrachys: what is the feature? we can discuss exceptions 14:09:16 <ralonsoh> the stable branches are proposed by the release team 14:09:20 <ihrachys> the nested snat thingy for ovn. 14:09:22 <haleyb> frickler: so next thursday? everything seems to be on a thursday 14:09:26 <ihrachys> frickler: ah ok so a matter of a week or two 14:09:31 <ralonsoh> and should be this thursday 14:09:47 <haleyb> ihrachys: i'd call that a bug fix not a feature 14:10:28 <slaweq> frickler aren't branches created during the RC-1 week? 14:11:02 <slaweq> and according to https://releases.openstack.org/dalmatian/schedule.html is in 2 weeks 14:11:10 <slaweq> not next week 14:11:39 <frickler> slaweq: this is the proposal task https://etherpad.opendev.org/p/dalmatian-relmgt-tracking#L352 14:11:39 <ralonsoh> right 14:11:50 <haleyb> i think i still have vacation on the brain, yes that schedule is the best place for info 14:11:51 <frickler> they then have some time to get approved or amended if needed 14:12:54 <haleyb> RC-1 target week is R-3, which is in two weeks, so basically features should be done (or exceptions filed) by this week, continue fixing bugs for 2 weeks 14:13:17 <slaweq> ahh, ok, so next week it will be for libraries 14:13:41 <slaweq> and branch for e.g. neutron will be created in R-3 week which is in 2 weeks 14:14:05 <haleyb> libraries should be tagged this week, R-5 14:15:36 <haleyb> sorry if i confused anyone, but the schedule slaweq linked is the source of truth 14:16:58 <haleyb> one thing i will mention is if you have any cycle highlights i will start making a short list, please ping me if you have something that should make that list 14:17:44 <haleyb> Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers 14:17:56 <slaweq> please remember that cycle highlights should be "marketing oriented list of features", not very technical one 14:19:22 <haleyb> right, that might be a short list, and as i remember we only include 2-3 at the most anyways 14:20:26 <slaweq> yeap 14:20:38 <haleyb> i did not have any other announcements, does anyone else? 14:21:26 <haleyb> i think nominations for PTL/TC elections end tomorrow, please see the ML email which has more info 14:22:28 <haleyb> looks like there are only 3 nominations for 4 TC openings at the moment 14:22:33 <slaweq> yes, tomorrow at 23:45 utc 14:22:46 <slaweq> There is 4 nominations for TC already 14:23:07 <slaweq> but anyone is welcome to nominate themself :) 14:23:17 <haleyb> oh, ok, your email was at 3am my time so a lot has happened :) 14:23:53 <mlavalle> we live in the past this side of the pond 14:23:55 <slaweq> yes, after I sent it, there was 4th nomination proposed so that has changed already 14:23:57 <frickler> yes, this morning we were at 31% PTL candidacies, this is looking a bit better now 14:23:57 <slaweq> :) 14:24:25 <lajoskatona> mlavalle: :D 14:25:20 <haleyb> I did have one more announcement regarding priorities for the rest of the cycle... 14:25:26 <haleyb> Please use the priorities dashboard for patches in the "ready to merge" state. This could be older changes as well as new ones 14:26:00 <haleyb> so set RP+1 - that way we can check that dashboard and get it reviewed 14:27:04 <haleyb> that was all i had, can move to bugs 14:27:13 <haleyb> #topic bugs 14:27:24 <haleyb> rubasov was the bug deputy last week, his report is at 14:27:32 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3HPRIASSKJPRRMFU6XBACVNE5EXDJR6M/ 14:27:36 <mlavalle> rememeber to set RP+1 again if your submit a revision to your patch 14:28:05 <haleyb> mlavalle: oh, it gets cleared? 14:28:15 <rubasov> ovn-octavia maintainers please have a look at the untriaged bug 14:28:17 <mlavalle> yes, I made that mistake last night 14:28:44 <rubasov> I'll follow up with Anton on the incomplete one, when he responds 14:28:57 <rubasov> otherwise all new bugs are assigned 14:29:38 <haleyb> i did not see this one assigned, unless anton will also take that over? 14:29:42 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2077533 14:29:54 <haleyb> regarding DVR router processing 14:30:07 <rubasov> that's the incomplete - at least that's how I understood it 14:30:44 <haleyb> ack, i'll just follow it 14:31:15 <rubasov> but please correct me there if you think differently 14:31:38 <haleyb> there was one related to fwaas and IPv6 cidrs, which almost seemed like a bug 14:31:41 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2077596 14:31:55 <haleyb> rubasov: no, that's fine 14:32:46 <rubasov> we had a previous similar one handled as an rfe, because there was an api behavior change 14:33:27 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/1869129 14:33:31 <rubasov> I believe that's why the reporter opened it as an rfe, however he did not write about yet his proposed change (I assume it would similarly involve an api behavior change) 14:33:58 <haleyb> i hadn't noticed we tagged that as an rfe due to the nature of the change, but makes sense 14:35:16 <haleyb> i will re-read and see what Liu's response it 14:37:13 <slaweq> I think we had discussion about that long time ago and we added "normalized_cidr" field to the SG rule 14:37:29 <slaweq> to make people aware what is really set by the backend 14:37:57 <haleyb> slaweq: right, thanks for the reminder 14:38:17 <ihrachys> curious - did we talk to ovn then to see if they should just support it? 14:38:39 <slaweq> it was related to the RFE you linked already https://bugs.launchpad.net/neutron/+bug/1869129 14:41:27 <haleyb> ihrachys: the review was https://review.opendev.org/c/openstack/neutron/+/736386 14:43:13 <ihrachys> looks like horizon UX concerns were pushed down to neutron. I guess the ship has sailed. 14:43:53 <sean-k-mooney> kind of 14:44:11 <sean-k-mooney> so conceptually the neturon api should be concistent acrros backends 14:44:48 <sean-k-mooney> i.e. if openstack security group rule create --protocol icmp --remote-ip 10.10.10.175/32 cidr 14:45:03 <sean-k-mooney> is valide for one backend it should be valid for all of them that supprot security groups 14:45:26 <haleyb> it is now after that change i believe 14:45:35 <sean-k-mooney> ah ok 14:45:53 <sean-k-mooney> we have a similar probelm in nova related to regex matchs in list ectra 14:46:07 <sean-k-mooney> the regex has to be in the db's native format... 14:46:41 <haleyb> job security :) 14:46:41 <sean-k-mooney> it shoudl be normalise vai a standar pcre step good to know cidrs are now normalised 14:48:01 <haleyb> ralonsoh: i did have a question for you - did your RPC change make the gate better? 14:48:16 <ralonsoh> yes, please check the DNM patch 14:48:33 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/926788 14:48:44 <haleyb> ack, will look after meeting 14:49:14 <haleyb> This week mlavalle is the bug deputy, next week will be ihrachys 14:49:19 <haleyb> is that good for both of you 14:49:24 <noonedeadpunk> hey folks! I'm trying to debug ovn + octavia provider misbehaviour here and got slightly cornered. Maybe you can point me to how it is supposed to work 14:49:28 <mlavalle> yes 14:49:32 <mlavalle> fine with me 14:49:41 <haleyb> just trying to move along since we have 10 minutes left 14:49:57 <ihrachys> haleyb: ok 14:50:01 <haleyb> Current bug count this week: 717, down 5 from last week 14:50:36 <haleyb> noonedeadpunk: someone can sync with you after the meeting perhaps 14:50:49 <haleyb> #topic community-goals 14:52:02 <lajoskatona> I had no time to work on the SDK realted topic last week, so no news from me 14:52:23 <haleyb> ralonsoh: seems like once the RPC change is merged the monkeypatch one will follow. then just the template change? 14:52:27 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/924317/9 14:52:37 <haleyb> for evenlet that is 14:52:49 <ralonsoh> yes, that's correct. Right now there is an issue with the ovn tempest ipv6 job 14:53:12 <ralonsoh> but the other jobs (ovn and ovs) seems to run fine with wsgi 14:53:36 <noonedeadpunk> so the thing is that I'm able to reach octavia backends via VIPs (an unattached port) but somehow FIP is not reachable 14:53:36 <ralonsoh> the next step: to disable eventlet in oslo.service and make the agents run fine... 14:53:45 <ralonsoh> that's all from me 14:53:57 <haleyb> ralonsoh: great, thanks 14:54:12 <noonedeadpunk> though I do see in OVN NAT rules for the port. But what I'm confused about (and not sure if that should matter), is that port is not binded to any gateway node 14:54:29 <lajoskatona> ralonsoh: but that is (make oslo.service eventletless) is for the coming cycles am I right< 14:54:29 <mlavalle> ralonsoh haleyb: should https://review.opendev.org/c/openstack/neutron/+/926922 be in the priority list? 14:54:30 <lajoskatona> ? 14:54:51 <ralonsoh> lajoskatona, yes, we are still reviewing the spec for this change 14:55:16 <ralonsoh> mlavalle, could be, yes, it could be interesting to have in before we end Dalmatian 14:55:18 <haleyb> mlavalle: yes, i was going to review right after meeting so maybe moot if we approve, but will add if not 14:55:47 <mlavalle> yeah, the monkey patch follow up was in the priority list. so it makes sense 14:57:46 <haleyb> so i did have one RBAC question in the community goals section, seems the default override change is still failing the designate job 14:57:50 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/926085 14:58:42 <slaweq> yes, I have it in my todo list to check that locally 14:58:54 <slaweq> but I still didn't had time to get to this yet 14:59:03 <haleyb> slaweq: is that a bug on the neutron or designate side you think? 14:59:16 <johnsom> It passes in the Designate gates 14:59:16 <opendevreview> Ihar Hrachyshka proposed openstack/neutron-tempest-plugin master: DNM Use fip-to-fip-vs-snat Ales patch for plugin jobs https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/927283 14:59:44 <opendevreview> Ihar Hrachyshka proposed openstack/neutron master: DNM try with Ales' fix for FIP-to-FIP vs zero-snat https://review.opendev.org/c/openstack/neutron/+/927272 15:00:08 <johnsom> It seems to fail when neutron is using the oslo policy 4.4 in the neutron API. 15:00:16 <johnsom> Though I don't have a "why" either 15:00:19 <slaweq> most likely on neutron, as we are using probably wrong context to make request 15:00:51 <slaweq> but as I said, I will deploy it locally and try to reproduce and investigate, probably next week 15:01:16 <haleyb> ah, ok, i'll watch the change and thanks everyone that's looked into it 15:01:42 <haleyb> #topic on-demand 15:01:45 <opendevreview> Merged openstack/neutron master: Get ips from system dns resolver without scope https://review.opendev.org/c/openstack/neutron/+/926079 15:01:52 <haleyb> we are over time, did anyone have another topic? 15:01:55 <mlavalle> can I get eyes on https://review.opendev.org/c/openstack/neutron/+/917800. I implemented the improvement recommended by haleyb. And I want it to be included in Dalmatian 15:02:22 <haleyb> mlavalle: yes, i will take a look, thanks for the update! 15:02:51 <mlavalle> thank you, that was a nice optimization 15:03:18 <haleyb> thanks for attending and the good discussions, as i said i'm out thursday if you're looking for me then, back on friday 15:03:25 <haleyb> #endmeeting