Tuesday, 2023-04-18

opendevreviewSam Morrison proposed openstack/neutron master: [OVN] Add new ML2 extension "dhcp_agent_scheduler"  https://review.opendev.org/c/openstack/neutron/+/86508101:20
opendevreviewyatin proposed openstack/neutron master: [DNM] check 880586  https://review.opendev.org/c/openstack/neutron/+/88070405:13
slaweqykarel lajoskatona obondarev hi, can one of You check patch https://review.opendev.org/c/openstack/neutron/+/880656/ and those which are below this one?08:35
slaweqthx in advance08:35
obondarevsure08:36
slaweqthx08:42
opendevreviewliuxie proposed openstack/neutron-lib master: New api-def: allowedaddresspairs-atomic  https://review.opendev.org/c/openstack/neutron-lib/+/88061509:45
rubasovralonsoh, obondarev_: hi guys! can you please decide together which loading strategy is preferred? https://review.opendev.org/c/openstack/neutron/+/870081/9..15/neutron/db/models/port_hints.py#b3310:14
obondarev_rubasov, ralonsoh: I replied in the patch10:19
*** obondarev_ is now known as obondarev10:20
rubasovobondarev: thank you10:20
opendevreviewMerged openstack/neutron-lib stable/wallaby: Fix pep8 errors with pytlint v2.16.0  https://review.opendev.org/c/openstack/neutron-lib/+/87441210:28
ralonsohrubasov, let me check10:31
ralonsohrubasov, done. Please revert the file mode and check https://review.opendev.org/c/openstack/neutron/+/870081/9..15/neutron/db/port_hints_db.py10:34
ralonsohthe rest of the patch looks fine. If you push an update, ping me for a +210:34
rubasovralonsoh: thank you too! I deleted that __init__.py and will push a new patchset in a few minutes.10:36
ralonsohperfect10:36
opendevreviewBence Romsics proposed openstack/neutron master: port-hints: api extension  https://review.opendev.org/c/openstack/neutron/+/87008110:40
opendevreviewBence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: agent side  https://review.opendev.org/c/openstack/neutron/+/87290510:40
opendevreviewBence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: shim extension  https://review.opendev.org/c/openstack/neutron/+/87311310:40
opendevreviewBence Romsics proposed openstack/neutron master: DNM debug logs and dev helper scripts  https://review.opendev.org/c/openstack/neutron/+/87290610:41
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Apply admin_state_up on a new member creation  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/88073711:13
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Apply admin_state_up on a new member creation  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/88073712:14
ralonsoh#startmeeting networking14:01
opendevmeetMeeting started Tue Apr 18 14:01:04 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:01
opendevmeetThe meeting name has been set to 'networking'14:01
ralonsohPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:01
mlavalleo/14:01
sahid_o/14:01
mtomaskao/14:01
slaweqo/14:01
obondarevo/14:01
ralonsohhello all14:01
bcafarelo/14:01
rubasovo/14:01
ykarelo/14:01
ralonsohok, I think we can start now14:02
lajoskatonao/14:02
ralonsoh#topic announcements14:02
ralonsoh#link https://releases.openstack.org/bobcat/schedule.html14:02
ralonsohin 3 weeks, we'll have the bobcat-1 milestone14:02
ralonsohand in 2 months the Vancouver summit!14:02
ralonsohI would like to refresh the link for the summit14:03
ralonsoh#link https://etherpad.opendev.org/p/neutron-vancouver-202314:03
ralonsohof course, as usual, please check the openinfra videos14:03
ralonsoh#link https://openinfra.dev/live/#all-episodes14:03
ralonsohand finally, the oslo.db 13.0.0 release 14:04
ralonsoh#link https://review.opendev.org/c/openstack/releases/+/88065914:04
opendevreviewyatin proposed openstack/neutron master: [DNM] check 880586  https://review.opendev.org/c/openstack/neutron/+/88070414:04
ralonsohthat should have full support for sqlalchemy 2.014:04
ralonsohso just a heads-up14:04
lajoskatonais that already bumped in requirements?14:04
ralonsohnot yet14:04
lajoskatonaok, thanks14:05
ralonsohbut here is the link14:05
ralonsoh#link https://review.opendev.org/c/openstack/requirements/+/88072914:05
ralonsoh(and Neutron is not failing)14:05
ralonsohbut remember this is not bumping sqlalchemy14:05
ralonsohonly oslo.db with support for 2.014:05
lajoskatonaack, thanks for the headsup14:06
ralonsohsomething else I'm missing here?14:06
ralonsohok, let's move on14:06
ralonsoh#topic bugs14:06
ralonsohlast week I was the bug deputy14:07
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033393.html14:07
ralonsohand there are some bugs to be discussed/assigned14:07
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201641314:07
ralonsohI think this is a low hanging fruit one14:07
ralonsohI'll add the tag14:07
ralonsohso please check it if you want to collaborate with documentation14:08
ralonsohnext one is14:08
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201619814:08
ralonsohthat is related to https://bugs.launchpad.net/neutron/+bug/201619714:09
ralonsohshould we bring this topic to the drivers meeting?14:09
mlavalleit's a bug, isn't it?14:09
ralonsohthe first one yes14:09
ralonsohbut the suggestion is to limit the port creation in a network without subnets14:10
mlavalleahh,14:10
ralonsohthat I don't think should be done because of a race condition14:10
mlavalleI get it14:10
ralonsohso LP#2016198 should be addressed, but LP#2016197 should not be the solution14:10
ralonsohIMO14:11
lajoskatonalet's discuss it during the drivers meeting14:11
ralonsohI'll move this topic then14:11
lajoskatonaok, thanks14:11
ralonsohlast one is14:11
mlavalleyes, that's probably a good idea14:11
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201584414:11
ralonsohin a nutshell, OpenStack is removing windows support14:11
ralonsohthis code is not tested in the CI14:12
slaweqregarding recent discussion about winstackers project that it will be gone I think we should remove completely this windows bits from neutron14:12
ralonsohfirst deprecate and then remove?14:12
slaweqbut we should probably follow deprecations policy so deprecate it in this cycle14:12
ralonsohperfect14:12
sahid_if windows is not supported anmore no need to maintain all that code14:12
slaweqand remove in 2024.2 at least14:12
ralonsohyes, that should be in 2 cycles14:13
ralonsohin D14:13
mlavalle++14:13
ralonsoh+114:13
lajoskatona+114:13
slaweqwe need to keep it deprecated for at least one SLURP release14:13
slaweqwhich will be C in this case14:13
ykarel+114:13
obondarev+114:13
slaweqI can deprecate it14:13
mtomaska+114:13
ralonsohok, decided, I'll comment that in the LP14:13
ralonsohslaweq, thanks, please propose the patches14:13
slaweqI will propose patch, sure14:13
ralonsohand assign that to you14:13
ralonsohwe can consider this LP closed with the deprecation14:14
ralonsohand in 1 year, we'll create a new one to remove the code14:14
slaweq++14:14
mlavalleLOL, close a LP by removing the related code14:14
ralonsohyes, just to track it14:14
slaweqmlavalle we should follow that practice more often :P14:14
ralonsohbut I would prefer not to have this LP open 1 year14:15
ralonsohok, that was fast 14:15
ralonsohthis week lucasgomes is the deputy, next week will be jlibosva14:15
ralonsohI know lucasagomes is aware14:15
ralonsohI'll ping Jakub next week14:15
ralonsohsomething else you want to discuss here?14:15
ralonsohyes, one more14:16
ralonsohhttps://ubuntu.com/security/CVE-2023-166814:16
ralonsohthis is a problem in OVS14:16
ralonsohI know there is a list of patches to fix that14:16
ralonsohand the mail from ovs-discuss14:17
ralonsohhttps://www.openwall.com/lists/oss-security/2023/04/06/114:17
ralonsohthat is affecting ML2/OVS and ML2/OVN14:17
ralonsohwell, I don't know if that is possible in OVN14:17
ralonsohbut we can create this rule in OVS FW14:18
ralonsohin any case, this is a heads-up14:18
ralonsohok, something else?14:18
ralonsohok, I'll skip the spec reviewal as we don't have any active one14:19
ralonsoh#topic community_goals14:19
ralonsoh1) Consistent and Secure Default RBAC 14:19
ralonsoh#link https://review.opendev.org/c/openstack/neutron/+/87982714:19
ralonsohI think we don't have active bugs, slaweq ?14:19
slaweqnothing new this week14:20
ralonsohbtw, https://review.opendev.org/c/openstack/neutron/+/880461/14:20
slaweqI'm still working on patch https://review.opendev.org/c/openstack/neutron/+/879827/14:20
ralonsohis failing in neutron-tempest-plugin-openvswitch-enforce-scope-new-defaults14:20
ralonsohyes, this is the 4th patch of the series14:20
ralonsohbut is failing the 1st14:20
slaweqohh, I will need to check it14:20
ralonsohok, I think this is just a red herring14:21
slaweqit failed because of issue with installation of packages14:21
ralonsohsomething with the mirrors, nothing else14:21
ralonsohyes14:21
slaweqnothing relevant to patch itself14:21
ralonsoh(much better)14:21
lajoskatonafingers crossed14:21
ralonsohso we are almost ready to merge the sRBAC by default in Neutron14:21
slaweqand main patch to enable new policies by default is almost there, just about 300 UT to fix still14:22
slaweqand 200 FT14:22
ralonsohnahhh almost nothing...14:22
ralonsoh(ping for help if needed)14:22
slaweqbut once all that will be done, we will also have a bit better coverage of policy testing in UT as all such tests will make API requests with proper context14:22
slaweqnot without context at all14:23
ralonsohso we need to review all UTs to use the proper context?14:23
slaweqI will definitely bother You all with review requests once it will be green14:23
ralonsohperfect14:23
slaweqralonsoh not all but many which are using api to e.g. create resources14:24
slaweqlike many tests for extensions14:24
slaweqor ml2 plugin14:24
slaweqor db modules14:24
slaweqI'm on it and it's high priority for me to finish it ASAP14:24
ralonsohthank you14:25
lajoskatonathanks slaweq14:25
ralonsohok, the second topic is14:25
ralonsoh2) Neutron client deprecation 14:25
ralonsohI 've identified 3 active patches14:25
ralonsoh#link https://review.opendev.org/c/openstack/python-neutronclient/+/88062914:25
ralonsoh#link https://review.opendev.org/c/openstack/python-neutronclient/+/87572814:26
lajoskatonayes, I started to work on fwaas CLI14:26
ralonsoh#link https://review.opendev.org/c/openstack/python-neutronclient/+/86832114:26
lajoskatona880629 is wip (this is for fwaas)14:26
ralonsohso we have the OSC/SDK code merged for fwaas?14:27
lajoskatonathe patch for octavia is also in good shape: https://review.opendev.org/c/openstack/octavia/+/866327 (thanks octavia team)14:27
lajoskatonaralonsoh: yes it is already done (https://review.opendev.org/c/openstack/openstacksdk/+/592303  )14:27
ralonsohperfect14:27
lajoskatonaso if yo have time you can even check the octavia patch14:28
ralonsoh^^ fantastic the patch in octavia, good to see traction outside Neutron team14:28
lajoskatonaagree, we had the same good example from designate14:28
lajoskatonathat's it from me for the neutronclient topic14:29
ralonsohthanks!14:29
ralonsohand that's all!14:29
ralonsoh#topic on_demand14:29
ralonsohI have one topic but was discussed in the bug section14:29
ralonsohso please, if you have something, this is the moment14:29
slaweqI wanted to ask people about ideas for forum sessions in vancouver14:30
slaweqdo You have any ideas what we can propose there?14:30
ralonsohthe forum proposals ends this Friday14:31
lajoskatonanot sure but the RBAC as default would be interesting even for operators14:31
ralonsohactually it is14:31
ralonsohthat was a request from operators14:31
slaweqlajoskatona but what You want exactly discussing regarding RBAC?14:31
ralonsohyeah, maybe this is a topic for a presentation, not a forum14:32
lajoskatonawhat kind of new personas they have to use and what can be expected? things like that14:32
lajoskatonabut presentation proposal is closed :-) so we have the forum only now >/(14:33
mlavallea general operators feedback session?14:33
slaweqlajoskatona but this actually is something broader than Neutron only thing14:33
slaweqso maybe S-RBAC team will propose some session14:33
lajoskatonaok14:33
lajoskatonamlavalle: that can be interesting anytime I suppose14:33
slaweqI don't think we should have any neutron specific discussion about it with operators, at least not something for separate session14:33
mlavalleyeap14:34
mlavalleand this would be the first time face to face in a long time14:34
slaweqmlavalle yes, I was also thinking about "general feedback session"14:34
mlavalleanother one might be discussion on scalability issues14:35
slaweqand ask operators about what features/plugins/drivers they are using, what are their pain points, etc.14:35
lajoskatona+114:35
slaweqand my idea was to ask operators question like "If You could choose one thing which will be fixed in Neutron, what it would be" to see if there would be any pattern there, maybe all of them needs the same thing to be there :)14:35
ralonsoh^^ right14:36
mlavalleyes, we can start with a menu of teaser questions and then see where the discussion goes14:36
mlavalleto uncover pattersn, as you say slaweq 14:37
ralonsohok, tomorrow we'll present, in this channel, some proposals14:38
ralonsohand then you'll approve then or not14:38
ralonsohand then we'll register them14:38
ralonsohok?14:38
lajoskatonasounds good14:38
slaweq++14:38
ralonsohwe are running out of time and we need to ground something14:38
ralonsohperfect then14:38
mlavallewhat time? don't forget us, the ones on this side of the pond14:38
ralonsohof course, at this time more or less14:39
mlavallesay around 1400 utc?14:39
ralonsohok14:39
mlavallecool14:39
mlavallegood time for me14:39
sahid_lajoskatona, rubasov o/14:40
ralonsohok, I think that's all for today14:40
sahid_quick question regarding https://review.opendev.org/c/openstack/neutron/+/872905/1514:40
sahid_oh sorry i think the meeting was finished :-)14:40
ralonsohnot yet14:40
ralonsohone sec14:40
ralonsohplease remember the CI meeting is in 20 mins in this channel14:41
ralonsoh#endmeeting14:41
opendevmeetMeeting ended Tue Apr 18 14:41:10 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:41
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18-14.01.html14:41
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18-14.01.txt14:41
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18-14.01.log.html14:41
ralonsohbye14:41
slaweqand it will be on video this week14:41
lajoskatonabye14:41
slaweqo/14:41
mlavalleslaweq: video this week14:41
mlavalle?14:41
ykarelbye14:41
lajoskatonasahid_: Hi14:41
lajoskatonasalweq: ack14:41
mtomaskao/14:41
mlavalleo/14:41
rubasovsahid_: hi14:41
slaweqmlavalle: yes14:41
obondarevo/14:43
sahid_i wanted to be sure that I have well understand you points14:44
sahid_i means if the operator is trying to enable that feature, and he made a typo14:44
sahid_he will never know that, right?14:44
rubasovhe should, because the server-side validation should catch typos14:45
sahid_ok, so basically a keyerror may never happen?14:45
sahid_s/may/will14:45
rubasovthere's one case that we don't catch server side, IIRC that is when the hints field has an empty dict at some level14:45
sahid_s/may/will14:46
rubasovIIRC my reason was to allow that input, that otherwise future expansion of the server side validator expression would become much harder14:46
slaweqralonsoh did You know that in some case(s) we are expecting error 500 to be returned from neutron: https://github.com/openstack/neutron/blob/master/neutron/tests/unit/plugins/ml2/test_plugin.py#L453 ?14:46
slaweqshould it be like that really? Do You know?14:47
sahid_so the current behavior is to catch a expected keyerror?14:47
sahid_an14:47
ralonsohslaweq, never a 500 error14:47
slaweqbut look at this test14:47
rubasovso for example this is fully correct input for the hints field: {"openvswitch": {"other_config": {"tx-steering": "thread"|"hash"}}}14:47
ralonsohpffff14:47
slaweqit litterally asserts that response is 50014:47
slaweq:D14:47
sahid_i think my issue is because we mix catching an expected behavior and unexpected behavior14:47
ralonsohyeah, that is not acceptable, we should fail with a 4xx error14:47
rubasovbut server we may allow something like this too {"openvswitch": {"other_config": {}}}14:48
sahid_yes and this will raise a keyerror right?14:48
ralonsohslaweq, let me check why this is happening14:48
rubasovsahid_: yes14:48
slaweqralonsoh https://review.opendev.org/c/openstack/neutron/+/23508614:49
slaweqthis is patch which added it14:49
sahid_i think this mix is making the code a bit complicated to maintain (for future people working on it) as like mentioned we are mixing valide and not valid cases14:49
sahid_rubasov: why not to specically add that valid condition on hints?14:50
sahid_and use a keyerror for the other unvalid and unexpected condition? and probably log something14:50
ralonsohslaweq, actually that could make sense there14:51
ralonsohthis is because we are mocking the methid14:51
ralonsohand is raising RetryRequest14:52
ralonsohif we can't access to the DB, we should raise 5xx14:52
rubasovI did not add full input validation to the agent, because 1) that would be code duplication 2) because this agent should not know about the rest of the hints data structure14:52
slaweqok, but at first glance it seems weird :)14:52
ralonsohyes14:52
rubasovregarding 2: for example if a new hint is added that should be handled by another agent, then the code of this agent should not be needed to change14:53
rubasovthat was the reason behind having only two cases: either the hint handled by this agent is there, or in any other cases delete the hint from ovs other_config, because this agent should not know what other values are valid14:54
sahid_I think I understand your point and I don't think this is in conflict with my suggestion to separe valid and unexpected case for an agent or perhaps something is confusing me14:58
slaweq#startmeeting neutron_ci15:00
opendevmeetMeeting started Tue Apr 18 15:00:14 2023 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'neutron_ci'15:00
slaweqping bcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva, elvira15:00
slaweqci meeting on https://meetpad.opendev.org/neutron-ci-meetings15:00
* bcafarel in another video meeting, nothign special from me on stable branches15:00
slaweqGrafana dashboard: https://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=115:02
slaweq#topic Actions from previous meetings15:02
slaweqslaweq to check dhcp issue in fullstack tests15:02
slaweq#action slaweq to check dhcp issue in fullstack tests15:03
slaweq    lajoskatona to check neutron-ovs-grenade-dvr-multinode job's failures15:03
lajoskatonahttps://bugs.launchpad.net/neutron/+bug/201506515:03
rubasovsahid_: I'm honestly not sure that if we add a 6-line if condition in front of the relevant piece, that will make anything clearer15:04
rubasovsahid_: but I can try again15:04
sahid_rubasov: no no let's move on it, the implementation is working and we can still rework parts in needed in future :-)15:12
rubasovsahid_: thanks15:13
slaweqykarel to check issue with neutron-ovn-grenade-multinode-skip-level15:14
sahid_rubasov: no thank you for your time and patience :)15:15
slaweq#topic Stadium projects15:15
lajoskatonahttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_542/periodic-weekly/opendev.org/openstack/neutron-dynamic-routing/master/neutron-dynamic-routing-openstack-tox-py310-with-sqlalchemy-main/54236ee/testr_results.html15:16
slaweq#topic Grafana15:16
slaweq#topic Rechecks15:17
slaweq#topic fullstack/functional15:18
slaweqneutron.tests.functional.agent.ovn.extensions.test_qos_hwol.OVSInterfaceEventTestCase.test_port_creation_and_deletion15:18
slaweqhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_78e/858879/30/check/neutron-functional-with-uwsgi/78e0492/testr_results.html15:19
slaweqhttps://dbc11b7f31cbdf1f5ec2-331f643549901f103f739b23815fad4a.ssl.cf5.rackcdn.com/873850/6/check/neutron-functional-with-uwsgi/5e6cda2/testr_results.html15:19
ralonsoh--> https://bugs.launchpad.net/neutron/+bug/200660315:20
slaweqhttps://32177b17610869e1b83a-af1192da167b817506a58f20e6af9357.ssl.cf2.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-uwsgi-fips/dc3710e/testr_results.html15:20
slaweq#action mtomaska to check and fix "no such process" error in kill cmd15:24
slaweq#topic Tempest/Scenario15:24
slaweqhttps://8efce70e72afb45d6ec7-62d3a5548ea094caef4a9963ba6c55d1.ssl.cf5.rackcdn.com/880461/6/check/neutron-ovs-tempest-multinode-full/1ee5b2f/testr_results.html15:24
slaweq#action slaweq to open bug regarding shelve/unshelve failures15:25
slaweq#topic On Demand15:26
slaweq#endmeeting15:34
opendevmeetMeeting ended Tue Apr 18 15:34:29 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:34
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-18-15.00.html15:34
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-18-15.00.txt15:34
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-18-15.00.log.html15:34
amorinHey neutron team, ralonsoh, about ovs bug you talked about earlier. You said fw is affected, is it fwaas or secgroups is ovs?15:37
amorinDo you have an ex of OpenStack commands to reproduce?15:37
opendevreviewTerry Wilson proposed openstack/ovsdbapp master: Add support for clearing map column keys  https://review.opendev.org/c/openstack/ovsdbapp/+/87936716:37
opendevreviewSlawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default  https://review.opendev.org/c/openstack/neutron/+/87982717:12
opendevreviewSlawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default  https://review.opendev.org/c/openstack/neutron/+/87982717:48
opendevreviewMiro Tomaska proposed openstack/neutron master: Handle no more IP addresses available during a network sync  https://review.opendev.org/c/openstack/neutron/+/88077318:28
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: Add a method to retrieve router gateway ports  https://review.opendev.org/c/openstack/neutron/+/87946218:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: Allow Multiple External Gateways  https://review.opendev.org/c/openstack/neutron/+/87359318:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: Add extra router attributes for ECMP and BFD  https://review.opendev.org/c/openstack/neutron/+/87479718:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Implement support for external-gateway-multihoming extension  https://review.opendev.org/c/openstack/neutron/+/87419918:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Honor `enable_default_route_ecmp` attribute  https://review.opendev.org/c/openstack/neutron/+/87853118:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Allow L3 scheduler to be aware of current transaction  https://review.opendev.org/c/openstack/neutron/+/87476018:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Add helper for retrieving LR associated with LRP  https://review.opendev.org/c/openstack/neutron/+/87369818:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Apply soft anti-affinity for LRs with multiple LRPs when scheduling  https://review.opendev.org/c/openstack/neutron/+/87369918:41
opendevreviewDmitrii Shcherbakov proposed openstack/neutron master: [ovn] Add support for enable_default_route_bfd attribute  https://review.opendev.org/c/openstack/neutron/+/87854318:41
opendevreviewTerry Wilson proposed openstack/ovsdbapp master: Add 'no timeout' option to wait_for_change  https://review.opendev.org/c/openstack/ovsdbapp/+/85780621:18
opendevreviewTerry Wilson proposed openstack/ovsdbapp master: Add 'no timeout' option to wait_for_change  https://review.opendev.org/c/openstack/ovsdbapp/+/85780621:29
opendevreviewTerry Wilson proposed openstack/ovsdbapp master: Add 'no timeout' option to wait_for_change  https://review.opendev.org/c/openstack/ovsdbapp/+/85780623:25

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