Friday, 2025-09-12

opendevreviewJaroslav Pulchart proposed openstack/neutron master: ip_conntrack: include allowed_address_pairs in CT_MARK_INVALID cleanup  https://review.opendev.org/c/openstack/neutron/+/96060205:37
ralonsohslaweq, hello! If you have 1 min: https://review.opendev.org/c/openstack/neutron/+/96036906:56
ralonsohthanks!06:56
opendevreviewMerged openstack/tap-as-a-service master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/tap-as-a-service/+/96047707:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN][FT] Do not lock the DB ``TestOvn*Sync*`` tests  https://review.opendev.org/c/openstack/neutron/+/96038407:45
opendevreviewMerged openstack/tap-as-a-service stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/tap-as-a-service/+/96047507:45
opendevreviewMerged openstack/tap-as-a-service stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/tap-as-a-service/+/96047607:45
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN][FT] Do not lock the DB in the ``TestOvn*Sync*`` tests  https://review.opendev.org/c/openstack/neutron/+/96038407:46
opendevreviewRodolfo Alonso proposed openstack/neutron master: [eventlet-removal] Don't use eventlet in the unit tests  https://review.opendev.org/c/openstack/neutron/+/95225807:46
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - Testing patch Neutron functional  https://review.opendev.org/c/openstack/neutron/+/95221007:46
ralonsohtkajinam, hello! do you know when we'll drop the support for py310?07:48
opendevreviewJaroslav Pulchart proposed openstack/neutron master: ip_conntrack: include allowed_address_pairs in CT_MARK_INVALID cleanup  https://review.opendev.org/c/openstack/neutron/+/96060207:49
sahido/ hello08:08
sahidquick question, some aggregates of segments are missing, i don't remember how I can force neutron to rebuild them08:09
sahidthe aggregates that have the name of the segment_id and on each there are the hosts that match the mapping08:10
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Dismiss the ``DBConnectionError`` exception during DB teardown  https://review.opendev.org/c/openstack/neutron/+/96072708:34
opendevreviewOpenStack Release Bot proposed openstack/ovn-bgp-agent stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/96072808:46
opendevreviewOpenStack Release Bot proposed openstack/ovn-bgp-agent stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/96072908:46
opendevreviewOpenStack Release Bot proposed openstack/ovn-bgp-agent master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/96073008:46
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: pep8: add translation for Exceptions (N534)  https://review.opendev.org/c/openstack/networking-bagpipe/+/96073408:47
tkajinamralonsoh, I don't know the exact timing but looking at https://devguide.python.org/versions/ probably in 2026.2 or 2027.108:56
ralonsohtkajinam, thanks!08:56
tkajinambasically we remove a version which may be EOL at the release timing08:56
tkajinammaybe at 2026.2, following what we've done in 2025.208:57
tkajinamthis ultimately needs to be confirmed by TC, though08:58
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Use a trivial active wait in ``test_create_bridges``  https://review.opendev.org/c/openstack/neutron/+/96074809:00
opendevreviewOpenStack Release Bot proposed openstack/neutron stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/neutron/+/96074909:04
opendevreviewOpenStack Release Bot proposed openstack/neutron stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/neutron/+/96075009:04
opendevreviewOpenStack Release Bot proposed openstack/neutron master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/neutron/+/96075109:04
opendevreviewLajos Katona proposed openstack/neutron-dynamic-routing master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96076009:22
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-vpnaas/+/96078109:53
opendevreviewLajos Katona proposed openstack/neutron-fwaas master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-fwaas/+/96078509:57
opendevreviewMerged openstack/neutron-vpnaas master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-vpnaas/+/96078111:06
opendevreviewMerged openstack/neutron-fwaas master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-fwaas/+/96078511:09
opendevreviewMerged openstack/neutron-dynamic-routing master: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96076011:16
opendevreviewJaroslav Pulchart proposed openstack/neutron master: ip_conntrack: include allowed_address_pairs in CT_MARK_INVALID cleanup  https://review.opendev.org/c/openstack/neutron/+/96060211:33
amorinhello neutron team, friday question: does it ring a bell to you? https://d9a8e1aebe2eccb5979a-b0b51e8fb063509c58e3ad9e91a1258e.ssl.cf1.rackcdn.com/openstack/330b0d23ffa1409a882eddcc3db0512c/tox/pep8/4-commands%5B3%5D.log13:11
lajoskatonaamorin: perhaps related to this one on master : https://review.opendev.org/c/openstack/neutron-lib/+/958786 , I mean the work around how hacking plugins from n-lib used13:13
haleyblajoskatona: thanks for the pep8 fix for n-d-r. it is also breaking the initial changes for stable/2025.2 but i'm not sure how to fix that - https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96049313:26
haleybfrickler: maybe you know? ^^ do we propose a new tag for 2025.2 ?13:27
tkajinamhaleyb, maybe you can just backport https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/960760 and merge it first ?13:28
opendevreviewTakashi Kajinami proposed openstack/neutron-dynamic-routing stable/2025.2: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96082113:29
haleybtkajinam: i just didn't know if the backport would merge without the others but worth a try13:29
opendevreviewMerged openstack/ovn-bgp-agent stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/96072813:29
opendevreviewMerged openstack/ovn-bgp-agent stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/ovn-bgp-agent/+/96072913:29
tkajinamhaleyb, these post-release patches don't need to be merged before backport13:30
tkajinamthe only annoying thing is that you have to manually override the target branch (due to the update of .gitreview not yet merged) but using web ui allows us to workaround it13:30
haleybtkajinam: ah, ok, thanks13:31
haleybi'm watching will merge when it passes13:31
tkajinamamorin, https://review.opendev.org/c/openstack/heat/+/958773/2/tox.ini shows what we did in heat13:34
lajoskatonahaleyb: we have to backport these to 2025.2 (https://review.opendev.org/q/topic:%22ignore_N535%22 )13:34
tkajinam(though the link does not open for me13:34
amorinack, thanks13:34
lajoskatonaas I see for n-d-r tkajinam already, thanks13:35
tkajinamlajoskatona, yup13:35
opendevreviewLajos Katona proposed openstack/neutron-fwaas stable/2025.2: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-fwaas/+/96082513:36
opendevreviewLajos Katona proposed openstack/neutron-vpnaas stable/2025.2: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-vpnaas/+/96082613:37
haleyblajoskatona: thanks, +2 from me13:38
lajoskatonaI cherry-picked for vpnaas (https://review.opendev.org/q/If5a5eb7044ed7d31f10478d93e394f95a21a2ba1 ) and fwaas (https://review.opendev.org/q/I3043fce2c8aad69f0f0ffb00d571d1d7569adc7f ) also13:40
opendevreviewMerged openstack/neutron-dynamic-routing stable/2025.2: pep8: Ignore N535 eventlet checking hacking rule  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96082113:48
opendevreviewMerged openstack/neutron-dynamic-routing master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96049513:49
opendevreviewMerged openstack/neutron stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/neutron/+/96074913:57
opendevreviewMerged openstack/neutron stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/neutron/+/96075013:57
haleyb#startmeeting neutron_drivers14:00
opendevmeetMeeting started Fri Sep 12 14:00:46 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 'neutron_drivers'14:00
ralonsohhello14:01
haleybPing list: ykarel, mlavalle, mtomaska, slaweq, tobias-urdin, lajoskatona, haleyb, ralonsoh14:01
mlavalle\o14:01
haleybi'm assuming we'll have quorum14:01
slaweqhi, I am in the other meeting in the same time but will try to participate here as well14:01
mlavalleI saw slaweq in slack earlier today14:01
haleybi can't remember if lajoskatona can attend14:02
haleybmaybe the first question is do we have to decide what quorum is now as we have less on the drivers team14:03
haleybi.e. is 3 enough?14:03
ralonsohhow many drivers do we have?14:03
ralonsoh6 if I'm not wrong14:04
haleybi'm looking14:04
slaweqhttps://launchpad.net/~neutron-drivers/+members#active14:04
slaweqaccording to this we have 7 but I think that amotoki is not really active anymore14:05
haleybnor is oleg, i need to remove them14:05
lajoskatonao/14:05
haleybso that leaves 514:05
lajoskatonaI am here actually quickly changing afternoon....14:05
haleyblajoskatona: o/14:05
haleybso do others agree that 3 is ok for quorum now? that is a majority of the 5.14:07
slaweqfine for me14:08
lajoskatona+114:08
ralonsoh+114:08
haleyband we will have to work on adding people, a thought for ptg14:08
haleybanyways, i do see at least one item, there might be others in the "ready" list to discuss quickly14:09
haleybralonsoh: you had the first one14:09
mlavalleyes 3 is quorum14:09
ralonsohthanks14:09
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/211964714:09
ralonsoh[RFE] OVN DHCP relay14:09
ralonsohI've also added a spec: https://review.opendev.org/c/openstack/neutron-specs/+/95679514:09
ralonsohIn a nutshell: OVN now allows to relay the DHCP requests14:10
ralonsohinstead of handling them internally, it is possible to relay the DCHP packets to external DHCP servers14:10
ralonsohthere is a new table DHCP_relay14:10
ralonsohyou can define an IP address there. Then you set this register to a Logical_Router_Port belonging to the network14:11
ralonsoh(that means you need to connect this network to a router)14:11
ralonsohand then, to the Logical_Switch, define in "options" the Logical_Router_Port14:11
ralonsohand that's all: you can have a DHCP running in a VM in another network14:12
ralonsohand this DHCP will reply to the DHCP requests messages from the VM running in this netwokr14:12
ralonsohthat's all14:12
ralonsoh(ah, of course, this feature is OVN only)14:13
ralonsohI have left you speechless!14:15
haleybi think i understand the spec, i did have one question.14:15
haleybthe network owner fills-in the IP address, correct?14:15
ralonsohyes14:15
opendevreviewMerged openstack/neutron-fwaas master: Update master for stable/2025.2  https://review.opendev.org/c/openstack/neutron-fwaas/+/96051214:15
haleybi didn't know if the cloud owner would want to do such things14:15
haleybi.e. how does the network owner know what IP it should use?14:16
haleybor maybe i'm missing the use case14:16
ralonsohso because of the potential issues this feature can cause, we can define by default this feature as admin-only14:16
ralonsohthat makes sense14:16
lajoskatona+1 for admin-only14:16
ralonsohso only an admin (by default) can assign this dhcp_relay value to a netwoek14:17
ralonsohI'll update the spec today ^^14:17
haleybok, and if it's required for normal operation, should a default be specified by the admin?14:17
opendevreviewMerged openstack/neutron-tempest-plugin master: Fix bug/2122606 to allow designate job  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/96065914:17
ralonsohadmin can always change the default policies14:18
ralonsohok you mean to have a default one14:18
ralonsohthat will apply always to the networks, that cannot be changed by a non-admin14:18
ralonsohhaleyb, is that what you mean?14:19
ralonsohI didn't think about having a possible default dhcp_relay value14:19
haleybright, i'm just thinking that if i go and create a network in this environment will dhcp work without that set?14:19
ralonsohby default, if not set, OVN will use the inner DHCP server14:19
ralonsohbuiltin DHCP server*14:20
lajoskatonafor backward compatibility the default builtin one is a good choice14:20
haleybsure14:20
ralonsohin any case, I would not implement the possibility for dhcp-relay by default14:21
haleybso maybe my first question should have been what the use case is? i'm assuming it's an operator that wants to know about all allocations?14:21
ralonsohthat should be used for very specific purposes14:21
mlavallebut we don14:21
mlavalledon't have a preferred dhcp server, right?14:22
ralonsohhaleyb, the use case was initially for baremetal servers in separate leafs14:22
ralonsohbut for now this feature, that requires a router and a LRP, doesn't match these requirements14:22
ralonsohmlavalle, sorry, I don't understand the question14:23
ralonsohOVN has a built-in server, we always use it14:23
opendevreviewStephen Finucane proposed openstack/neutron master: setup: Remove pbr's wsgi_scripts  https://review.opendev.org/c/openstack/neutron/+/96083414:23
opendevreviewStephen Finucane proposed openstack/neutron master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/neutron/+/96083514:23
ralonsohif we set a dhcp relay for a network, and this network is connected to a router (this is a must), then the DHCP messages will be relayed14:23
mlavallewe don't make any assumptions as to what ultimately responds to the dhcp requests. It's something running in a VM14:24
ralonsohnot at all14:24
opendevreviewArnaud Morin proposed openstack/neutron master: Add option to skip loading agent Trunk extension  https://review.opendev.org/c/openstack/neutron/+/91397914:24
ralonsohcould be anything, a DHCP agent, an DHCP server running in a VM, a DHCP server in an external IP address14:25
ralonsohanything14:25
mlavallethat was my question, thanks14:25
opendevreviewMerged openstack/neutron-dynamic-routing stable/2025.2: Update .gitreview for stable/2025.2  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96049314:25
ralonsohthis is like in ML2/OVS: the VM sends the DHCP requests, we run the DHCP agent but in some cases, with some "peculiar" configurations and ACLs, it was possible to respond from a VM with a DHCP server14:25
mlavalle+114:26
haleybare there any other questions?14:27
slaweqI am ok with this proposal14:28
mlavallevery clear use case14:28
lajoskatonafinr from me also, +114:28
mlavalle+114:28
ralonsohthank you all14:28
haleyb+1 from me14:28
mlavallewe need to start by reviewing the spec, right?14:28
ralonsohI need to add the admin-only bit14:29
haleyback, i'll mark approved but then yes, review the spec14:29
mlavalleok14:29
haleyb#link https://review.opendev.org/c/openstack/neutron-specs/+/95679514:29
lajoskatonaI have to anyway go to reviews specs, recently I forgot that....14:29
ralonsohahh, please approve the patch opening the 2026.1 folder: https://review.opendev.org/c/openstack/neutron-specs/+/95883114:29
lajoskatonadone14:30
ralonsohcool14:30
mlavallelol lajoskatona beat me to it14:31
haleybthere was nothing else in agenda, but there was one more rfe that would be good to discuss14:31
haleyb#link https://bugs.launchpad.net/neutron/+bug/212073214:31
haleyb[RFE] Add metadata caching for immutable values14:31
haleybi should have pinged sam before the meeting, but it seems straightforward, and more of a bug then rfe14:32
ralonsohI love the idea but I have some concerns with the implementation14:32
haleyboh, i now see you had looked the other day14:32
ralonsohwhat are "immutable values"? if you can answer it14:32
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/957197/5/neutron/common/metadata.py#3814:33
ralonsohI mean, having a configurable metadata cache could be a huge performance improvement in some scenarios14:33
opendevreviewMerged openstack/neutron-specs master: Spec folder for 2026.1 cycle  https://review.opendev.org/c/openstack/neutron-specs/+/95883114:33
ralonsohbut we must define well (or make it configurable too) what are inmutable values14:33
haleybi had initially asked about rate-limiting, but it does seem useful especially for this person14:34
ralonsohthat will probably be a bottle neck, the rate limiter14:34
ralonsohthey really need not to ping again and again the metadata server14:34
haleybin his case the rate limiter would help with the load, but not address the issue14:34
ralonsohso initially I'm in favor of this but we need a very clear picture of what is static and cab be cached14:35
haleybi.e. IoT devices that are dump14:35
haleybs/dumb14:35
lajoskatonayes, and as these values are coming from nova, should we have a chat with nova as well?14:36
ralonsoh^^ PTG could be a good place14:36
mlavallewas a spec proposed? if not, we can request a spec and clarify these concerns there14:36
mlavalleor the PTG. good idea14:37
ralonsoh+1 for a spec, I really like this idea14:37
haleybno, i didn't ask for one yet as it seemed simple, but would be good to get these questions answered14:37
mlavallelet's do that14:38
haleybimplementation should be simple according to existing change14:38
haleybok, i'll ask for spec and have a quick discussion at ptg to make sure we're not missing something from nova side14:38
ralonsoh+114:38
ralonsoh(nice topic for the PTG)14:39
lajoskatona+114:39
mlavalle+114:39
haleybgreat14:39
haleybi didn't see any other topics to discuss, but will wait a minute if anyone has one14:39
lajoskatonaI have one small (forgot to add to the agenda)14:40
lajoskatonathere was a mail from mnasser: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/425LYYRSQYWAK6APPQC6QFW35NFLJ6F7/14:40
lajoskatonaregarding taas and that the CLI code is historically in the taas repo and not in neutronclient like it is for other stadiums14:40
lajoskatonaI am not sure if we need and RFE for it, or just a bug enough14:41
mlavalle I don't think so. It is bringing this project in line with the rest of the stadium14:42
lajoskatonaexactly14:42
haleybso the ask is to add taas commands to the network CLI?14:43
ralonsoh^^ I have the same question14:44
lajoskatonaIn python-neutronclient under the OSC folder we have CLI code for other stadiums14:44
lajoskatonahttps://opendev.org/openstack/python-neutronclient/src/branch/master/neutronclient/osc/v214:45
haleybah yes, a lot of them14:45
lajoskatonaso the goal is to move the current taas CLI code to this folder14:45
ralonsohyeah but I think the decision was to have the OSC plugin in the repos14:45
ralonsohhttps://github.com/openstack/tap-as-a-service/tree/master/neutron_taas/taas_client/osc14:45
ralonsohif I'm not wrong14:45
lajoskatonathanks this is the current code14:45
ralonsohsorry, why do they need that in neutronclient?14:46
lajoskatonamnasser's issue is that when they deploy the CLI (I suppose in container) they have to install taas and that pulls in neutron as well to the container14:47
ralonsohahhh understood14:47
lajoskatonabut if they install neutronclient with all the dependencies no more hedache with the size14:47
ralonsohyeah, makes sense14:47
ralonsohjust asking: these are OSC extensions, right?14:49
ralonsohwhy not moving them to OSC?14:49
lajoskatonayes OSC14:49
lajoskatonano idea, I suppose openstackclient tried to keep these things away from their umbrella and maintenance14:50
ralonsohyeah... ok, let me ask this question to OSC mantainers (stephenfin for example)14:50
ralonsohin any case, we can do this: we can move this code to neutronclient for now14:51
lajoskatonagood idea, perhaps the simpler would to move all the things in neutronclient to OSC finally14:51
lajoskatonathanks14:51
stephenfinralonsoh: I was wondering the same thing myself recently :)14:51
haleybright, because we have 7 other directories of code in neutronclient14:51
ralonsohso that could be something for 2026.1: to move the OSC extensions to OSC14:52
stephenfinneutronclient uses SDK for everything now, right? Or does it still use the deprecated neutronclient lib?14:52
ralonsohstephenfin, good question, for sure14:52
lajoskatonano I beleive I cut all the code for the old python bindings14:52
ralonsohI can't confirm that but these are OSC extensions, should relay on SDK14:52
stephenfinIf it uses SDK for everything then I see no reason not to move it wholesale to OSC14:52
ralonsohnice to read that14:53
stephenfinand probably make you folks full core there so I don't have to review everything14:53
ralonsohhehehe ok14:53
lajoskatonawe can start that as a goal for the coming cycle :-)14:53
ralonsoh^ +114:53
haleybsure, and it gets us a good ptg topic too :)14:54
mlavallelol14:54
lajoskatona:-)14:55
lajoskatonathan I think that's it for this topic, the goal is to move all things to OSC, have a discussion on the PTG14:56
haleybok, sounds good, do you want to respond to mnaser on the ML?14:56
lajoskatonayes I can14:57
* haleyb is getting better at delegating :)14:57
lajoskatona:D14:57
haleybalright we're at end of hour, any other topics14:57
haleybthanks for that one lajoskatona btw14:57
haleybok, thanks for attending and have a good weekend!14:58
haleyb#endmeeting14:58
opendevmeetMeeting ended Fri Sep 12 14:58:18 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:58
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-09-12-14.00.html14:58
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-09-12-14.00.txt14:58
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-09-12-14.00.log.html14:58
mlavalle\o14:58
ralonsohhave a nice weekend!14:58
lajoskatonao/14:58
haleybslaweq: i had a question about https://launchpad.net/~neutron-drivers/+members#active since you are marked as Admin. I had updated the review group (https://review.opendev.org/admin/groups/5b063c96511f090638652067cf0939da1cb6efa7,members) to remove members, but should we clean-up the members list?15:01
haleybobviously i can't do it without super powers15:02
ralonsohhaleyb, he left the office 1 min ago15:03
haleybit wasn't critical can figure out monday15:04
fricklerhaleyb: just checked and I could make you admin15:10
haleybfrickler: why not i'll be here at least one more cycle :)15:10
fricklerwell "I could" meant "I was able to and did" ... ;)15:13
opendevreviewCandido Campos Rivas proposed x/whitebox-neutron-tempest-plugin master: Increase burst window size to avoid unstabilities in slow envs  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94461615:23
opendevreviewMohammed Naser proposed openstack/python-neutronclient master: Add Tap-as-a-Service client code  https://review.opendev.org/c/openstack/python-neutronclient/+/96084615:33
opendevreviewMohammed Naser proposed openstack/python-neutronclient master: Add Tap-as-a-Service client code  https://review.opendev.org/c/openstack/python-neutronclient/+/96084615:37
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN][FT] Do not lock the DB in the ``TestOvn*Sync*`` tests  https://review.opendev.org/c/openstack/neutron/+/96038415:38
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Dismiss the ``DBConnectionError`` exception during DB teardown  https://review.opendev.org/c/openstack/neutron/+/96072715:38
opendevreviewRodolfo Alonso proposed openstack/neutron master: [FT] Use a trivial active wait in ``test_create_bridges``  https://review.opendev.org/c/openstack/neutron/+/96074815:38
opendevreviewMohammed Naser proposed openstack/tap-as-a-service master: Remove client code from repository  https://review.opendev.org/c/openstack/tap-as-a-service/+/96084915:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: [eventlet-removal] Don't use eventlet in the unit tests  https://review.opendev.org/c/openstack/neutron/+/95225815:52
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - Testing patch Neutron functional  https://review.opendev.org/c/openstack/neutron/+/95221015:53
opendevreviewArnaud Morin proposed openstack/neutron master: Add option to skip loading agent Trunk extension  https://review.opendev.org/c/openstack/neutron/+/91397915:55
ralonsohhaleyb, hello! please check https://review.opendev.org/c/openstack/neutron/+/960748 and the parent patches (you already reviewed a couple)16:04
ralonsohthanks in advance16:04
opendevreviewMerged openstack/neutron-dynamic-routing stable/2025.2: Update TOX_CONSTRAINTS_FILE for stable/2025.2  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/96049416:04
opendevreviewStephen Finucane proposed openstack/neutron master: Migrate setup configuration to pyproject.toml  https://review.opendev.org/c/openstack/neutron/+/96083517:02
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM - Testing patch Neutron py310  https://review.opendev.org/c/openstack/neutron/+/96087617:40
opendevreviewBrian Haley proposed openstack/python-neutronclient master: Update outdated tox.ini and setup.cfg files  https://review.opendev.org/c/openstack/python-neutronclient/+/96089021:33
opendevreviewJakub Libosvar proposed openstack/neutron master: functional: Spawn Open_vSwitch ovsdb-server for OVN agent  https://review.opendev.org/c/openstack/neutron/+/96089221:51
opendevreviewJakub Libosvar proposed openstack/neutron master: functional: Spawn Open_vSwitch ovsdb-server for OVN agent  https://review.opendev.org/c/openstack/neutron/+/96089221:56
opendevreviewJakub Libosvar proposed openstack/neutron master: functional: Spawn Open_vSwitch ovsdb-server for OVN agent  https://review.opendev.org/c/openstack/neutron/+/96089222:17
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Introduce service plugin  https://review.opendev.org/c/openstack/neutron/+/95810022:17
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Introduce Main router and chassis router commands  https://review.opendev.org/c/openstack/neutron/+/95989022:17
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: Introduce BGP chassis commands  https://review.opendev.org/c/openstack/neutron/+/96042222:17
opendevreviewJakub Libosvar proposed openstack/neutron master: bgp: OVN agent BGP extension  https://review.opendev.org/c/openstack/neutron/+/96089522:17
opendevreviewJakub Libosvar proposed openstack/neutron master: functional: Spawn Open_vSwitch ovsdb-server for OVN agent  https://review.opendev.org/c/openstack/neutron/+/96089222:20
opendevreviewMerged openstack/neutron stable/2025.1: Fix AttributeError accessing local compute port  https://review.opendev.org/c/openstack/neutron/+/96013123:30

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