Tuesday, 2023-03-07

opendevreviewMerged openstack/neutron master: Remove duplicate rows in MySQL query output  https://review.opendev.org/c/openstack/neutron/+/87616800:46
opendevreviewIhar Hrachyshka proposed openstack/neutron master: functional: set dns_domain config option after its registration  https://review.opendev.org/c/openstack/neutron/+/87665603:10
opendevreviewIhar Hrachyshka proposed openstack/neutron master: ovn_idl_impl: fix a logic bug in get_sg_port_groups  https://review.opendev.org/c/openstack/neutron/+/87665703:10
opendevreviewIhar Hrachyshka proposed openstack/neutron master: ovn: store neutron:revision_number for Port_Groups  https://review.opendev.org/c/openstack/neutron/+/87665803:10
opendevreviewIhar Hrachyshka proposed openstack/neutron master: ovn: allow returning metadata packets for stateless security groups  https://review.opendev.org/c/openstack/neutron/+/87665903:10
tobias-urdinany plans to do a new yoga release? a lot of changes waiting for release, even the CVE merged back in September last year08:09
tobias-urdinseems like a xena release was done recently that included all that but not yoga08:10
opendevreviewSlawek Kaplonski proposed openstack/neutron-tempest-plugin master: Remove method which created ingress metadata rule in SG  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/87669208:30
slaweqhi ralonsoh, I commented in https://review.opendev.org/c/openstack/neutron/+/874767 - please check and let me know what do You think. If this isn't needed, I will approve that patch08:34
ralonsohslaweq, I'll check it now08:37
opendevreviewSahid Orentino Ferdjaoui proposed openstack/neutron master: ovs: fix regression when vlan mapping is not already registered  https://review.opendev.org/c/openstack/neutron/+/87657008:37
ralonsohtobias-urdin, there is a topic for today's meeting08:37
ralonsohtobias-urdin, you can also attend to the weekly Neutron meeting to ask this08:38
slaweqralonsoh ok, approved then, thx a lot09:19
tobias-urdinralonsoh: ack, thanks :)09:20
opendevreviewMerged openstack/networking-bgpvpn stable/2023.1: Update .gitreview for stable/2023.1  https://review.opendev.org/c/openstack/networking-bgpvpn/+/87583110:14
opendevreviewMerged openstack/neutron-fwaas-dashboard stable/2023.1: Update .gitreview for stable/2023.1  https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/87583810:15
opendevreviewMerged openstack/neutron-fwaas-dashboard stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1  https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/87583910:19
opendevreviewMerged openstack/networking-odl stable/2023.1: Update .gitreview for stable/2023.1  https://review.opendev.org/c/openstack/networking-odl/+/87587910:21
opendevreviewMerged openstack/networking-odl stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1  https://review.opendev.org/c/openstack/networking-odl/+/87588010:21
opendevreviewMerged openstack/neutron-vpnaas stable/2023.1: Update .gitreview for stable/2023.1  https://review.opendev.org/c/openstack/neutron-vpnaas/+/87586410:31
opendevreviewMerged openstack/neutron-vpnaas stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1  https://review.opendev.org/c/openstack/neutron-vpnaas/+/87586510:31
opendevreviewMerged openstack/networking-bgpvpn stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1  https://review.opendev.org/c/openstack/networking-bgpvpn/+/87583210:35
sahid_it's me or gerrit is a bit unstable?10:43
lajoskatonasahid_: what's wrong?10:50
opendevreviewLajos Katona proposed openstack/neutron master: OVS FW: Delete sg rule which remote is the deleted sg  https://review.opendev.org/c/openstack/neutron/+/87671610:50
lajoskatonasahid_: gerrit itself is ok for me10:50
sahid_lajoskatona: well it's not really gerrit, fetching  ssh://sahid@review.opendev.org:29418/openstack/neutron.git does not respond10:51
lajoskatonasahid_: for me it worked, just now11:00
slaweqralonsoh lajoskatona can You check https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/876052 - it would be good to include it in the neutron-tempest-plugin 2023.1 release: https://review.opendev.org/c/openstack/releases/+/87661611:26
slaweqthx in advance11:26
ralonsohslaweq, sure11:27
ralonsohslaweq, done, once merged, I'll update the release patch11:29
slaweqralonsoh++ thx11:43
opendevreviewMerged openstack/neutron master: Add 2023.1 release name in routed networks doc  https://review.opendev.org/c/openstack/neutron/+/87640713:11
zigoIt feels like to me that etc/oslo-config-generator/ovn_agent.ini is wrong, and should contain namespace = neutron.ovn.agent and not namespace = neutron.ml2.ovn.agent. Am I right?13:31
opendevreviewMerged openstack/neutron stable/2023.1: Change the release tag to use the release identification  https://review.opendev.org/c/openstack/neutron/+/87596913:32
opendevreviewMerged openstack/neutron master: Add Lajos Katona to Client and Doc areas as lieutenant  https://review.opendev.org/c/openstack/neutron/+/87591813:33
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules  https://review.opendev.org/c/openstack/neutron/+/87673213:36
ralonsohzigo, why? This is an agent like OVS agent, LB agent or SRIOV agent13:47
zigoralonsoh: The neutron.ml2.ovn.agent entry point is *NOT* an oslo.config entry point, look at the setup.cfg you'll see !13:49
zigoIn fact, it doesn't exist at all in setup.cfg.13:50
ralonsohzigo, so this is a missing bit from the implementation13:50
ralonsohI'll push a patch for this13:51
zigoralonsoh: neutron.ovn.agent is, I believe the correct entry point...13:51
ralonsohno, that was a mistake in the setup.cfg13:51
zigoralonsoh: Look at neutron/conf/agent/ovn/ovn_neutron_agent/config.py ...13:51
ralonsohwe are locating all agents on neutron.ml213:51
zigoIt really has list_ovn_neutron_agent_opts() as expected !13:52
ralonsohI know, I implemented it13:52
zigo:)13:52
ralonsohso what is wrong in setup.cfg13:53
zigoralonsoh: Nothing, what's wrong is etc/oslo-config-generator/ovn_agent.ini13:53
ralonsoh(in any case, this is currently not used, apart from very specific HW offload envs)13:53
zigoIt lists a non-existing entry point in the namespace list.13:53
ralonsohping bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 13:59
ralonsohwe'll start the meeting in 1 min13:59
ralonsoh#startmeeting networking14:00
opendevmeetMeeting started Tue Mar  7 14:00:23 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. 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
ralonsohhello all14:00
slaweqo/14:00
haleybo/14:00
obondarevo/14:00
elvirahi!14:00
rubasovo/14:00
bcafarelo/14:00
lajoskatonao/14:01
ralonsohlet's start! 14:01
ralonsoh#topic announcements14:01
ralonsohas usual, during this important weeks14:01
ralonsoh#link https://releases.openstack.org/antelope/schedule.html14:01
ralonsohthis week is the final release for the non-client libraries14:01
tobias-urdino/14:01
ralonsohsorry, no!14:02
ralonsoh(what I'm reading?)14:02
ralonsohnext week is the final week for the RC14:02
frickler\o14:02
ralonsohso far, nothing went wrong during the last week14:02
ralonsohwhen we merged the releases for all the Neutron related projects14:03
lajoskatonaCool14:03
fricklerreno generation is still a bit broken, but a fix is in the works14:03
ralonsohbut please, keep an eye on the CI and launchpad14:03
ralonsohfrickler, which one?14:03
frickler2023.1 sorts before zed and everything else, leading to duplicated entries14:03
ralonsohah yes yes14:04
ralonsohbut seems to be addressed now14:04
fricklerhttps://review.opendev.org/c/openstack/reno/+/876581 is the proposed fix14:04
ralonsohyeah and almost merged, so cool14:04
ralonsohah, I almost forgot, last week we had the "election" polling (there wasn't for Neutron as I was the only candidate)14:05
ralonsohso you'll have me again for the next 6 months14:05
ralonsohsorry for you!14:05
bcafarelcongratulations here's to 6 more months :)14:05
tobias-urdinlucky us! congrats :)14:05
lajoskatona+214:05
obondarevthank you, congrats!14:05
ralonsohand please, remember the PTG is very very close14:06
ralonsohand we have a not-so-active etherpad14:06
ralonsoh#link https://etherpad.opendev.org/p/neutron-bobcat-ptg14:06
ralonsohnext week I'll add all related to sqlalchemy, neutronclient and CI14:06
ralonsohbut if you have new features/RFE/bugs, please add them in this etherpad14:07
ralonsoh(I'll send another reminder today)14:07
ralonsohsomething else here??14:07
bcafareljust a stable service announcement, now that we have antelope branched14:07
bcafarelremember to also cherry-pick to this branch when doing a series of backports :)14:08
ralonsohright, 2023.114:08
ralonsoh(^^^ please don't make my mistake again: antelope is officially called 2023.1 in the code)14:08
lajoskatonayeah be careful as this breaks alphabetical order :-)14:08
ralonsohbtw, about this, I tested the patches renaming the DB branches14:09
ralonsohluckily the db migration tool only checks the migration IDs, not the directories14:09
ralonsohok, let's move to the next topic14:10
ralonsoh#topic bugs14:10
lajoskatonaIt was my week14:10
ralonsohexactly14:10
ralonsohthere is the report14:10
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032577.html14:10
lajoskatonathanks14:10
ralonsohmany bugs but most of them addressed or assigned under investigation14:11
ralonsoh(thanks for this active community!)14:11
lajoskatonaThere was only one which has no owner: https://bugs.launchpad.net/neutron/+bug/200904314:11
ralonsohthere are still 3 bugs to be discussed14:11
ralonsohyeah, this is the first one14:11
lajoskatonaactually the reporter just come back with some result what is the suspicion from their side14:11
ralonsohmaybe slaweq could check that 14:11
ralonsohif you have time14:11
lajoskatonaand I would like to as slaweq (or anybody more HA router knowledge) to check14:12
slaweqsure, I will try to check it this week14:12
ralonsohthanks a lot14:12
lajoskatonayes the reporter wrote that for them this patch is suspicios: https://review.opendev.org/c/openstack/neutron/+/77642314:12
lajoskatonaslaweq: thanks14:12
ralonsohthe next one is 14:13
lajoskatonathats all from the bugs of last week, all other bugs are active14:13
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200885814:13
ralonsohI would like you to check this one because the cause (and the fix proposed) are not solving the reported issue14:13
ralonsohwhat is failing there is the Neutron DB access, not the OVN connectivity14:14
lajoskatonaohh, I set it to inactive as there was no answer, but it is active again, thanks14:14
lajoskatonaok, thanks ralonsoh14:14
ralonsohI'll check it today but my opinion is the same: in this bug the problem is the DB access, not the OVN connection. This timeout will make things worst 14:15
ralonsohthe last one in this list is 14:15
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200880814:15
ralonsohbut seems inactive since the report14:15
ralonsohto be honest, I don't know how to replicate this14:16
ralonsohdid you have this problem before?14:16
ralonsohok, we'll wait for more info14:17
ralonsohthat's all from this list14:17
ralonsohThis week slaweq is the deputy, next week will be haleyb14:17
slaweqsure14:17
haleybthat works14:18
ralonsohcool, thanks both14:18
ralonsohlet's move to the next topic14:18
ralonsoh#community_goals14:18
ralonsoh1) Consistent and Secure Default RBAC 14:18
ralonsohwe have an active n-t-p patch14:19
ralonsoh#link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/87470914:19
ralonsohwith all the dependencies merged14:19
ralonsohbut seems that this job "neutron-tempest-plugin-openvswitch-enforce-scope-new-defaults" is failing14:19
slaweqI need to check why it's still failing14:19
ralonsohno rush and thanks14:19
slaweqmaybe we have missing something in neutron-lib, idk for now14:19
slaweqI will ping You once it will be ready to review14:20
ralonsohsure, remember that we'll need that too in Zed14:20
ralonsohactually what is failing is zed job14:21
slaweqyeah, in master it works fine, there is something missing in Zed just14:21
ralonsohnot master one14:21
slaweqin master I will work in this new cycle on the service role for communication between services14:21
slaweqand on making new policies to be enabled by default14:21
lajoskatonathat is already agreed with nova for example?14:22
ralonsohqq, the service role will be available only in Bobcat, right?14:22
slaweqlajoskatona what?14:22
slaweqralonsoh yes, I don't plan to backport it14:22
lajoskatonaI mean how the service role will be used for service-to-service comm14:22
slaweqit's agreed generally14:23
slaweqwe need to identify what calls may be only for service2service and will be available by this new role14:23
lajoskatonaok, thanks14:23
amotokiadmin role is too much and IIRC we agreed to use the service role for such communicatins.14:24
ralonsohyeah, this is not trivial to make a list of all S2S calls14:24
lajoskatonado we need to sit down with nova team to clarify the deatils or it will be enough to do the reviews?14:24
slaweqI think it will be enough to do reviews14:24
ralonsohbecause Nova is our client, they mostly should provide this info14:25
ralonsohbut we can have a cross session during the next ptg14:25
slaweqor if needed, I will add topic to the PTG to talk about that14:25
ralonsohto sync that14:25
slaweqbut need to check it first14:25
ralonsohcorrect14:25
ralonsohslaweq, will you ping Nova folks about this?14:25
ralonsohto know if they will be ready for this during the PTG14:25
slaweqralonsoh sure, if needed I will :)14:25
ralonsohperfect14:25
ralonsohthanks again for taking care of this14:26
ralonsohlet's move then14:26
ralonsoh2) Neutron client deprecation 14:26
ralonsohthe agenda: https://etherpad.opendev.org/p/python-neutronclient_deprecation14:26
ralonsohlajoskatona, something new?14:27
lajoskatonaI think no news14:27
lajoskatonathe usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation14:27
lajoskatonaI have to come back and push my patches as the last ones are still WIPs14:27
ralonsohduring the next PTG I'll add a topic for this, mostly to make it public, see what is the progress and to try to involve more people on this14:28
lajoskatonaI already added :-)14:28
ralonsohright, i see it14:28
lajoskatonaI will add some details, I just added a line for it14:28
ralonsohperfect14:28
ralonsohwe don't have a hard schedule, but let's see if during the next cycle we can deprecate nclient14:29
ralonsohthe whole project14:29
lajoskatonaok14:29
ralonsohand that's all in this topic14:30
ralonsohlet's move to the last one14:30
fricklerdidn't we want to keep it as osc-plugin?14:30
ralonsohthe plan is to move everything to sdk14:30
ralonsohand use the OSC, instead of the nclient14:30
fricklersdk is only one half14:30
lajoskatonawe want, but we can remove the python binding code14:30
fricklerbut we can discuss at the ptg. just invite gtema to that session14:31
ralonsohperfect14:31
amotokiI think we need moree discussion on osc-plugin from neutronclient14:31
amotokifrickler: right14:31
lajoskatonafrickler: good idea, I ask gtema f he can join14:31
amotokiour current target is python bindings14:31
fricklerright, that is undisputed afaict14:32
lajoskatonain the patches which are up for this topic I kept the CLI code in neutronclient, but change to use sdk and not neutronclient binding code14:33
ralonsohI think we can have this conversation in the PTG, but is there any limitation to move all the bindings to SDK?14:33
lajoskatona+114:33
fricklereven if that is finished, you still cannot deprecate the OSC-plugin part14:34
ralonsohno of course14:34
fricklero.k., maybe I misunderstood "deprecate nclient" then14:34
ralonsohbut we'll stop doing anything in nclient, that at least is a good goal14:34
amotokifrickler: no worries. neutronclient has two parts: CLI and python bindings, and it is always confusing :p14:35
fricklerwell if there happened to be a new feature in n-d-r for example that would require client support, that still would be added to nclient, wouldn't it? 14:36
ralonsohactually what was supposedly deprecated (the CLI) can't be yet removed14:36
ralonsohwell that's the point lajoskatona job here14:36
amotokiralonsoh: "neutron" CLI was deprecated but OSC plugin is still active I think14:36
ralonsohamotoki, right14:37
ralonsohif n-d-r is still using nclient, it should move to OSC14:37
ralonsohwe should avoid any new develpment in nclient14:37
fricklerall the "openstack bgp ..." commands are in nclient as osc-plugin14:38
amotokin-d-r support is now implemented as OSC plugin (not in OSC).14:38
fricklerand there are no current plans to change that, or are there?14:38
lajoskatonaI think we said that no plan for that14:38
lajoskatonaand let's keep the repos as OSC plugin14:39
amotokiperhaps what we first need to do is that OSC plugin for n-d-r consume openstacksdk instead of neutronclient python bindings14:39
lajoskatonaI mean neutronclient repo14:39
lajoskatonaamotoki: exactly, that's what I started14:39
frickleramotoki: that is what lajoskatona is working on I think, first moving the sdk code to openstacksdk repo14:39
amotokiyes14:39
amotokiat least we still need to add CLI commands to neutronclient OSC plugin14:40
amotokiif we would like to add new commands related to n-d-r, right?14:41
fricklerthat's my understanding, yes14:41
ralonsohand why not spend time first on moving all the bindings to SDK and use the OSC in n-d-r?14:41
ralonsohwe'll never finish the migration doing that14:41
lajoskatonayes but we have only one SDK for all these when it is finished14:42
amotoki+114:42
fricklerthe commands are implemented in neutronclient, not in n-d-r14:42
fricklerI can double check if n-d-r uses bindings from neutronclient somewhere14:43
amotokianyway the ptg session would be helpful to share the current situation and futures :-)14:43
amotokithe discussion here is a good example14:43
fricklerfrom a quick look n-d-r only uses rpc client14:44
frickleryes, let's go on and defer to PTG14:44
ralonsohok, let's move on14:45
ralonsoh#topic on_demand_agenda14:45
ralonsohI've been asked to release new versions for stable releases14:46
ralonsohX, Y and Z14:46
haleybU as well?14:46
ralonsohand that makes sense as we haven't done it for a long time14:46
ralonsohnot U14:46
ralonsohlet me check the state of U14:46
slaweqIsn't U in EM phase already?14:47
haleybthere have been some merges recently, one of which i'm interested in releasing14:47
haleybyes i do see the -em tag there14:47
ralonsohyeah, is in EM mode14:47
fricklercould that also become a regular topic? weekly is likely too often, but e.g. in kolla we do a monthly check whether stable releases should be done14:47
ralonsohI'll add it to the agenda14:48
ralonsohI'll check if we can push a new hash for EM branches14:48
ralonsohand how14:48
fricklerem gets no new tags14:48
ralonsohso that could be a problem then14:49
fricklerit is consumed only from stable/ussuri or whatever head14:49
ralonsohyes14:49
haleybwhy? i'm probably just forgetting14:49
ralonsohwhat I mean is if we can update the EM hash?14:49
fricklerwhat is "the EM hash"? move the ussuri-em tag: nope14:49
ralonsohyeah so the only next tag that a EM branch can have is EOL14:50
ralonsohright?14:50
frickleryes14:50
lajoskatonathats my undertsanding also, the tag is set to some hash and it cant be moved14:50
fricklerand that also drops the branch14:50
ralonsohhaleyb, so no, we can't release any new version for W and older14:50
opendevreviewMerged openstack/neutron master: Add full support for OVN NB "Gateway_Chassis" table  https://review.opendev.org/c/openstack/neutron/+/87476714:51
ralonsohabout Z, Y and X, I think you are ok with this, right?14:51
haleybralonsoh: ack, i'll ask our downstream team about it14:51
haleybi'm fine with releasing everything else, yes14:52
lajoskatonaagree for new release14:52
ralonsohok, I'll push the patches this week and I'll add all of you as reviewers14:52
lajoskatonathanks14:53
fricklersemi-related: is someone working on creating n-t-p zuul.d/2023.1_jobs.yaml ?14:53
ralonsohnot yet, I think (let me check)14:53
fricklerI didn't see a review at least14:53
ralonsohno, I'll do it too this week14:54
lajoskatonaI can check it14:54
ralonsohbtw, I almost forget14:54
ralonsohrelated to the stable releases14:55
opendevreviewMerged openstack/neutron stable/yoga: Reintroduce agent bridge resync test  https://review.opendev.org/c/openstack/neutron/+/87646414:55
ralonsohI'll add the rest of the projects too14:55
ralonsohok, so that's all for today, do you have something else?14:56
ralonsohthank you all and remember that today there isn't CI meeting14:56
ralonsoh#endmeeting14:56
opendevmeetMeeting ended Tue Mar  7 14:56:45 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:56
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.html14:56
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.txt14:56
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.log.html14:56
ralonsohbye14:56
lajoskatonao/14:56
fricklerI'm still not sure about the n-d-r reno situation for 2023.114:57
ralonsohwhy? what is missing?14:57
rubasovo/14:57
fricklerhttps://review.opendev.org/c/openstack/neutron-dynamic-routing/+/876326 vs. https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/87635814:57
fricklerthere currently are no renos for 2023.114:57
fricklerI'm not sure whether adding to master first or only to the stable brach is better14:58
ralonsohI'm checking the patches during this release14:58
frickler*branch14:58
ralonsohand seems that there are no renos during 2023.114:59
ralonsohwhen was fixed? in 2023.1?14:59
frickleryes, some patches were merge without reno that should have had one, like the one I added above14:59
frickleryes14:59
ralonsohso I think is legit to backport the reno14:59
ralonsohwe'll, you are not backporting it15:00
fricklerI can abandon the stable one and backport the other once it is merged15:01
ralonsohthe master one is approved15:01
fricklero.k., I'll backport once it is merged. and then we'll likely need an rc-2? or does that not matter for renos?15:02
ralonsohis does if I'm not wrong: the tools generate renos per release15:03
ralonsohif this backport is not in the RC-2, it won't be in the renos of 2023.115:04
fricklero.k., so I'll do a patch for that, too and check with release team15:04
opendevreviewMerged openstack/neutron stable/xena: Reintroduce agent bridge resync test  https://review.opendev.org/c/openstack/neutron/+/87646515:17
opendevreviewMerged openstack/neutron stable/wallaby: Reintroduce agent bridge resync test  https://review.opendev.org/c/openstack/neutron/+/87646615:17
opendevreviewMerged openstack/neutron-dynamic-routing master: Add a reno for the fixed address scope calculation  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/87635815:22
opendevreviewDr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/2023.1: Add a reno for the fixed address scope calculation  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/87667615:24
opendevreviewLajos Katona proposed openstack/neutron-tempest-plugin master: Move test_dhcp_port_status_active to tempest  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/86922715:56
lajoskatonaslaweq, ralonsoh: shall we include this one also to n-t-p release: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/869227 the tempest side was merged15:57
lajoskatonaslaweq, ralonsoh: this one is to remove some duplications between tempest and neutron-tempest-plugin15:57
ralonsohyes, the tempest patch has been merged time ago15:58
opendevreviewMerged openstack/neutron-tempest-plugin master: Fix the way how default SG for project if found in SG scenario test  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/87605216:58
opendevreviewMerged openstack/neutron master: ovs: fix regression when vlan mapping is not already registered  https://review.opendev.org/c/openstack/neutron/+/87657016:58
opendevreviewMerged openstack/neutron master: functional: set dns_domain config option after its registration  https://review.opendev.org/c/openstack/neutron/+/87665616:58
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules  https://review.opendev.org/c/openstack/neutron/+/87673217:01
opendevreviewRodolfo Alonso proposed openstack/neutron-tempest-plugin master: Remove method which created ingress metadata rule in SG  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/87669217:13
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules  https://review.opendev.org/c/openstack/neutron/+/87673218:25
prometheanfireit looks like the ovn port created for load balancing is set to status down, is there a reason for that? ( jamesdenton? )18:35
prometheanfireI'm really trying to debug this but seeing nothing wrong on the northd controller, etc18:39
opendevreviewMerged openstack/neutron master: ovn_idl_impl: fix a logic bug in get_sg_port_groups  https://review.opendev.org/c/openstack/neutron/+/87665719:09

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