Tuesday, 2025-12-16

daidvhi haleyb , I have updated this patch following your comments https://review.opendev.org/c/openstack/neutron/+/951390 . Could you pls to take a look on it :D Thanks!03:23
opendevreviewOleksandr Kozachenko proposed openstack/neutron master: Fix a race condition in OVN metadata port update  https://review.opendev.org/c/openstack/neutron/+/96246304:00
*** zseguin_ is now known as zseguin04:18
*** zseguin_ is now known as zseguin05:46
*** zseguin is now known as Guest3370205:47
opendevreviewMerged openstack/neutron unmaintained/yoga: [CI] Functional: Increase Ulimit to 4096  https://review.opendev.org/c/openstack/neutron/+/97106407:56
ralonsohbcafarel, hello! If you have less than one min: https://review.opendev.org/c/openstack/neutron/+/970646. Thanks!08:16
ralonsohslaweq, hello! If you have less than one min: https://review.opendev.org/c/openstack/neutron/+/971049. Thanks!08:17
slaweqralonsoh done08:19
ralonsohfolks, we need this fix: https://review.opendev.org/c/openstack/neutron/+/97020408:24
ralonsohand backport it up to 2025.108:24
slaweqralonsoh: approved08:30
slaweqralonsoh: can you check https://review.opendev.org/c/openstack/neutron-lib/+/969952/ maybe?08:31
ralonsohsure08:32
opendevreviewOleksandr Kozachenko proposed openstack/neutron master: Fix a race condition in OVN metadata port update  https://review.opendev.org/c/openstack/neutron/+/96246308:54
opendevreviewMerged openstack/neutron master: Change some common test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808310:23
opendevreviewMerged openstack/neutron master: Remove the "nftables" explicit CI jobs  https://review.opendev.org/c/openstack/neutron/+/97104910:27
opendevreviewMerged openstack/neutron master: Check if network is external in auto-allocate code  https://review.opendev.org/c/openstack/neutron/+/97020410:28
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2025.2: Check if network is external in auto-allocate code  https://review.opendev.org/c/openstack/neutron/+/97116010:34
opendevreviewRodolfo Alonso proposed openstack/neutron stable/2025.1: Check if network is external in auto-allocate code  https://review.opendev.org/c/openstack/neutron/+/97116110:34
opendevreviewRodolfo Alonso proposed openstack/neutron master: Change some unit test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808410:51
opendevreviewStephen Finucane proposed openstack/neutron master: Move api-paste.ini, rootwrap.conf files  https://review.opendev.org/c/openstack/neutron/+/96113010:52
ralonsohslaweq, after merging the approved n-lib patches (https://review.opendev.org/q/project:openstack/neutron-lib+status:open), we can propose a new nversion10:56
opendevreviewMerged openstack/neutron-lib master: Deprecate "is_advsvc" attribute in the Context object  https://review.opendev.org/c/openstack/neutron-lib/+/96995211:12
opendevreviewMerged openstack/neutron-lib master: Service role is now considered as the one who can change project_id  https://review.opendev.org/c/openstack/neutron-lib/+/96995311:12
slaweqralonsoh: the only one which I am not sure about is https://review.opendev.org/c/openstack/neutron-lib/+/969962 - I don't know how much time elvira would need for it and if she wants us to wait a bit for that one or not11:43
ralonsohelvira, ^^ will you be able to propose the new API extension this week?14:00
haleyb#startmeeting networking14:00
opendevmeetMeeting started Tue Dec 16 14:00:23 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'networking'14:00
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh14:00
slaweqo/14:00
lajoskatonao/14:00
ralonsohhello14:00
*** ykarel_ is now known as ykarel14:00
elvirao/14:00
ykarelo/14:00
haleyb#announcements14:01
haleybhi everyone14:01
haleybWe are in week R-15 of Gazpacho14:01
haleybOur next milestone in this development cycle will be gazpacho-2, on January 8, 202614:01
haleyb#link https://releases.openstack.org/gazpacho/schedule.html14:01
haleybSo we should start getting any new features merged14:02
haleybContinue to use the priorities dashboard for important changes or things ready to merge14:02
haleyb#link https://tinyurl.com/59z278km14:02
haleybReminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers14:02
haleybbut with that said, i was going to cancel the meeting this friday, and actually all neutron meetings until the week of january 5th14:03
mtomaskao/ late14:03
lajoskatonaack, thanks14:03
haleybi am technically out from this friday until then, just working one day in the middle14:04
haleybalthough i'll probably check things randomly14:04
ralonsohquestion about friday 214:04
ralonsohwe'll we have drivers meeting?14:04
ralonsohjust asking, no special interest14:05
slaweqI doubt we will have quorum14:05
ralonsohI think so, yes14:05
haleybralonsoh: i will be out, but if you want to lead it and there are items14:05
slaweqI will still be off for sure14:05
ralonsohno no, just asking14:05
ralonsohI'm fine if we cancel it14:05
haleyback14:05
haleybhopefully everyone enjoys their time off, since we'll jump right back into it with G2 in January14:06
haleybone more announcement is that V/W/X releases are going EOL, there was a ML thread about it14:07
opendevreviewElvira García Ruiz proposed openstack/neutron-lib master: Add "both" direction to tap mirror definition  https://review.opendev.org/c/openstack/neutron-lib/+/96996214:08
haleybi asked about yoga since it's an LTS for us, so maybe it will stay around a little bit longer14:08
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/N24CYAJMLVJMAJMUE4RA5U7KOL7LABOW/14:08
haleybi approved the eol tags for those three already14:09
haleybany other announcements?14:09
haleyb#topic bugs14:10
haleybi was the bug deputy last week, and it was (finally) pretty light14:10
haleyb#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/JSOLWTLT7TAW766BOHTMGSD6IFJHI3CL/14:10
haleybi'll just go over a couple14:11
haleyb#link https://bugs.launchpad.net/neutron/+bug/213450414:11
haleybWrong neutron:host_id in LSP external_ids after live migration14:11
haleyb#link https://review.opendev.org/c/openstack/neutron/+/97056414:11
haleybif anyone can review that i'd appreciate it, was tested by submittor14:11
ralonsohsure, looks ok, I'm trying to find a way to optimize (if possible) the DB access 14:12
haleybralonsoh: sure, if there is a way to improve let me know14:12
haleybthe next was involving changing the is_default flag for external networks, and i see the fix was merged today, so thanks ralonsoh and slaweq 14:13
ralonsoh++14:13
ralonsohnice catch and fix14:13
haleybnp, and i see it was cherry-picked so will take a look14:14
ralonsohhttps://review.opendev.org/q/topic:%22bug/2134387%2214:15
haleybralonsoh: and i see the fix for https://bugs.launchpad.net/neutron/+bug/2134703 was merged and cherry-picked, great14:15
ralonsohyes, thanks for the reviews14:16
haleybthere were two RFEs, one was from mtomaska 14:16
haleyb#link https://bugs.launchpad.net/neutron/+bug/213522814:17
haleyb[RFE] Add support for local sink in tap mirror14:17
haleybi asked him to put on agenda, seemed good14:17
mtomaskaACK14:17
mtomaskabut maybe next year :)14:17
haleybyup, np14:17
mtomaskasorry end of the year jokes are coming14:17
slaweq:)14:17
haleyb:)14:18
haleybthe other RFE i was not sure it was useful, figure i would ask for input14:18
haleyb#link https://bugs.launchpad.net/neutron/+bug/213460614:18
haleyb[RFE] Add an API that returns a list of available IPs in a network14:18
ralonsohI'm checking the patches now 14:19
ralonsohactually the pending one in neutron14:19
haleybi had two issues - 1) there is already a way to get all the IPs in use on a network, and 2) there was no real use case given14:19
ralonsohI don't understand you14:20
mtomaskaThis RFE is asking to return list of available IPs(not used) , right?14:20
haleybyes, but that can be scripted if we know the cidr and the in-use IPs14:20
ralonsohyes, I think so14:21
ralonsohbut I think this is faster with one single command14:21
haleyb"it would be very useful for users" isn't really a use case14:21
mtomaskatrue, but I think the reporter wants neutron to provide. I.e. "openstack network foo list-free-ips` are something like that14:21
haleybFor IPv6 a single /64 has 18,446,744,073,709,551,616 addresses :-/14:22
mtomaskapipe to `less` I guess :)  But I get your point14:23
haleybmtomaska: i do understand what they are asking, but we have a perfectly good allocator to pick a free IP from the pool14:24
haleybotherwise they can be in a loop - show me the list; give me .7; sorry in-use; give me the list again; give me .8; rinse repeat14:24
haleybthere is no way to guarantee what is free one second is free the next14:25
mtomaskaYeah I am reading comment #2. It almost seems like they are describing a dhcp server :) 14:25
mtomaskaBut I agree with you. It is bit unclear.  "The feature that’s currently being added only reports the count of available IP; it doesn’t show which specific addresses are free"14:27
haleybyeah i had mentioned the network-ip-availabilty update in progress14:27
ralonsohbut the point was to add all the extra fields: total subnet, total allowcation, used subnet, used allocation, etc14:27
ralonsohthis is something we currently don't have14:28
ralonsohI don't think we are expecting this feature to report the current used IP addresses14:28
haleybralonsoh: right, i didn't exactly know his ask, didn't know if it was to determine how many were left14:29
ralonsohplease, comment that in the review14:29
ralonsohthat will help me too to re-review it again14:29
haleybralonsoh: ? i was just talking about the bug, there isn't a review for it14:30
haleybi might have confused people14:30
haleybi am just talking about https://bugs.launchpad.net/neutron/+bug/213460614:30
ralonsohyes14:31
ralonsohhttps://review.opendev.org/q/topic:%22bug/2107316%2214:31
haleybralonsoh: no that's a different thing, i'm ok with that14:31
haleyblike i said, i confused you14:32
ralonsohmy bad...14:32
haleybnp14:32
haleybthe bug/rfe has this sentence - "Some users may prefer automatic allocation, but I think there will also be users who want to retrieve the list of available addresses and pick one themselves"14:32
haleybthat is not very cloud-y14:32
ralonsohok, let them to present it in the drivers meeting14:33
haleybnone of our workloads run that way at all14:33
ralonsohjust to justify the value14:33
mtomaskaI have a feeling they have some use cases for it at their site, but maybe not that useful in grand scheme of openstack 14:34
haleybralonsoh: ok, this is why i wanted to bring it up, i just haven't seen the justification yet, but if they are willing to spend the time to discuss that says something14:34
ichenIt sounds like splitting the subnet into blocks for static address allocation and for dhcp14:35
haleybmtomaska: maybe, but using "I think" is confusing to me, it doesn't show there is a current problem14:35
haleybichen: yes, i mentioned they can change the allocation range, just like i do on my home subnet to allow static vs dynamic14:36
haleybanyway i'll ask them to attend driver's meeting next year14:36
haleybalright, i had no more bugs14:37
haleybthis week rubasov is the bug deputy, next two weeks are mlavalle and ralonsoh - don't know if with people off you need to track the bugs though14:38
ralonsohok14:38
rubasovack14:38
haleybralonsoh, mlavalle: should i just push your shifts to next year and not worry about the next two weeks? or are you working?14:39
ralonsohI'll be working since Friday 214:39
haleyboops, it's not ralonsoh it's lajoskatona 14:39
ralonsohso I'll check thi sweek14:39
ralonsohahhhh14:39
haleybno coffee yet  :(14:40
lajoskatonaIcan do it, not full time but can keep my eyes on things14:40
haleyblajoskatona: ack14:40
haleybi realize apac is mostly still working, but should be a slow week anyway14:41
haleybok, moving on14:41
haleyb#topic specs14:41
haleyb#link https://review.opendev.org/q/project:openstack/neutron-specs+status:open14:41
haleybi see there were a couple of updates recently so just need review14:42
haleybmlavalle: is your routed network spec ready for review?14:43
haleyband regarding the OVN BGP spec work, i have seen things start to merge to jlibosva must be happy14:44
haleyb#topic community goals14:45
haleyblajoskatona: i see you are still waiting for reviews on nova changes14:45
haleyb#link https://review.opendev.org/c/openstack/nova/+/928022 and series14:45
lajoskatonayes, I updated the last one for ports, some tests are still failing, perhaps will pass just in January :-)14:47
haleybgreat, will try and review this week14:47
haleyband mtomaska i see the OSC taas change merged :)14:48
lajoskatonaI have 2 older one in some of our dashboars:14:48
lajoskatonahttps://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/960287 & https://review.opendev.org/c/openstack/neutron-vpnaas-dashboard/+/96038814:48
mtomaskaYep14:48
lajoskatonacool14:48
ralonsohlajoskatona, I'll check both now14:49
haleyblajoskatona: great will take a look14:49
mtomaskaonce those are part of SDK their OSC cli code can also be  moved, correct?14:49
lajoskatonayes,I think14:50
haleybmtomaska: yes i think thats correct14:50
lajoskatonaas we are in a SLURP now do we have some deprecation rules perhaps?14:50
haleybi'd have to look as i don't know how it applies to this code14:51
lajoskatonahaleyb: ack, thanks14:51
haleybi also started quite a long patch series moving the test code to using project_id over tenant_id14:52
haleyb#link https://review.opendev.org/c/openstack/neutron/+/968083 (and series)14:52
haleybthanks for the reviews14:52
haleybi might take a break on it, but next would be to change things to ensure the objects returned all have project_id key in them, which they don't at the moment14:53
haleyb#topic on-demand14:54
haleybi didn't not see anything on the agenda, but any other topics?14:55
ralonsohI have 2 topics14:55
ralonsohI added 114:55
ralonsoh1) n-d-r project, we discussed that yesterday in the CI meeting14:55
ralonsohwe no longer can move projects to x/ namespace14:55
haleybah, reload14:55
ralonsohbut we can deprecate it. However, we can delay it until further debugging frickler will do14:56
ralonsohso we can wait14:56
ralonsohthat was just a heads-up14:56
ralonsoh2) live-migration with OVN (THE topic)14:56
ralonsohwe have this: https://bugs.launchpad.net/neutron/+bug/206971814:56
ralonsohI talked to Sean about implementing in os-vif the possibility of creating the port+TAP14:57
ralonsohand in the libvirt definition, request linvirt to reuse the existing TAP14:57
ralonsohthat should work for any OVS port (ml2/ovs and ml2/ovn)14:58
ralonsohthe next step would be to add a nueutron configuration flag and pass it in the vif-details14:58
ralonsohto enable/disable the commented feature14:58
ralonsohand last, to implement in Neutron an event to detect that the multiple port binding (in the LSP) has been already moved14:59
ralonsohwe are creating now POCs. Once tested, we'll present it in a drivers meeting and if needed, we'll create a spec14:59
ralonsohthat's all14:59
mtomaskaJut FYI, ykarel was looking into similar request via D/S bug request. I have also talked to OVN about what we can do... 14:59
ralonsohexactlu15:00
ykarelit's the same one that ralonsoh talking about15:00
ralonsohthis is yatin's Jira ticket15:00
mtomaskaACK15:00
haleybthanks for the update looking forward to any changes :)15:00
ralonsohcool! thanks15:01
haleybok, we are over time15:01
haleybthanks for attending everyone and have a great end of year, next meeting january 6th!15:01
haleyb#endmeeting15:01
opendevmeetMeeting ended Tue Dec 16 15:01:38 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2025/networking.2025-12-16-14.00.html15:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-12-16-14.00.txt15:01
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2025/networking.2025-12-16-14.00.log.html15:01
ralonsohbye15:01
lajoskatonao/15:01
mtomaskao/15:01
ykarelo/15:01
slaweqo/15:03
opendevreviewMerged openstack/neutron master: Change some unit test code to use project_id  https://review.opendev.org/c/openstack/neutron/+/96808415:12
sean-k-mooneyralonsoh: while you shoudl never reaslly have moved thing to the x namespace they can be removed to other namespace in some cases i.e. openstack-attic when they are bing archived15:27
sean-k-mooneyralonsoh: n-d-r is neutron dynmaic routing correct?15:28
ralonsohyeah, we can think about this if the eventlet removal is not finished in time15:28
ralonsohyes, dynamic routing15:28
sean-k-mooneyralonsoh: on a related note what is the status of neutron FWaaS15:28
sean-k-mooneythat was deprecated in victoria and undeprecated 3 years ago15:28
ralonsohfine right now15:28
slaweqsean-k-mooney: fwaas is revived for some time already15:29
ralonsohactually we are providing it in RHOSO18 (kudos to slaweq)15:29
sean-k-mooneyyep15:29
slaweqand we even have it as TP in RHOSO 1815:29
slaweqsame with Tapaas15:29
sean-k-mooneythe reason im asking is efoley is currently looking at removing the use of neutron client form ceilomenter15:29
ralonsohlajoskatona, ^^ is working in this area15:29
sean-k-mooneyand there they have deprecated teh FWaaS part a year before it was revived15:30
ralonsohlajoskatona, is working on replacing neutronclient with OSC15:30
sean-k-mooneyso we were trying to figure out if that should be undeprecated in celiomenter and ported to the sdk or remvoed15:30
sean-k-mooneyit sounds like it shoudl be proted with everthing else15:30
ralonsohI know that for TaaS, Miro implemented the OSC part and removed the neutronclient code15:30
ralonsohI don't know for FWaaS15:31
sean-k-mooneyits supproted in the sdk, i have not check osc15:31
slaweqI did not even check it so I don't really know for now15:31
sean-k-mooneyi dont see it . 15:31
sean-k-mooneyin https://docs.openstack.org/python-openstackclient/latest/cli/command-list.html15:31
ralonsohsean-k-mooney, in any case, if the SDK provides support, then it should be used15:32
sean-k-mooneyso that a gap but the FWaaS api surface is pretty small15:32
ralonsohI'll ping efoley to know what is still using neutronclient for fwaas15:33
ralonsohfolks, check https://review.opendev.org/c/openstack/neutron/+/97056416:00
ralonsohif merged, we'll need to backport it16:00
slaweqralonsoh: done16:04
slaweqsee you tomorrow16:04
ralonsohthanks!16:04
ralonsohsee you16:04
opendevreviewElvira García Ruiz proposed openstack/neutron-lib master: Add "both" direction to tap mirror definition  https://review.opendev.org/c/openstack/neutron-lib/+/96996216:06
opendevreviewMerged openstack/neutron stable/2025.2: [OVN] Fix the `_gen_router_port_ext_ids` call  https://review.opendev.org/c/openstack/neutron/+/97064616:07
opendevreviewElvira García Ruiz proposed openstack/neutron-lib master: Add "both" direction to tap mirror definition  https://review.opendev.org/c/openstack/neutron-lib/+/96996216:11
opendevreviewsean mooney proposed openstack/os-vif master: Add pyroute2 tap device creation support  https://review.opendev.org/c/openstack/os-vif/+/97123117:26
sean-k-mooneyralonsoh: https://github.com/openstack/ceilometer/blob/20756c9bd8ccb5e25c61e68769d04d4913725128/ceilometer/network/services/fwaas.py is what we were chating about. emma is looking at updating ceilomenter in general to use the sdk instead of the project clients i guess17:39
sean-k-mooneyhttps://github.com/openstack/ceilometer/blob/20756c9bd8ccb5e25c61e68769d04d4913725128/ceilometer/neutron_client.py is a better refernce17:39
opendevreviewMerged openstack/neutron master: Search for active port binding when updating LSP host info  https://review.opendev.org/c/openstack/neutron/+/97056418:13
opendevreviewElvira García Ruiz proposed openstack/tap-as-a-service master: [OVN] Add BOTH direction to tap mirror  https://review.opendev.org/c/openstack/tap-as-a-service/+/96999118:26
opendevreviewBrian Haley proposed openstack/neutron stable/2025.2: Search for active port binding when updating LSP host info  https://review.opendev.org/c/openstack/neutron/+/97123718:43
opendevreviewBrian Haley proposed openstack/neutron stable/2025.1: Search for active port binding when updating LSP host info  https://review.opendev.org/c/openstack/neutron/+/97123818:44
opendevreviewBrian Haley proposed openstack/neutron stable/2024.2: Search for active port binding when updating LSP host info  https://review.opendev.org/c/openstack/neutron/+/97123918:45
opendevreviewBrian Haley proposed openstack/neutron unmaintained/2024.1: Search for active port binding when updating LSP host info  https://review.opendev.org/c/openstack/neutron/+/97124018:45
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Introduce BGP chassis commands  https://review.opendev.org/c/openstack/neutron/+/96042221:52
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Introduce BGP chassis commands  https://review.opendev.org/c/openstack/neutron/+/96042221:55

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!