Monday, 2025-06-30

opendevreviewMerged openstack/neutron master: [eventlet-removal] Remove the usage of eventlet from the periodic worker  https://review.opendev.org/c/openstack/neutron/+/95211700:01
*** elodilles is now known as elodilles_pto06:14
ralonsohhi folks, if you have some minutes today:08:00
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/95265908:00
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/93932108:00
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/93776508:00
ralonsoh* https://review.opendev.org/c/openstack/neutron/+/95049908:00
ralonsohall eventlet-removal related08:00
ralonsohthanks in advance08:00
lajoskatonaralonsoh: added to my pile08:07
opendevreviewSlawek Kaplonski proposed openstack/neutron-lib master: Make model_query to be project scoped only with old API policies  https://review.opendev.org/c/openstack/neutron-lib/+/95373309:07
opendevreviewyatin proposed openstack/neutron master: Revert "Make resource "tag" case sensitive"  https://review.opendev.org/c/openstack/neutron/+/95373409:10
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Remove plugin parameter from the policy.enforce and check functions  https://review.opendev.org/c/openstack/neutron/+/95373509:27
opendevreviewLajos Katona proposed openstack/neutron master: OVS Trunk: Improve code documentation for trunk wiring  https://review.opendev.org/c/openstack/neutron/+/94956909:37
jjasekHello, Horizon greets Neutron :-). Our Horizon tests (not exactly the tests but devstack environment preparing) started failing around 27th of June. The issue seems to be connected with Neutron (neutron_plugins). Can someone please take a look at it or direct me to the right path to find what can be wrong there? Log: https://zuul.opendev.org/t/openstack/build/71baf61777b844578daad15d564ecb2309:41
bcafareljjasek: you may need https://review.opendev.org/c/openstack/neutron/+/953734 (disclaimer I have not checked the logs in detail, just that the date aligns with original change)09:48
opendevreviewMerged openstack/neutron stable/2025.1: [FT] Wait for the FIP Port_Binding event before checking MAC removal  https://review.opendev.org/c/openstack/neutron/+/95341109:48
lajoskatonajjasek, bcafarel: Hi, the zuul log referenced is a little different what is in the bug for tags (https://bugs.launchpad.net/neutron/+bug/2115629 ), but good coincidence based on the dates10:01
jjasekbcafarel, lajoskatona: Hello guys, based on my very limited knowledge of Neutron, it doesn't seem to be related. I will try to deep dive into this, I also created a bug for this issue. If any of you have some time/idea, I will be more than happy if you can take a look at it <3. https://bugs.launchpad.net/neutron/+bug/211563110:07
ykareljjasek, ot10:48
ykarelit's same as https://bugs.launchpad.net/neutron/+bug/2115629 , i have closed 2115631 as duplicate10:48
ralonsohykarel, thanks a lot for reporting and providing info10:49
ralonsohjjasek, I'm working on this right now10:49
ralonsohsorry, I didn't considered mariadb10:49
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Remove plugin parameter from the policy.enforce and check functions  https://review.opendev.org/c/openstack/neutron/+/95373510:50
opendevreviewTakashi Kajinami proposed openstack/neutron-tempest-plugin master: Remove deprecated options to enable/disable plugin tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/95374110:57
jjasekykarel, ralonsoh, Thank you guys! Let me know if there is any news.11:00
sean-k-mooneyralonsoh: the reaons we did not set a coalation typ in the scema for nova awas actully becase of upgrade impact in 2 cases, 1 it woudl force a data migration and for nova we woudl rally need to do this for a lot fo tables not just one for it to make any sesne11:39
sean-k-mooneythe other reasons is some people may have incorrectly been relying on the case insensitve behavior11:40
sean-k-mooneywhiel we inteded the tag and metadata apis ectra to be case senseitive11:40
ralonsohsean-k-mooney, we need that only for one table11:40
sean-k-mooneyand that what the python code expected it was not enforced at the db level11:40
ralonsohthe openstack API says tags are case sensitive11:40
sean-k-mooneyat the api they are11:41
sean-k-mooneybut the actual behavior dependon on the db schdmea to a degree11:41
sean-k-mooneyso thenicaly it depends11:41
ralonsohI don't agree with that11:41
ralonsohif we add two different tags and then the DB doesn't differenciate them11:41
ralonsohthen the API is broken11:42
sean-k-mooneyyou were referint to the wiki which is not the ahtoritive source11:42
sean-k-mooneyas in https://specs.openstack.org/openstack/api-wg/guidelines/tags.html is not actully the athoritive srouce on hwo this work11:42
sean-k-mooneybut making them case sensitive was the orgianly intient11:42
ralonsohand we are doing that with that single change11:43
sean-k-mooneyin realtity it entirlly depended on how your db was configured11:43
ralonsohthis is only needed in one single table11:43
ralonsohand there are collations that are in mariuadb and mysql11:43
sean-k-mooneyright im just sayign that if nova is deploy with a case insetivige coalation type then they will be case instisitive11:44
sean-k-mooneywe are not enforcign the coalation type because we were worried about upgrade impacts11:44
ralonsohwe considered that in the Neutron meeting and decided to follow what is in the wiki11:44
ralonsohwhat about the upgrade?11:44
sean-k-mooneywe dont know if people have built applciation that depend on it being case instistive because the cloud they are interactig with did not use a case sensitive coalation type11:45
sean-k-mooneyralonsoh: i would sugget usign  utf8mb4_bin by the way11:45
ralonsohthis is what I'm going to push now11:45
sean-k-mooneythat shoudl work on debian and older dbs 11:45
sean-k-mooneyack11:46
ralonsohyes, this is supported in all mariadb and mysql 5.5.3 (2010)11:46
sean-k-mooneyya its much much older and was added wiht the 4 byte utf8 encoding was added11:46
sean-k-mooneyso the actula api ref for the server tag interface is here https://docs.openstack.org/api-ref/compute/#server-tags-servers-tags11:47
sean-k-mooneyas i said we ended up not specifyign if it was case sesneitve or not in the api contract11:47
sean-k-mooneyeven though it was inteded to be case senitive11:48
sean-k-mooneythe spec did capture that detail https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/tag-instances.html#data-model-impact11:48
sean-k-mooneywe got a bug report https://bugs.launchpad.net/nova/+bug/153801111:49
sean-k-mooneysayign metadata keys were not treated as case seneitive 11:51
sean-k-mooneywhen we looked at that w efound that in many case because nova does not specify a coalation type the exact behavior can vary depending on how the db is configured11:51
sean-k-mooneyso for us to actully fix this and make them case seneistive is much more complex11:52
sean-k-mooneywe would have to look at all our tables and decided which need to be case sensitive or not11:53
ralonsohsorry sean-k-mooney , I sent a mail 2 weeks ago11:53
ralonsohand nobody replied 11:53
ralonsohthat was an openstack wide mail, with the correct tags11:53
ralonsohso we decided to fix that making it case sensitive11:53
ralonsohbecause some customers using THT hit an issue11:54
sean-k-mooneyif they used tripleo hte behavior they would have by default woudl depend on the local used but it was proably case inseitive on the nova side11:55
sean-k-mooneyi have been pretty heads down for the last few weeks so i missed your mail11:55
sean-k-mooneyah `"tag" API in OpenStack, case sensitive`11:57
sean-k-mooneyi can reply with context to that mail if it helps11:57
ralonsohthat will be perfect11:58
sean-k-mooneyi think this would be a good topic for th enova team to reconsider in the next ptg.11:58
sean-k-mooneywe have a number of issue with our db schema like using ints instead of uint6411:59
sean-k-mooneyin places11:59
sean-k-mooneywe had at least one case where the make primary key was hit for our metadta table (psi)11:59
sean-k-mooneythat was cause by using a signed int 3212:00
sean-k-mooneybut as i noted we generally dont set the coalation types at all in our schemas12:00
sean-k-mooneywhich is problematic12:00
sean-k-mooneyralonsoh: by the way why does neutorn have tags?12:32
sean-k-mooneynova has port tags in our db because neutron did not have taging12:32
sean-k-mooneyhttps://specs.openstack.org/openstack//nova-specs/specs/ocata/approved/virt-device-tagged-attach-detach.html12:32
sean-k-mooneywe have neutron port tags and cinder volume tags in our db to extended tagging to both services since pike  https://specs.openstack.org/openstack//nova-specs/specs/pike/implemented/virt-device-tagged-attach-detach.html12:33
sean-k-mooneywhen did neutron gain a concept of tags?12:34
sean-k-mooneyi guess it got network tags around the same time12:35
sean-k-mooneyand prot tag must of comple at a later point12:35
opendevreviewTakashi Kajinami proposed openstack/neutron-tempest-plugin master: Hide ssh_proxy_jump_password from debug log  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/95374612:40
sean-k-mooneyah looks like it was extened in https://github.com/openstack/neutron/commit/96f0142b8089a85f1a031f236c6d39fd463bf86c12:44
sean-k-mooneythat measn there are 2 ways to asign tags to ports, nova device role tagging and in neutorn directly. im not sure if we ever sync between the two sources of truth12:45
ralonsohsean-k-mooney, we have several resources that can have tags12:47
ralonsohports, networks, SG, etc12:47
sean-k-mooneyralonsoh: yep so looking at https://specs.openstack.org/openstack//nova-specs/specs/pike/implemented/virt-device-tagged-attach-detach.html#history the inital impleation in nova was done in mitaka for booting vms with tagged port which predates tags in neutron and it was complete for prot attach in pike12:48
ralonsohwhy? I can't reply to this, I would need to check the bug12:48
ralonsohso that was a RFE: https://bugs.launchpad.net/neutron/+bug/168277512:48
sean-k-mooneyyep which was compelted after we had device role taggin in nova but i dont think there was ever any work to sync to too12:49
sean-k-mooneyso right now there are 2 independet set of tag for neutron ports12:49
sean-k-mooneydevice roles tags implemtned  in nova's db12:49
sean-k-mooneysince newton in the virtual interfaces table12:50
sean-k-mooneyand native port tags in neutron db12:50
sean-k-mooneyi dont think the two are correated today12:50
ralonsohI didn't know we had this feature12:51
ralonsohhow Nova stores port tags?12:51
sean-k-mooneyi could be wrogn about that but since the nova feature predates the neturon one and it does nto refence neutron tages i assuem we never updated it12:51
ralonsohin nova db12:51
sean-k-mooneywe dont store the nueton ones at all as far as i am aware12:51
sean-k-mooneybtu the nova ones are in the virutal interfaces table12:51
sean-k-mooneyill get a link12:51
ralonsohso this is a nova feature and you store this info in nova DB12:52
sean-k-mooneyyep12:52
ralonsohI don't think both features are the same and for sure they won't clash12:52
sean-k-mooneythey wont but it can be confusting ot have 2 diffent sets of tags on an itnerface12:52
sean-k-mooneywe presetnt only the nova tags to the instnaces in teh metadtaa api12:52
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/db/main/models.py#L95712:53
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L4812:54
sean-k-mooneyso ya https://github.com/openstack/nova/blob/master/nova/network/model.py#L411-L442 nova does not store the neutron tags today12:55
sean-k-mooneyso they are independent but we also do not present them in the metatadata api so they they can only be used via neturon rest api which is proably ok12:56
opendevreviewTakashi Kajinami proposed openstack/neutron-lib master: sqlalchemy: Use built-in declarative  https://review.opendev.org/c/openstack/neutron-lib/+/95375213:07
opendevreviewTakashi Kajinami proposed openstack/neutron master: sqlalchemy: Use built-in declarative  https://review.opendev.org/c/openstack/neutron/+/95376613:23
opendevreviewTakashi Kajinami proposed openstack/neutron-lib master: sqlalchemy: Use built-in declarative  https://review.opendev.org/c/openstack/neutron-lib/+/95375213:24
tkajinamI wonder if anyone knows what https://github.com/openstack/os-ken/blob/master/os_ken/services/protocols/zebra/db/base.py is for ?13:26
ralonsohtkajinam, no idea, sorry13:27
ralonsohI don't think we use it, to be honest (in Neutron)13:27
tkajinammaybe we can just drop it ?13:28
slaweqtkajinam it is one of the many things which came to os-ken from ryu when we've forked it13:28
slaweqbut we are for sure not using it in Neutron13:28
ralonsohI think it is safe to drop it 13:28
slaweqI think we can drop it from os-ken easily13:28
ralonsohas slaweq said, we don't use it13:28
tkajinamI noticed it uses an old sqlalchemy interface (which I'm fixing in a few other neutron repos). I see the zebra module os-ken depends on sqlalchemy but it doesn't declare that dependency13:29
tkajinamI can "fix" it technically but if we expect no usage then dropping the module makes more sense13:29
ralonsohdon't spend time on this13:33
ralonsohjust delete it13:33
tkajinamyeah13:33
opendevreviewTakashi Kajinami proposed openstack/neutron-tempest-plugin master: Remove deprecated options to enable/disable plugin tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/95374113:34
opendevreviewRodolfo Alonso proposed openstack/neutron master: Change "tag" table collation to "utf8mb4_bin"  https://review.opendev.org/c/openstack/neutron/+/95376813:36
ralonsohykarel, ^13:36
ykarelralonsoh, ack thx13:46
opendevreviewTakashi Kajinami proposed openstack/neutron-lib master: sqlalchemy: Use built-in declarative  https://review.opendev.org/c/openstack/neutron-lib/+/95375213:50
lajoskatonakajinam: https://docs.frrouting.org/projects/dev-guide/en/latest/zebra.html , I suppose we can drop it from os-ken, FRR host for it maintained code and as that is already used by some Netrowking projects can be a better choice14:00
ykarel#startmeeting neutron_ci14:01
opendevmeetMeeting started Mon Jun 30 14:01:42 2025 UTC and is due to finish in 60 minutes.  The chair is ykarel. Information about MeetBot at http://wiki.debian.org/MeetBot.14:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'neutron_ci'14:01
ykarelPing list: bcafarel, lajoskatona, slawek, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva, elvira14:01
ralonsohhi14:01
slaweqo/14:02
mlavalle\o14:02
lajoskatonao/14:02
bcafarelo/14:02
mlavalleis this video or only IRC?14:02
ykarelIRC14:03
lajoskatonaack14:03
ykarelk lets start with topics14:04
ykarelthese are from last to last week as last week we didn't met14:04
ykarel#topic Actions from previous meetings14:04
ykarelralonsoh to check issue with test_create_bridges14:04
ralonsoh#link https://review.opendev.org/c/openstack/neutron/+/95282814:04
ykarelthx ralonsoh14:05
ykarelralonsoh to check https://bugs.launchpad.net/neutron/+bug/211473214:05
ralonsoh#link https://review.opendev.org/c/openstack/devstack/+/95339814:05
ralonsohtesting patch: https://review.opendev.org/c/openstack/nova/+/95340214:06
ykarelthx ralonsoh 14:06
ralonsohjob is passing14:06
ykarelgmaan, can you check ^14:06
ykarelykarel to report bug for test_direct_route_for_address_scope failure14:06
ykarelreported https://bugs.launchpad.net/neutron/+bug/211502614:07
ykarelalso found test_fip_connection_for_address_scope impacted for similar reasons so included that as well part of bug report14:07
ykarelmoved these tests to run with concurrency 1 , that helped for test_direct_route_for_address_scope but we still seeing it for test_fip_connection_for_address_scope14:08
ykarelcan discuss while we look into failures14:08
ykarel#topic Stable branches14:08
bcafarelI am still behind on my reviews but from what I saw overall stable branches looked in good shape14:09
ykarelthx bcafarel for the update14:09
bcafarelthanks to lajos, rodolfo, brian, and you for also keeping the queue short there :)14:09
ykarelfrom periodic we have tobiko job broken, can check that during failure discussion14:09
ykarel#topic Stadium projects14:09
ykarelall green in periodics14:09
ykarellajoskatona, anything to add?14:09
lajoskatonanothing from my side, all green this week as you said, fingers crossed :-)14:10
ykarel#topic Rechecks14:10
ykarelwe still have couple of rechecks due to random known issues, mostly it's related to functional tests14:11
ykarelbare recheck wise we have 3/25 14:11
ykarel2 of them were in same patch14:11
ykarellet's keep avoiding bare rechecks14:11
ykarel#topic fullstack/functional14:11
ykareltest_fip_connection_for_address_scope14:12
ykarelhttps://bugs.launchpad.net/neutron/+bug/211502614:12
ykarelfor this case seeing behavior https://bugs.launchpad.net/neutron/+bug/2115026/comments/314:13
ykareli.e after adding arp entry manual or pinging the router gateway port, fip pings starts working in local reproducer14:13
ykarel^ i have observed for test test_direct_route_for_address_scope14:14
ralonsohthat shouldn't be the normal behaviour, right?14:14
ykarelyes this observed only when issue reproducing14:14
ykareldo you see what can trigger this behavior ?14:15
ykareli recall seeing something in past but can't find a bug for that14:15
ralonsohI'll try to find it tomorrow morning14:16
ykarelok thx ralonsoh 14:16
ykareland for test_fip_connection_for_address_scope seeing different behavior14:16
ykareli.e test fails with ProcessExecutionError("Exit code: 1; Cmd: ['ip', 'netns', 'exec', 'test-b619fe36-b473-4ea7-9103-35d5754d27ae', 'ping', '-W', 1, '-c', 3, '19.4.4.11']; Stdin: ; Stdout: PING 19.4.4.11 (19.4.4.11) 56(84) bytes of data.\n\n--- 19.4.4.11 ping statistics ---\n3 packets transmitted, 0 received, 100% packet loss, time 2036ms\n\n; Stderr: ")14:17
ykarelif i run that manually i see14:17
ykarelseeing dup packets https://paste.openstack.org/show/bFDgf9Q7FFI8aYnvYwSx/14:18
ykareland rerun same command works fine https://paste.openstack.org/show/bDq8b7xK1c5Lj9IwIogD/14:19
ykareldo you recall something like that?14:19
ralonsohno, sorry14:19
ykarelif anyone recalls something please update it on the bug14:20
ykareltest_floatingip_mac_bindings random failures14:21
ykarelhandled with timeout increase https://review.opendev.org/q/Ia153b48aaec72e6a073b313ef2aea8efac6dbbae14:21
ykarel#topic Tempest/Scenario14:21
ykarelrandom fail image customize14:21
ykarel https://369db73f1617af64c678-28a40d3de53ae200fe2797286e214883.ssl.cf5.rackcdn.com/openstack/0fe5092db63d45c2882910c3dd641526/job-output.txt14:21
ykarelattempted in past but needs to be reworked https://launchpad.net/bugs/211019114:21
ykarelthat used to work for focal for not jammy so needs to be checked, i will check that14:22
ykarel#action ykarel to check https://launchpad.net/bugs/2110191 for jammy14:22
ykarelAlso for a few days last week with etcd.service failed because the control process exited with error code but not seeing it now so not reported a bug for it14:23
ykarelbut found an attempt to bump etcd with https://review.opendev.org/c/openstack/devstack/+/952755 from tkajinam 14:23
ykarelmay be that's related 14:23
lajoskatonasomewhere frickler mentioned that it was some infra issue in tha background14:24
ykarelohkk not seeing since 26th concluded it must be resolved by something :)14:25
ykarel#topic Periodic14:25
ykarelmariadb jobs(centos 9-stream/debian-bookwarm) broken with https://review.opendev.org/c/openstack/neutron/+/95281914:25
ykarelBug https://bugs.launchpad.net/neutron/+bug/211562914:25
ykarelralonsoh, pushed a fix for that, i will abandon the revert patch14:25
ykareldevstack tobiko job broken in stable/2024.1 and 2024.2 with https://review.opendev.org/c/x/devstack-plugin-tobiko/+/95288614:26
ykarelNeed to check with eolivare_ slaweq on this14:26
ykarel#action ykarel to report bug for tobiko job failure in stable14:26
slaweqlooking14:27
ykarelthx slaweq can be checked offline, moving ahead14:27
ykarel#topic Grafana14:27
ykarelhttps://grafana.opendev.org/d/f913631585/neutron-failure-rate14:27
ykarellet's have a quick look here too14:27
ykarelso we no longer have fullstack jobs in master so they can be cleaned from dashboard14:29
ykarelralonsoh, no plan to bring those job back, right?14:29
ralonsohI'll push the patches14:29
ralonsohno for now14:29
ykarelk thx14:29
ykarel#action ralonsoh to cleanup fullstack jobs from grafana dashboard14:30
ykarelapart from that looks normal, known failures and patch specific failures14:30
ykarelanything to add?14:30
lajoskatonafor fullstack there's an etherpad also to track: https://etherpad.opendev.org/p/migrate_Neutron_fullstack_to_Tempest14:30
ykarelthx lajoskatona 14:31
lajoskatonaso if you have some time and grab tests here you can mark that14:31
lajoskatonaI started some analysis also, but no time since last week to finish that14:31
ykarelok14:31
ykarel#topic On Demand14:32
ykarelanything else you would like to raise?14:32
lajoskatonanothing from me14:33
bcafarelall good for me14:35
ykarelassuming same for others :)14:35
ykarelok in that case let's close early and have everyone almost 25 minutes back14:35
ykarelthx everyone for joining14:35
ykarel#endmeeting14:35
opendevmeetMeeting ended Mon Jun 30 14:35:40 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:35
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-06-30-14.01.html14:35
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-06-30-14.01.txt14:35
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2025/neutron_ci.2025-06-30-14.01.log.html14:35
lajoskatonao/14:35
ralonsohbye14:36
mlavalle\o14:36
slaweqo/14:37
tkajinamykarel, the issue with etcd is not directly related to that bump. See https://bugs.launchpad.net/devstack/+bug/2115338 14:41
tkajinamthe problem is caused by a misbehavior in nodepool which results in using a floating ip (which is not present in the node) as LOCAL_IP14:41
tkajinamykarel, I hope the issue is now resolved but if you see the issue happens again then ping me14:42
ykareltkajinam, thx for the details14:44
toreAnyone know if the «Neutron BGP integration upstream sync» Google Meet scheduled for right now is still on? The page is still «Asking to be let in…»15:06
ralonsohhaleyb, hello! If you have some time: https://review.opendev.org/q/topic:%22eventlet-removal%22+project:openstack/neutron+status:open15:15
ralonsohthanks in advance15:15
opendevreviewMerged openstack/neutron stable/2025.1: Limit trunk ACTIVE state hack to OVN  https://review.opendev.org/c/openstack/neutron/+/95343716:30
opendevreviewMerged openstack/neutron stable/2024.2: Limit trunk ACTIVE state hack to OVN  https://review.opendev.org/c/openstack/neutron/+/95343816:30
opendevreviewMerged openstack/neutron stable/2024.1: Limit trunk ACTIVE state hack to OVN  https://review.opendev.org/c/openstack/neutron/+/95343916:30
opendevreviewEduardo Olivares proposed openstack/neutron stable/2024.1: DNM: verify tobiko jobs fixed on 2024.1  https://review.opendev.org/c/openstack/neutron/+/95380916:32
opendevreviewEduardo Olivares proposed openstack/neutron stable/2024.1: DNM: verify tobiko jobs fixed on 2024.1  https://review.opendev.org/c/openstack/neutron/+/95380916:36
eolivareykarel, slaweq checking fix for the tobiko issue: https://review.opendev.org/c/openstack/neutron/+/95380916:37
*** iurygregory__ is now known as iurygregory16:58
opendevreviewMerged openstack/neutron master: Remove deprecated plugin argument from policy calls  https://review.opendev.org/c/openstack/neutron/+/94717517:15
opendevreviewMerged openstack/neutron master: [eventlet-removal] ovs: reimplement signals handling  https://review.opendev.org/c/openstack/neutron/+/93932118:06
*** iurygregory_ is now known as iurygregory18:07
opendevreviewAnas Jouhdy proposed openstack/os-ken master: Fixing the BGP loop prevention  https://review.opendev.org/c/openstack/os-ken/+/95363120:50

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