opendevreview | Merged openstack/neutron master: Remove duplicate rows in MySQL query output https://review.opendev.org/c/openstack/neutron/+/876168 | 00:46 |
---|---|---|
opendevreview | Ihar Hrachyshka proposed openstack/neutron master: functional: set dns_domain config option after its registration https://review.opendev.org/c/openstack/neutron/+/876656 | 03:10 |
opendevreview | Ihar Hrachyshka proposed openstack/neutron master: ovn_idl_impl: fix a logic bug in get_sg_port_groups https://review.opendev.org/c/openstack/neutron/+/876657 | 03:10 |
opendevreview | Ihar Hrachyshka proposed openstack/neutron master: ovn: store neutron:revision_number for Port_Groups https://review.opendev.org/c/openstack/neutron/+/876658 | 03:10 |
opendevreview | Ihar Hrachyshka proposed openstack/neutron master: ovn: allow returning metadata packets for stateless security groups https://review.opendev.org/c/openstack/neutron/+/876659 | 03:10 |
tobias-urdin | any plans to do a new yoga release? a lot of changes waiting for release, even the CVE merged back in September last year | 08:09 |
tobias-urdin | seems like a xena release was done recently that included all that but not yoga | 08:10 |
opendevreview | Slawek 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/+/876692 | 08:30 |
slaweq | hi 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 patch | 08:34 |
ralonsoh | slaweq, I'll check it now | 08:37 |
opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: ovs: fix regression when vlan mapping is not already registered https://review.opendev.org/c/openstack/neutron/+/876570 | 08:37 |
ralonsoh | tobias-urdin, there is a topic for today's meeting | 08:37 |
ralonsoh | tobias-urdin, you can also attend to the weekly Neutron meeting to ask this | 08:38 |
slaweq | ralonsoh ok, approved then, thx a lot | 09:19 |
tobias-urdin | ralonsoh: ack, thanks :) | 09:20 |
opendevreview | Merged openstack/networking-bgpvpn stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/networking-bgpvpn/+/875831 | 10:14 |
opendevreview | Merged openstack/neutron-fwaas-dashboard stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/875838 | 10:15 |
opendevreview | Merged openstack/neutron-fwaas-dashboard stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/875839 | 10:19 |
opendevreview | Merged openstack/networking-odl stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/networking-odl/+/875879 | 10:21 |
opendevreview | Merged openstack/networking-odl stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/networking-odl/+/875880 | 10:21 |
opendevreview | Merged openstack/neutron-vpnaas stable/2023.1: Update .gitreview for stable/2023.1 https://review.opendev.org/c/openstack/neutron-vpnaas/+/875864 | 10:31 |
opendevreview | Merged openstack/neutron-vpnaas stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/neutron-vpnaas/+/875865 | 10:31 |
opendevreview | Merged openstack/networking-bgpvpn stable/2023.1: Update TOX_CONSTRAINTS_FILE for stable/2023.1 https://review.opendev.org/c/openstack/networking-bgpvpn/+/875832 | 10:35 |
sahid_ | it's me or gerrit is a bit unstable? | 10:43 |
lajoskatona | sahid_: what's wrong? | 10:50 |
opendevreview | Lajos Katona proposed openstack/neutron master: OVS FW: Delete sg rule which remote is the deleted sg https://review.opendev.org/c/openstack/neutron/+/876716 | 10:50 |
lajoskatona | sahid_: gerrit itself is ok for me | 10:50 |
sahid_ | lajoskatona: well it's not really gerrit, fetching ssh://sahid@review.opendev.org:29418/openstack/neutron.git does not respond | 10:51 |
lajoskatona | sahid_: for me it worked, just now | 11:00 |
slaweq | ralonsoh 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/+/876616 | 11:26 |
slaweq | thx in advance | 11:26 |
ralonsoh | slaweq, sure | 11:27 |
ralonsoh | slaweq, done, once merged, I'll update the release patch | 11:29 |
slaweq | ralonsoh++ thx | 11:43 |
opendevreview | Merged openstack/neutron master: Add 2023.1 release name in routed networks doc https://review.opendev.org/c/openstack/neutron/+/876407 | 13:11 |
zigo | It 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 |
opendevreview | Merged openstack/neutron stable/2023.1: Change the release tag to use the release identification https://review.opendev.org/c/openstack/neutron/+/875969 | 13:32 |
opendevreview | Merged openstack/neutron master: Add Lajos Katona to Client and Doc areas as lieutenant https://review.opendev.org/c/openstack/neutron/+/875918 | 13:33 |
opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules https://review.opendev.org/c/openstack/neutron/+/876732 | 13:36 |
ralonsoh | zigo, why? This is an agent like OVS agent, LB agent or SRIOV agent | 13:47 |
zigo | ralonsoh: The neutron.ml2.ovn.agent entry point is *NOT* an oslo.config entry point, look at the setup.cfg you'll see ! | 13:49 |
zigo | In fact, it doesn't exist at all in setup.cfg. | 13:50 |
ralonsoh | zigo, so this is a missing bit from the implementation | 13:50 |
ralonsoh | I'll push a patch for this | 13:51 |
zigo | ralonsoh: neutron.ovn.agent is, I believe the correct entry point... | 13:51 |
ralonsoh | no, that was a mistake in the setup.cfg | 13:51 |
zigo | ralonsoh: Look at neutron/conf/agent/ovn/ovn_neutron_agent/config.py ... | 13:51 |
ralonsoh | we are locating all agents on neutron.ml2 | 13:51 |
zigo | It really has list_ovn_neutron_agent_opts() as expected ! | 13:52 |
ralonsoh | I know, I implemented it | 13:52 |
zigo | :) | 13:52 |
ralonsoh | so what is wrong in setup.cfg | 13:53 |
zigo | ralonsoh: Nothing, what's wrong is etc/oslo-config-generator/ovn_agent.ini | 13:53 |
ralonsoh | (in any case, this is currently not used, apart from very specific HW offload envs) | 13:53 |
zigo | It lists a non-existing entry point in the namespace list. | 13:53 |
ralonsoh | ping bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki | 13:59 |
ralonsoh | we'll start the meeting in 1 min | 13:59 |
ralonsoh | #startmeeting networking | 14:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
opendevmeet | The meeting name has been set to 'networking' | 14:00 |
ralonsoh | hello all | 14:00 |
slaweq | o/ | 14:00 |
haleyb | o/ | 14:00 |
obondarev | o/ | 14:00 |
elvira | hi! | 14:00 |
rubasov | o/ | 14:00 |
bcafarel | o/ | 14:00 |
lajoskatona | o/ | 14:01 |
ralonsoh | let's start! | 14:01 |
ralonsoh | #topic announcements | 14:01 |
ralonsoh | as usual, during this important weeks | 14:01 |
ralonsoh | #link https://releases.openstack.org/antelope/schedule.html | 14:01 |
ralonsoh | this week is the final release for the non-client libraries | 14:01 |
tobias-urdin | o/ | 14:01 |
ralonsoh | sorry, no! | 14:02 |
ralonsoh | (what I'm reading?) | 14:02 |
ralonsoh | next week is the final week for the RC | 14:02 |
frickler | \o | 14:02 |
ralonsoh | so far, nothing went wrong during the last week | 14:02 |
ralonsoh | when we merged the releases for all the Neutron related projects | 14:03 |
lajoskatona | Cool | 14:03 |
frickler | reno generation is still a bit broken, but a fix is in the works | 14:03 |
ralonsoh | but please, keep an eye on the CI and launchpad | 14:03 |
ralonsoh | frickler, which one? | 14:03 |
frickler | 2023.1 sorts before zed and everything else, leading to duplicated entries | 14:03 |
ralonsoh | ah yes yes | 14:04 |
ralonsoh | but seems to be addressed now | 14:04 |
frickler | https://review.opendev.org/c/openstack/reno/+/876581 is the proposed fix | 14:04 |
ralonsoh | yeah and almost merged, so cool | 14:04 |
ralonsoh | ah, I almost forgot, last week we had the "election" polling (there wasn't for Neutron as I was the only candidate) | 14:05 |
ralonsoh | so you'll have me again for the next 6 months | 14:05 |
ralonsoh | sorry for you! | 14:05 |
bcafarel | congratulations here's to 6 more months :) | 14:05 |
tobias-urdin | lucky us! congrats :) | 14:05 |
lajoskatona | +2 | 14:05 |
obondarev | thank you, congrats! | 14:05 |
ralonsoh | and please, remember the PTG is very very close | 14:06 |
ralonsoh | and we have a not-so-active etherpad | 14:06 |
ralonsoh | #link https://etherpad.opendev.org/p/neutron-bobcat-ptg | 14:06 |
ralonsoh | next week I'll add all related to sqlalchemy, neutronclient and CI | 14:06 |
ralonsoh | but if you have new features/RFE/bugs, please add them in this etherpad | 14:07 |
ralonsoh | (I'll send another reminder today) | 14:07 |
ralonsoh | something else here?? | 14:07 |
bcafarel | just a stable service announcement, now that we have antelope branched | 14:07 |
bcafarel | remember to also cherry-pick to this branch when doing a series of backports :) | 14:08 |
ralonsoh | right, 2023.1 | 14:08 |
ralonsoh | (^^^ please don't make my mistake again: antelope is officially called 2023.1 in the code) | 14:08 |
lajoskatona | yeah be careful as this breaks alphabetical order :-) | 14:08 |
ralonsoh | btw, about this, I tested the patches renaming the DB branches | 14:09 |
ralonsoh | luckily the db migration tool only checks the migration IDs, not the directories | 14:09 |
ralonsoh | ok, let's move to the next topic | 14:10 |
ralonsoh | #topic bugs | 14:10 |
lajoskatona | It was my week | 14:10 |
ralonsoh | exactly | 14:10 |
ralonsoh | there is the report | 14:10 |
ralonsoh | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032577.html | 14:10 |
lajoskatona | thanks | 14:10 |
ralonsoh | many bugs but most of them addressed or assigned under investigation | 14:11 |
ralonsoh | (thanks for this active community!) | 14:11 |
lajoskatona | There was only one which has no owner: https://bugs.launchpad.net/neutron/+bug/2009043 | 14:11 |
ralonsoh | there are still 3 bugs to be discussed | 14:11 |
ralonsoh | yeah, this is the first one | 14:11 |
lajoskatona | actually the reporter just come back with some result what is the suspicion from their side | 14:11 |
ralonsoh | maybe slaweq could check that | 14:11 |
ralonsoh | if you have time | 14:11 |
lajoskatona | and I would like to as slaweq (or anybody more HA router knowledge) to check | 14:12 |
slaweq | sure, I will try to check it this week | 14:12 |
ralonsoh | thanks a lot | 14:12 |
lajoskatona | yes the reporter wrote that for them this patch is suspicios: https://review.opendev.org/c/openstack/neutron/+/776423 | 14:12 |
lajoskatona | slaweq: thanks | 14:12 |
ralonsoh | the next one is | 14:13 |
lajoskatona | thats all from the bugs of last week, all other bugs are active | 14:13 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2008858 | 14:13 |
ralonsoh | I would like you to check this one because the cause (and the fix proposed) are not solving the reported issue | 14:13 |
ralonsoh | what is failing there is the Neutron DB access, not the OVN connectivity | 14:14 |
lajoskatona | ohh, I set it to inactive as there was no answer, but it is active again, thanks | 14:14 |
lajoskatona | ok, thanks ralonsoh | 14:14 |
ralonsoh | I'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 |
ralonsoh | the last one in this list is | 14:15 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2008808 | 14:15 |
ralonsoh | but seems inactive since the report | 14:15 |
ralonsoh | to be honest, I don't know how to replicate this | 14:16 |
ralonsoh | did you have this problem before? | 14:16 |
ralonsoh | ok, we'll wait for more info | 14:17 |
ralonsoh | that's all from this list | 14:17 |
ralonsoh | This week slaweq is the deputy, next week will be haleyb | 14:17 |
slaweq | sure | 14:17 |
haleyb | that works | 14:18 |
ralonsoh | cool, thanks both | 14:18 |
ralonsoh | let's move to the next topic | 14:18 |
ralonsoh | #community_goals | 14:18 |
ralonsoh | 1) Consistent and Secure Default RBAC | 14:18 |
ralonsoh | we have an active n-t-p patch | 14:19 |
ralonsoh | #link https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/874709 | 14:19 |
ralonsoh | with all the dependencies merged | 14:19 |
ralonsoh | but seems that this job "neutron-tempest-plugin-openvswitch-enforce-scope-new-defaults" is failing | 14:19 |
slaweq | I need to check why it's still failing | 14:19 |
ralonsoh | no rush and thanks | 14:19 |
slaweq | maybe we have missing something in neutron-lib, idk for now | 14:19 |
slaweq | I will ping You once it will be ready to review | 14:20 |
ralonsoh | sure, remember that we'll need that too in Zed | 14:20 |
ralonsoh | actually what is failing is zed job | 14:21 |
slaweq | yeah, in master it works fine, there is something missing in Zed just | 14:21 |
ralonsoh | not master one | 14:21 |
slaweq | in master I will work in this new cycle on the service role for communication between services | 14:21 |
slaweq | and on making new policies to be enabled by default | 14:21 |
lajoskatona | that is already agreed with nova for example? | 14:22 |
ralonsoh | qq, the service role will be available only in Bobcat, right? | 14:22 |
slaweq | lajoskatona what? | 14:22 |
slaweq | ralonsoh yes, I don't plan to backport it | 14:22 |
lajoskatona | I mean how the service role will be used for service-to-service comm | 14:22 |
slaweq | it's agreed generally | 14:23 |
slaweq | we need to identify what calls may be only for service2service and will be available by this new role | 14:23 |
lajoskatona | ok, thanks | 14:23 |
amotoki | admin role is too much and IIRC we agreed to use the service role for such communicatins. | 14:24 |
ralonsoh | yeah, this is not trivial to make a list of all S2S calls | 14:24 |
lajoskatona | do we need to sit down with nova team to clarify the deatils or it will be enough to do the reviews? | 14:24 |
slaweq | I think it will be enough to do reviews | 14:24 |
ralonsoh | because Nova is our client, they mostly should provide this info | 14:25 |
ralonsoh | but we can have a cross session during the next ptg | 14:25 |
slaweq | or if needed, I will add topic to the PTG to talk about that | 14:25 |
ralonsoh | to sync that | 14:25 |
slaweq | but need to check it first | 14:25 |
ralonsoh | correct | 14:25 |
ralonsoh | slaweq, will you ping Nova folks about this? | 14:25 |
ralonsoh | to know if they will be ready for this during the PTG | 14:25 |
slaweq | ralonsoh sure, if needed I will :) | 14:25 |
ralonsoh | perfect | 14:25 |
ralonsoh | thanks again for taking care of this | 14:26 |
ralonsoh | let's move then | 14:26 |
ralonsoh | 2) Neutron client deprecation | 14:26 |
ralonsoh | the agenda: https://etherpad.opendev.org/p/python-neutronclient_deprecation | 14:26 |
ralonsoh | lajoskatona, something new? | 14:27 |
lajoskatona | I think no news | 14:27 |
lajoskatona | the usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation | 14:27 |
lajoskatona | I have to come back and push my patches as the last ones are still WIPs | 14:27 |
ralonsoh | during 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 this | 14:28 |
lajoskatona | I already added :-) | 14:28 |
ralonsoh | right, i see it | 14:28 |
lajoskatona | I will add some details, I just added a line for it | 14:28 |
ralonsoh | perfect | 14:28 |
ralonsoh | we don't have a hard schedule, but let's see if during the next cycle we can deprecate nclient | 14:29 |
ralonsoh | the whole project | 14:29 |
lajoskatona | ok | 14:29 |
ralonsoh | and that's all in this topic | 14:30 |
ralonsoh | let's move to the last one | 14:30 |
frickler | didn't we want to keep it as osc-plugin? | 14:30 |
ralonsoh | the plan is to move everything to sdk | 14:30 |
ralonsoh | and use the OSC, instead of the nclient | 14:30 |
frickler | sdk is only one half | 14:30 |
lajoskatona | we want, but we can remove the python binding code | 14:30 |
frickler | but we can discuss at the ptg. just invite gtema to that session | 14:31 |
ralonsoh | perfect | 14:31 |
amotoki | I think we need moree discussion on osc-plugin from neutronclient | 14:31 |
amotoki | frickler: right | 14:31 |
lajoskatona | frickler: good idea, I ask gtema f he can join | 14:31 |
amotoki | our current target is python bindings | 14:31 |
frickler | right, that is undisputed afaict | 14:32 |
lajoskatona | in the patches which are up for this topic I kept the CLI code in neutronclient, but change to use sdk and not neutronclient binding code | 14:33 |
ralonsoh | I think we can have this conversation in the PTG, but is there any limitation to move all the bindings to SDK? | 14:33 |
lajoskatona | +1 | 14:33 |
frickler | even if that is finished, you still cannot deprecate the OSC-plugin part | 14:34 |
ralonsoh | no of course | 14:34 |
frickler | o.k., maybe I misunderstood "deprecate nclient" then | 14:34 |
ralonsoh | but we'll stop doing anything in nclient, that at least is a good goal | 14:34 |
amotoki | frickler: no worries. neutronclient has two parts: CLI and python bindings, and it is always confusing :p | 14:35 |
frickler | well 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 |
ralonsoh | actually what was supposedly deprecated (the CLI) can't be yet removed | 14:36 |
ralonsoh | well that's the point lajoskatona job here | 14:36 |
amotoki | ralonsoh: "neutron" CLI was deprecated but OSC plugin is still active I think | 14:36 |
ralonsoh | amotoki, right | 14:37 |
ralonsoh | if n-d-r is still using nclient, it should move to OSC | 14:37 |
ralonsoh | we should avoid any new develpment in nclient | 14:37 |
frickler | all the "openstack bgp ..." commands are in nclient as osc-plugin | 14:38 |
amotoki | n-d-r support is now implemented as OSC plugin (not in OSC). | 14:38 |
frickler | and there are no current plans to change that, or are there? | 14:38 |
lajoskatona | I think we said that no plan for that | 14:38 |
lajoskatona | and let's keep the repos as OSC plugin | 14:39 |
amotoki | perhaps what we first need to do is that OSC plugin for n-d-r consume openstacksdk instead of neutronclient python bindings | 14:39 |
lajoskatona | I mean neutronclient repo | 14:39 |
lajoskatona | amotoki: exactly, that's what I started | 14:39 |
frickler | amotoki: that is what lajoskatona is working on I think, first moving the sdk code to openstacksdk repo | 14:39 |
amotoki | yes | 14:39 |
amotoki | at least we still need to add CLI commands to neutronclient OSC plugin | 14:40 |
amotoki | if we would like to add new commands related to n-d-r, right? | 14:41 |
frickler | that's my understanding, yes | 14:41 |
ralonsoh | and why not spend time first on moving all the bindings to SDK and use the OSC in n-d-r? | 14:41 |
ralonsoh | we'll never finish the migration doing that | 14:41 |
lajoskatona | yes but we have only one SDK for all these when it is finished | 14:42 |
amotoki | +1 | 14:42 |
frickler | the commands are implemented in neutronclient, not in n-d-r | 14:42 |
frickler | I can double check if n-d-r uses bindings from neutronclient somewhere | 14:43 |
amotoki | anyway the ptg session would be helpful to share the current situation and futures :-) | 14:43 |
amotoki | the discussion here is a good example | 14:43 |
frickler | from a quick look n-d-r only uses rpc client | 14:44 |
frickler | yes, let's go on and defer to PTG | 14:44 |
ralonsoh | ok, let's move on | 14:45 |
ralonsoh | #topic on_demand_agenda | 14:45 |
ralonsoh | I've been asked to release new versions for stable releases | 14:46 |
ralonsoh | X, Y and Z | 14:46 |
haleyb | U as well? | 14:46 |
ralonsoh | and that makes sense as we haven't done it for a long time | 14:46 |
ralonsoh | not U | 14:46 |
ralonsoh | let me check the state of U | 14:46 |
slaweq | Isn't U in EM phase already? | 14:47 |
haleyb | there have been some merges recently, one of which i'm interested in releasing | 14:47 |
haleyb | yes i do see the -em tag there | 14:47 |
ralonsoh | yeah, is in EM mode | 14:47 |
frickler | could 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 done | 14:47 |
ralonsoh | I'll add it to the agenda | 14:48 |
ralonsoh | I'll check if we can push a new hash for EM branches | 14:48 |
ralonsoh | and how | 14:48 |
frickler | em gets no new tags | 14:48 |
ralonsoh | so that could be a problem then | 14:49 |
frickler | it is consumed only from stable/ussuri or whatever head | 14:49 |
ralonsoh | yes | 14:49 |
haleyb | why? i'm probably just forgetting | 14:49 |
ralonsoh | what I mean is if we can update the EM hash? | 14:49 |
frickler | what is "the EM hash"? move the ussuri-em tag: nope | 14:49 |
ralonsoh | yeah so the only next tag that a EM branch can have is EOL | 14:50 |
ralonsoh | right? | 14:50 |
frickler | yes | 14:50 |
lajoskatona | thats my undertsanding also, the tag is set to some hash and it cant be moved | 14:50 |
frickler | and that also drops the branch | 14:50 |
ralonsoh | haleyb, so no, we can't release any new version for W and older | 14:50 |
opendevreview | Merged openstack/neutron master: Add full support for OVN NB "Gateway_Chassis" table https://review.opendev.org/c/openstack/neutron/+/874767 | 14:51 |
ralonsoh | about Z, Y and X, I think you are ok with this, right? | 14:51 |
haleyb | ralonsoh: ack, i'll ask our downstream team about it | 14:51 |
haleyb | i'm fine with releasing everything else, yes | 14:52 |
lajoskatona | agree for new release | 14:52 |
ralonsoh | ok, I'll push the patches this week and I'll add all of you as reviewers | 14:52 |
lajoskatona | thanks | 14:53 |
frickler | semi-related: is someone working on creating n-t-p zuul.d/2023.1_jobs.yaml ? | 14:53 |
ralonsoh | not yet, I think (let me check) | 14:53 |
frickler | I didn't see a review at least | 14:53 |
ralonsoh | no, I'll do it too this week | 14:54 |
lajoskatona | I can check it | 14:54 |
ralonsoh | btw, I almost forget | 14:54 |
ralonsoh | related to the stable releases | 14:55 |
opendevreview | Merged openstack/neutron stable/yoga: Reintroduce agent bridge resync test https://review.opendev.org/c/openstack/neutron/+/876464 | 14:55 |
ralonsoh | I'll add the rest of the projects too | 14:55 |
ralonsoh | ok, so that's all for today, do you have something else? | 14:56 |
ralonsoh | thank you all and remember that today there isn't CI meeting | 14:56 |
ralonsoh | #endmeeting | 14:56 |
opendevmeet | Meeting ended Tue Mar 7 14:56:45 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:56 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.html | 14:56 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.txt | 14:56 |
opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2023/networking.2023-03-07-14.00.log.html | 14:56 |
ralonsoh | bye | 14:56 |
lajoskatona | o/ | 14:56 |
frickler | I'm still not sure about the n-d-r reno situation for 2023.1 | 14:57 |
ralonsoh | why? what is missing? | 14:57 |
rubasov | o/ | 14:57 |
frickler | https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/876326 vs. https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/876358 | 14:57 |
frickler | there currently are no renos for 2023.1 | 14:57 |
frickler | I'm not sure whether adding to master first or only to the stable brach is better | 14:58 |
ralonsoh | I'm checking the patches during this release | 14:58 |
frickler | *branch | 14:58 |
ralonsoh | and seems that there are no renos during 2023.1 | 14:59 |
ralonsoh | when was fixed? in 2023.1? | 14:59 |
frickler | yes, some patches were merge without reno that should have had one, like the one I added above | 14:59 |
frickler | yes | 14:59 |
ralonsoh | so I think is legit to backport the reno | 14:59 |
ralonsoh | we'll, you are not backporting it | 15:00 |
frickler | I can abandon the stable one and backport the other once it is merged | 15:01 |
ralonsoh | the master one is approved | 15:01 |
frickler | o.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 |
ralonsoh | is does if I'm not wrong: the tools generate renos per release | 15:03 |
ralonsoh | if this backport is not in the RC-2, it won't be in the renos of 2023.1 | 15:04 |
frickler | o.k., so I'll do a patch for that, too and check with release team | 15:04 |
opendevreview | Merged openstack/neutron stable/xena: Reintroduce agent bridge resync test https://review.opendev.org/c/openstack/neutron/+/876465 | 15:17 |
opendevreview | Merged openstack/neutron stable/wallaby: Reintroduce agent bridge resync test https://review.opendev.org/c/openstack/neutron/+/876466 | 15:17 |
opendevreview | Merged openstack/neutron-dynamic-routing master: Add a reno for the fixed address scope calculation https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/876358 | 15:22 |
opendevreview | Dr. 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/+/876676 | 15:24 |
opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Move test_dhcp_port_status_active to tempest https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/869227 | 15:56 |
lajoskatona | slaweq, 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 merged | 15:57 |
lajoskatona | slaweq, ralonsoh: this one is to remove some duplications between tempest and neutron-tempest-plugin | 15:57 |
ralonsoh | yes, the tempest patch has been merged time ago | 15:58 |
opendevreview | Merged 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/+/876052 | 16:58 |
opendevreview | Merged openstack/neutron master: ovs: fix regression when vlan mapping is not already registered https://review.opendev.org/c/openstack/neutron/+/876570 | 16:58 |
opendevreview | Merged openstack/neutron master: functional: set dns_domain config option after its registration https://review.opendev.org/c/openstack/neutron/+/876656 | 16:58 |
opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules https://review.opendev.org/c/openstack/neutron/+/876732 | 17:01 |
opendevreview | Rodolfo 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/+/876692 | 17:13 |
opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: Use neutron-lib policy rules https://review.opendev.org/c/openstack/neutron/+/876732 | 18:25 |
prometheanfire | it looks like the ovn port created for load balancing is set to status down, is there a reason for that? ( jamesdenton? ) | 18:35 |
prometheanfire | I'm really trying to debug this but seeing nothing wrong on the northd controller, etc | 18:39 |
opendevreview | Merged openstack/neutron master: ovn_idl_impl: fix a logic bug in get_sg_port_groups https://review.opendev.org/c/openstack/neutron/+/876657 | 19:09 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!