Tuesday, 2023-04-25

« Monday, 2023-04-24 Index Wednesday, 2023-04-26 »
haleybdansmith: which one, just the neutron one? none of the others seem to have merged yet. i'm going offline but if you propose a revert you can always depend on it to see if it helps? if not ralonsoh will be around in the early morning01:18
ykareldansmith, sure since neutron gates are unblocked with https://review.opendev.org/c/openstack/requirements/+/88132904:20
ykarelneutron patch could be reverted and others open patch could be put on hold until next steps are known04:20
ykarelreading discussion in revert patch seems possible plan would be to keep py38 or drop dependencies of it on projects before real drop04:21
ykarelwill push the revert04:21
opendevreviewyatin proposed openstack/neutron master: Revert "Move to python3.9 as minimal python version"  https://review.opendev.org/c/openstack/neutron/+/88143004:26
ykarellajoskatona, i put -W on other projects just to avoid the merges04:55
ykarelto avoid any future revert dances04:55
lajoskatonaykarel: ack, thanks05:27
opendevreviewyatin proposed openstack/neutron-tempest-plugin master: [DNM] non nested virt jammy nodes with workaround v2  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/88139105:29
opendevreviewSahid Orentino Ferdjaoui proposed openstack/neutron master: rpc/handlers/dhcp: fix get_network_info when no local subnets  https://review.opendev.org/c/openstack/neutron/+/88013107:16
opendevreviewMerged openstack/neutron master: Revert "Move to python3.9 as minimal python version"  https://review.opendev.org/c/openstack/neutron/+/88143007:18
opendevreviewSahid Orentino Ferdjaoui proposed openstack/neutron master: rpc/handlers/dhcp: fix get_network_info when no local subnets  https://review.opendev.org/c/openstack/neutron/+/88013107:19
ralonsohykarel, I'm going to send a mail saying that we have reverted the python3.9 patch in Neutron07:53
ralonsohbut we'll continue working on moving to Jammy07:53
ykarelralonsoh, +107:55
lajoskatona+107:55
lajoskatonaralonsoh: Warning: there's a chance I can't join today meetings07:56
ralonsohnp, do your best07:56
ralonsohfolks, please check https://review.opendev.org/c/openstack/neutron/+/88058608:05
bauzasthanks folks for having quickly revert the python_requires for Neutron08:14
ralonsohyw08:14
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] check 880586 [2]  https://review.opendev.org/c/openstack/neutron/+/88139508:25
opendevreviewRodolfo Alonso proposed openstack/neutron master: Use a writer context for the online alembic migrations  https://review.opendev.org/c/openstack/neutron/+/88086708:25
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Admin procedure for duplicated or deleted OVN agents  https://review.opendev.org/c/openstack/neutron/+/88120408:39
opendevreviewRodolfo Alonso proposed openstack/neutron master: Remove "neutron-ovn-tempest-ovs-release-ubuntu-old" job  https://review.opendev.org/c/openstack/neutron/+/88134208:39
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Remove backwards compatibility with OVN < v20.09  https://review.opendev.org/c/openstack/neutron/+/87062108:40
opendevreviewRodolfo Alonso proposed openstack/neutron master: Mark "ipv6_pd_enabled" as deprecated and experimental.  https://review.opendev.org/c/openstack/neutron/+/87903008:40
opendevreviewMerged openstack/neutron master: Fix parent of neutron-ovn-tempest-with-uwsgi-loki  https://review.opendev.org/c/openstack/neutron/+/88058608:58
opendevreviewRodolfo Alonso proposed openstack/neutron master: Deprecated support for Windows OS  https://review.opendev.org/c/openstack/neutron/+/88098009:01
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] check 880586 [2]  https://review.opendev.org/c/openstack/neutron/+/88139509:16
ralonsohlajoskatona, how did you change the links in LP? https://bugs.launchpad.net/neutron/+bug/201641409:37
lajoskatonaralonsoh: phuhh, that was a good search :-) Let me try to remember it09:47
lajoskatonaralonsoh: ok, I think I find it, go to the main Neutron bugs page (https://bugs.launchpad.net/neutron )09:48
lajoskatonarlonsoh: on the right side in one of the boxed areas there is a link "Configure Bugs", and that brings to the area where you can set such texts (https://bugs.launchpad.net/neutron/+configure-bugtracker )09:49
ralonsohahhhh good to know that09:50
ralonsohthanks!09:50
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] Test loki  https://review.opendev.org/c/openstack/neutron/+/88145910:04
opendevreviewMerged openstack/neutron stable/zed: Honor debug mode in keepalived-state-change script logs  https://review.opendev.org/c/openstack/neutron/+/88135510:25
opendevreviewyatin proposed openstack/neutron master: Add py39 jobs to tox override template  https://review.opendev.org/c/openstack/neutron/+/88146410:25
opendevreviewMerged openstack/neutron stable/yoga: Honor debug mode in keepalived-state-change script logs  https://review.opendev.org/c/openstack/neutron/+/88132210:27
opendevreviewMerged openstack/neutron stable/xena: Honor debug mode in keepalived-state-change script logs  https://review.opendev.org/c/openstack/neutron/+/88135610:27
ykarellajoskatona, ralonsoh focal jobs broke again :( with pysaml2==7.4.1 https://github.com/IdentityPython/pysaml2/commit/7d34181fc0b7929e0100973e140d61f8fbf31d9710:45
ralonsohoh my...10:45
ralonsohwhat a permanent drama!10:45
ralonsohso no support for 3.8 anymore10:45
fricklermagnificient move to do that in a patch version10:55
fricklerseems we really need py38-specific u-c10:55
ykarelpushed revert https://review.opendev.org/c/openstack/requirements/+/88146610:56
ralonsoh+110:57
frickleralso https://review.opendev.org/c/openstack/requirements/+/88143310:59
ralonsohdone11:02
opendevreviewBence Romsics proposed openstack/neutron master: port-hints: api extension  https://review.opendev.org/c/openstack/neutron/+/87008111:27
opendevreviewBence Romsics proposed openstack/neutron-lib master: port-hint-ovs-tx-steering: Add missing api-ref response sample  https://review.opendev.org/c/openstack/neutron-lib/+/88146811:27
opendevreviewBence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: agent side  https://review.opendev.org/c/openstack/neutron/+/87290511:27
opendevreviewBence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: shim extension  https://review.opendev.org/c/openstack/neutron/+/87311311:28
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] Test loki  https://review.opendev.org/c/openstack/neutron/+/88145912:56
dansmithykarel: awesome thanks!12:59
ralonsohPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki 14:00
mlavalleo/14:00
mtomaskao/14:00
ralonsoh#startmeeting networking14:01
opendevmeetMeeting started Tue Apr 25 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
ralonsohhello14:01
sahido/14:01
ykarelo/14:01
obondarevhi14:01
ralonsohlajoskatona told me that, most probably, won't attend14:02
ralonsohok, let's start14:02
ralonsoh#topic announcements14:02
ralonsoh#link https://releases.openstack.org/bobcat/schedule.html14:02
rubasovo/14:03
lajoskatonao/14:03
ralonsohnext week is the Bobcat Cycle-Trailing Release Deadline14:03
ralonsohhttps://releases.openstack.org/bobcat/schedule.html#b-cycle-trail14:03
ralonsohand the PTG is closer14:03
ralonsoh#link https://etherpad.opendev.org/p/neutron-vancouver-202314:03
ralonsohslaweq presented two forum sessions (still under review)14:03
ralonsoh1) OpenStack Neutron onboarding14:04
slaweqo/14:04
ralonsoh2) Neutron meet and greet: Operators feedback session14:04
bcafarellate o/14:04
ralonsohthanks slaweq for the document and presenting them14:04
lajoskatonaThanks for proposing14:04
ralonsohand as usual, please check https://openinfra.dev/live/#all-episodes14:04
ralonsohany other announcement?14:05
ralonsohok, let's move on14:05
ralonsoh#topic bugs14:05
ralonsohlast week report is from lucasgomes14:05
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033448.html14:06
ralonsohthere are some bugs not assigned yet14:06
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201641314:06
ralonsoha low hanging fruit one14:06
ralonsohok, next one14:07
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201650414:07
ralonsohSupport specify fixed_ip_address for DHCP or Metadata port14:07
ralonsohfor ovn, when you create a network, the metadata port is created at the same time14:08
ralonsohand then, when the first subnet is created, the IP is assigned14:08
ralonsohthe point is that you can then change the assigned IP14:08
lajoskatonabut this sounds more an RFE, am I wrong?14:08
ralonsohyes14:08
ralonsohis an RFE14:09
lajoskatonaahh, ok14:09
ralonsohI'll comment in the bug 14:09
ralonsohif Liu makes a good proposal, we can discuss it in the drivers meeting14:10
ralonsohfeel free to comment on the bug14:10
ralonsohnext one14:10
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201696014:10
ralonsoh[RFE] neutron fwaas support l2 firewall for ovn driver14:10
ralonsohsame as before, is a RFE14:10
ralonsohif I'm not wrong, what is expecting is to have white lists, not present in the in-tree driver14:11
ralonsohsounds good but to be approved needs an assignee and to be presented in the drivers meeting14:11
ralonsohI'll comment in the lp bug14:11
ralonsohnext one14:11
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201702314:11
ralonsohlajoskatona, is ^^ still valid?14:12
lajoskatonayes, I discussed it with kopecmartin and on #nova channel sean14:12
lajoskatonaI added the conclusion from those discussions so far as comment #214:12
ralonsohbut we need first to bump the min version of nova api, right?14:12
lajoskatonabut as I see gmann also commented14:12
lajoskatonaNo, that is not necessary14:13
ralonsohah ok, I see14:13
lajoskatonawhat is lightweight and good for us is that we stop executing those tests for Neutron, and keep the test coverage only in Nova14:13
lajoskatonathe same is true for glance for example as there's a similar legacy API in nova for images and tempest tests also14:14
ralonsohso do we need to remove this test from our jobs?14:14
lajoskatonabut that is a separate story and not covered in this bug, just as interesting story14:14
ralonsohthis/these14:14
lajoskatonayes as I understand, but have to double check with QA, as they wanted to have it as topic on their meeting14:15
lajoskatonahave to check with them again14:15
ralonsohperfect, can I assign the neutron bug to you? just to track it14:15
lajoskatonasure14:16
ralonsohthanks a lot14:16
ralonsohok, last one14:16
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/201713114:16
ralonsohykarel, fixed the issue with loki jobs14:16
ralonsohnow both (ovs and ovn) are working again14:16
ralonsohnow the problem is in the OVN one, when creating the router14:16
ykarelThanks ralonsoh 14:16
ralonsohI'm testing several options: https://review.opendev.org/q/topic:test_loki14:17
ralonsohI'll assign this bug to myself14:17
ralonsohin any case, this is not critical14:17
ralonsohand now the CI "party" we had, a short report14:18
ralonsohafter these 2 reverts14:18
ralonsohRevert "Move to python3.9 as minimal python version": https://review.opendev.org/c/openstack/neutron/+/88143014:18
ralonsohRevert "update constraint for tooz to new release 4.0.0": https://review.opendev.org/c/openstack/requirements/+/88132914:18
ralonsohwe were able to execute py38 jobs again14:18
ralonsohthis is because we are still running on Focal, not in Jammy14:18
ralonsohykarel, is testing a Nova patch https://review.opendev.org/c/openstack/nova/+/86841914:19
ralonsohthat could fix the nested virt nodes issue14:19
ralonsohbecause of this, during the last release we reverted the migration to Jammy nodes14:19
ralonsohand, of course, we have new problems in the CI14:19
ralonsohthat are being addressed by14:20
ralonsohRevert pysaml2 to 7.3.1: https://review.opendev.org/c/openstack/requirements/+/88146614:20
ralonsohadn14:20
ralonsohRevert "Drop check-uc jobs for py38": https://review.opendev.org/c/openstack/requirements/+/88143314:20
ykarelyes will be discussing that nova patch in nova meeting today14:20
ralonsohright, we need to keep investigating this issue to be able to migrate to Jammy asap14:21
lajoskatonathanks for the summary and for pushing this topic14:21
mlavalleso hold re-checks until further notice?14:21
ralonsohyes, exactly14:21
mlavalleack14:21
ralonsohcheck upper patches in requirements14:21
mlavallethanks for the update14:21
ralonsohand that's all14:22
ralonsohah14:22
ralonsohThis week jlibosva is the deputy, next week will be obondarev14:22
obondarev++14:22
ralonsohI'll ping Jakub after this meeting14:22
ralonsohlet's jump to the next topic14:22
ralonsoh#topic community_goals14:23
ralonsohthere are no new specs nor ryu patches14:23
ralonsohso no need to stop there14:23
ralonsoh1) Consistent and Secure Default RBAC 14:23
ralonsohthere is an active list of patches14:23
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/879827 14:23
ralonsoh^^ this one is the last one14:23
ralonsohto enable sRBAC in master14:24
slaweqand the most important one14:24
ralonsohby default14:24
ralonsohexactly hehehe14:24
slaweqit's very big but changes are mostly in tests14:24
ralonsohslaweq, if I'm not wrong, this is the summary now, right?14:24
slaweqas I had to change many tests so it is passing proper context while doing requests to neutron now14:25
slaweqlogically tests were not changed IIRC14:25
slaweqthat's all from me about it14:25
ralonsohjust a few tests...14:25
slaweqahh, and once this will be merged we will can say that we completed phase1 of S-RBAC goal14:26
slaweqnext one is to introduce service-to-service role and identify some APIs for such role14:26
slaweqbut that's next step14:26
ralonsohthat second one is more obscure, we need to identify these calls14:26
lajoskatonaI forgot from last time, is that task for this cycle (bobcat)?14:26
ralonsohthe first one14:26
lajoskatonaack14:27
lajoskatonaso for now the goal is to identify only those calls14:27
ralonsohyeah14:27
slaweqlajoskatona actually initial goal was to finish phase1 in Anthelope cycle14:27
slaweqbut we didn't made it14:27
slaweqso we are catching up14:27
lajoskatonaok14:27
lajoskatonathanks for refreshing the history :-)14:27
ralonsohslaweq, thanks for working on this14:28
ralonsohok, next one14:28
ralonsoh2) Neutron client deprecation 14:29
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/199977414:29
lajoskatonaand the usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation14:29
lajoskatonaI pushed a patch for fwaas: https://review.opendev.org/c/openstack/python-neutronclient/+/88062914:29
lajoskatonabut I have to test a few things on it, so it is WIP14:29
ralonsohI'll add it to the list in the agenda14:30
lajoskatonathanks, the ocata patch is still open, but ready for review from Tom Weninger: https://review.opendev.org/c/openstack/octavia/+/86632714:30
lajoskatonaoctavia, not ocata, sorry14:30
ralonsohah yes14:31
slaweqqq about neutronclient14:31
slaweqI see that we finally merged https://review.opendev.org/c/openstack/python-neutronclient/+/87171114:31
slaweqshould we maybe propose new release of neutronclient with that removed? or it's not needed?14:31
ralonsohright, we should push a new release with a new mayor version, I think14:32
lajoskatona+114:32
ralonsohI'll push this patch today14:32
lajoskatonagood idea14:32
slaweq++14:32
ralonsohperfect, thanks lajoskatona for working on this14:32
ralonsohok, let's move to the last topic14:33
ralonsoh#topic on_deman14:33
ralonsohltomasbo, froyo would be interested14:33
froyoo/ sure14:33
ralonsoh#link https://bugzilla.redhat.com/show_bug.cgi?id=218675814:33
ralonsohin a nutshell: a non-admin port in a private network14:33
ralonsohthe admin creates a FIP and associates the FIP (admin project) to the non-admin port14:34
ralonsoh--> the user cannot delete the port because cannot disassociate the FIP14:34
ralonsoh(btw, I'll create a LP bug for this)14:34
ralonsohquestion14:34
ralonsohshould we allow this disassociation in any case?14:34
ralonsohin order to  allow the non-admin user to delete his/her port in any case14:35
ralonsoh(my opinion: we should allow the disassociation during the port deletion)14:36
lajoskatonaif it is only to allow to delete the one port for the FIP, why not?14:36
ralonsohbecause that was an admin action, the association14:37
ralonsohbut, IMO, this port belongs to the user14:37
lajoskatonaack14:37
froyoyeah, the main options are: 14:38
froyo1) it was an admin action, it an admin issue...14:38
froyo2) it is a port belong to user, so user can delete it (elevating context to disassociate FIP)14:38
ralonsohok, I think froyo you can propose 2) in a patch and wait for feedback. IMO, the association is not covered by the policy rules14:39
ralonsohso it should be undone during the deletion14:39
ralonsohslaweq, any feedback?14:39
slaweqisn't accociation done as FIP update?14:40
slaweqfrom policy PoV14:40
ralonsohhmmm let me check14:40
ralonsohyes, the association is done during the FIP update14:41
slaweqI don't think any special API endpoint for that in https://docs.openstack.org/api-ref/network/v2/index.html14:41
ralonsohno, there isn't14:41
slaweqok, so disassociation of FIP from port is actually removing port_id from fip's attributes, right?14:42
ralonsohyes14:42
froyoyes14:42
slaweqso who is owner of FIP? is it admin in Your case?14:42
ralonsohyes14:42
froyoyes14:42
slaweqso by elevating context we will allow regular user to update fip which belongs to other project14:42
slaweqI know it's kind of "special" case but I'm not sure we should do that14:43
fricklerimo 1) is a better option then, just make a proper 403 error instead of 50014:43
froyojust on delete_port (to remove port_id and put FIP in DOWN state)14:43
slaweqfroyo but still, admin user probably did it for some reason14:44
froyoslaweq, sure!14:44
ralonsohok, let's change then the scope and the output of the server14:46
ralonsohbut the port deletion can't be done14:46
fricklerfor the use case, is it mandatory the FIP belongs to admin? they could also create FIP in the tenant project?14:46
slaweqmaybe better option would then be to introduce some api rule like "PORT_OWNER" and allow update FIPs for port owners14:46
ralonsohthis is a particular case14:46
ralonsohthat was proposed yes14:46
slaweqsimilar what we have for some port related apis where it can be done by "network owner"14:46
ralonsohthe FIp can be assigned to the project14:46
ralonsohthat is easier than creating a new particular rule type14:46
ralonsohok, let's propose the error change to 4xx14:46
ralonsohand you'll probably need to reconsider your deployment and how the FIP is created14:47
froyowhen the FIP is assigned to the project, the tenant user will be manage it completely? 14:47
ralonsohyes14:47
froyogood, so move the responsability to the admin ... good for me!14:47
ralonsohcool, thanks!14:47
ralonsohplease, open a lp bug for this14:48
slaweqI would just try to avoid doing hardcoded context.elevate() as much as possible14:48
froyothanks for comments!14:48
slaweqand use API rules as much as we can14:48
slaweqit's IMO better for S-RBAC policies14:48
ralonsohright14:48
ralonsohok, let's move ibn14:48
ralonsohon14:48
ralonsoh#link https://review.opendev.org/c/openstack/neutron/+/87580914:48
ralonsohqq: should we allow to backport this one?14:48
ralonsohthis is implicitly an API change14:48
ralonsohbut we in the other hand, this limitation is needed14:49
ralonsohbecause this is a bug fix, I would accept it, but waiting for opinions14:49
slaweqI think we would need opinion from stable-maint team on this14:50
lajoskatona+114:50
slaweqmaybe elodilles can take a look14:50
ralonsohI'll ping him14:50
lajoskatonaquite a corner case as ralonsoh said14:50
mlavalleyeah, we've sought their opinion before14:50
frickleris there an associated api-ref change?14:50
ralonsohno14:50
ralonsohthis is an implicit API change14:50
ralonsohbecause that introduces a limitation14:51
ralonsohthat is implicit by the standard, btw14:51
fricklerbut api-ref should specify conditions when api calls fail?14:51
frickleror at least it could14:51
ralonsohI don't know if we report that correctly in the API14:52
ralonsohthe neutron server logs that correctly14:52
fricklerthat would IMO improve the feasibility of a backport14:52
ralonsohok, I'll check that first14:52
ralonsohand that's all I have in the agenda14:53
ralonsohanything else??14:53
ralonsohso thank you very much and see you in 6 mins in the CI meeting (IRC type this week)14:53
ralonsoh#endmeeting14:53
opendevmeetMeeting ended Tue Apr 25 14:53:45 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:53
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-25-14.01.html14:53
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-25-14.01.txt14:53
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-25-14.01.log.html14:53
mlavalleo/14:53
lajoskatonao/14:53
mtomaskao/14:53
rubasovo/14:53
fricklerjust mentioning I'll be offline for 3 weeks starting thursday14:53
slaweqo/14:53
fricklero/14:54
mlavalleslaweq: ci meeting: video or irc?14:54
ykarelo/14:54
slaweqmlavalle irc14:54
mlavalleack14:54
elodillesslaweq ralonsoh : i haven't looked at the patch, but as a base rule i would say that neutron team needs to think about what issues could cause if that change is backported and deployments are upgraded to it. and on the other hand: what benefit can be achieved if it is backported14:56
elodillesif it is risky, then probably better to leave it to deployers to solve the backport downstream if they need it14:57
ralonsohelodilles, I'll check first what is the CLI output14:57
ralonsohtbh, this limitation is more an IP limitation than an API one14:58
ralonsohfrickler, have fun!14:58
fricklerwell currently users could still have working v4 with mtu=500 e.g. and only v6 broken. with that patch, the mtu change would fail instead14:59
fricklernot sure if that's a scenario to care about, though14:59
ralonsohhmmm no, that's right14:59
ralonsohI prefer a broken scenario rather than a new limitation in stable branched15:00
ralonsohbranches*15:00
ralonsohno, I don't think we should backport it15:00
*** iurygregory_ is now known as iurygregory15:00
fricklerotoh inconsistent, unpredictable API responses aren't nice for users, too15:01
slaweq#startmeeting neutron_ci15:01
opendevmeetMeeting started Tue Apr 25 15:01:17 2023 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.15:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
opendevmeetThe meeting name has been set to 'neutron_ci'15:01
mlavalleo/15:01
slaweqbcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva, elvira15:01
ralonsohhello15:01
mtomaskao/15:01
slaweqci meeting is starting :)15:01
slaweqhi15:01
lajoskatonao/15:01
ykarelo/15:02
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
slaweqI still didn't had time for this15:02
slaweqsorry15:03
slaweq#action slaweq to check dhcp issue in fullstack tests15:03
slaweqI will try this week15:03
slaweqnext one15:03
slaweqmtomaska to check and fix "no such process" error in kill cmd15:03
mtomaskaI posted patch https://review.opendev.org/c/openstack/neutron/+/88089315:03
slaweqthx15:03
mtomaskaAlso AI from week ago needs final review 15:03
slaweqI will add it to my review's queue15:03
mtomaskahttps://review.opendev.org/c/openstack/neutron/+/87854915:04
mtomaskathank you15:04
slaweqand the last one from last week15:04
slaweqslaweq to open bug regarding shelve/unshelve failures15:04
slaweqI opened https://bugs.launchpad.net/nova/+bug/201696715:04
slaweqbut nobody from nova team checked it15:05
slaweq#topic Stable branches15:06
slaweqbcafarel is on different meeting but he told me that all seems good with stable branches this week15:06
slaweqanything You have to add there or can we move on to next topics?15:06
ralonsohnothing15:07
slaweqok, lets move on then15:07
slaweq#topic Stadium projects15:07
slaweqodl and bagpipe's periodic jobs are red this week15:08
ralonsohcould be related to the py3.8 issue?15:08
ralonsohor the mirror issues?15:09
lajoskatonayes, for bagpipe I think it is only not master from sfc, but have to check in details15:09
lajoskatonafor ODL, I had no time to check, but it is also sqlalachemy2.015:09
slaweqok15:09
lajoskatonaI dont't think it is related to py3815:09
lajoskatonaand nothing more from me15:10
slaweqok, thx15:10
slaweq#topic Grafana15:11
slaweqhere I see that all our neutron-tempest-plugin jobs are still broken15:11
slaweqalso functional and py38 jobs were broken yesterday but those are already good15:11
lajoskatonaso graphana shows us real data :-)15:12
slaweqyeah15:12
lajoskatonaas those were/are really broken15:12
slaweqand our gate is broken now15:12
ralonsohwait for https://review.opendev.org/c/openstack/requirements/+/881433/2 (and the previous patch)15:12
ykarelyes once https://review.opendev.org/c/openstack/requirements/+/881466 merges scenario jobs should be green again15:14
slaweqthat will be great15:14
slaweqthx guys for working on all those issues15:14
slaweqanything else regarding grafana? or can we move on?15:15
mlavallelet's move on15:15
slaweq#topic Rechecks15:15
slaweqavg recheckes from last week looked good (0.33)15:16
slaweqbare rechecks: 9/22 were bare so pretty many but not dramatic :)15:16
ralonsohif you find bare rechecks, comment that in the patch15:17
slaweqsure15:17
slaweq++15:17
ralonsohI don't think all neutron developers are aware of that15:17
mlavalleor sometimes we need reminders15:18
lajoskatonagood idea, I will keep my eyes open15:18
slaweqthx all15:18
slaweqok, lets move on15:18
slaweq#topic fullstack/functional15:18
slaweqhere I have only one issue to mention15:18
slaweqneutron.tests.functional.agent.ovn.extensions.test_qos_hwol.OVSInterfaceEventTestCase.test_port_creation_and_deletion15:18
slaweq    https://7e36fd2cde2eb81dcf41-647b4a42ed353e16c17ad589257e07eb.ssl.cf5.rackcdn.com/877831/13/check/neutron-functional-with-uwsgi/0610ffa/testr_results.html15:18
slaweq    https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_4d6/878527/9/check/neutron-functional-with-uwsgi/4d6adb2/testr_results.html15:18
ralonsohI've pushed  a patch15:19
slaweqthose are 2 examples but I think I saw same error few more times15:19
ralonsohhttps://review.opendev.org/c/openstack/neutron/+/88093415:19
ralonsohif that patch doesn't work, I'll mark it as unstable15:20
slaweqthx15:20
slaweqI added it to review list15:20
slaweqfor tomorrow morning15:20
lajoskatoname too15:21
slaweqso we can move on I guess15:21
slaweq#topic Tempest/Scenario15:21
slaweqhere I don't have any specific issues for today15:21
slaweqbut ralonsoh wanted to talk about migration of neutron-tempest-plugin jobs to Jammy15:22
slaweqis the nova patch mentioned by ykarel the only think we need?15:22
ralonsohwell, I think we have discussed that during the last meeting15:22
ralonsohyes, this patch15:22
ralonsohand ykarel is testing that in neutron15:22
ralonsohone sec15:22
ralonsohhttps://review.opendev.org/c/openstack/neutron-tempest-plugin/+/88139115:22
ykarelalso i prepared https://etherpad.opendev.org/p/jammy-issues to have details together15:22
ralonsohlinux bridge tests seems unstable15:23
ralonsohmore than OVS or OVN15:23
ralonsohAm I right?15:23
ykarelso would need nova patch + jobs rework in neutron side(current idea is split slow tests in seperate job) and as per results seems to work better15:24
lajoskatonais that related to the py38/nested virt issues?15:24
ralonsohyes it is15:24
ralonsohso create new jobs for slow tests?15:24
ykarelralonsoh, yes till now seen 1 failure and that is in linuxbridge https://6b56f02e616b126f480f-032ac4cea892347a8142b5cb4ce2d8a7.ssl.cf2.rackcdn.com/881391/3/check/neutron-tempest-plugin-linuxbridge-4/00c563b/testr_results.html15:25
ralonsohwith concurrency = 1?15:25
ykarelcurrent tests are with concurrency = 2 and working fine15:25
ralonsohok15:25
slaweqbut do we want to have slow jobs for each variant? LIke openvswitch, ovn, openvswitch-iptables_hybdir, linuxbridge?15:25
slaweqso 4 new jobs running on every patch?15:25
slaweqor how?15:25
ykarelso if there is some other idea then slow jobs, we can rework15:26
ralonsohwe can execute then in periodic only15:26
lajoskatonaas temporary solution?15:26
ralonsohso far you have identified 6 tests15:27
slaweqare those times mentioned in https://etherpad.opendev.org/p/jammy-issues on nodes with really enabled nested virt?15:27
slaweqI don't think it takes that much time currently15:27
ykarelslaweq, those are non non-nested virt nodes or nested-virts(with qemu not kvm)15:27
slaweqahh, ok15:27
ykarelnested virts results are far better, like 2-3 times better15:27
slaweqso because it is using qemu instead of kvm it is so slow15:28
ykarelyes15:28
slaweqgood15:28
ralonsohso what do you think about having these 4 new jobs executing the slow tests?15:29
slaweqare "slow" tests the same ones as those which requires advanced image15:29
slaweq?15:29
ykarelyes most of them are those only15:30
slaweqok, that makes sens15:30
ralonsohbut where do we execute these jobs?15:30
slaweqI would then move those new jobs to periodic queue probably15:30
ralonsoh^^ right15:30
slaweqI don't think we should have 4 more jobs in check/gate queue15:30
ralonsohfor sure no15:30
slaweqit's a lot of resources on every patch15:30
lajoskatonaok, and when this libvirt /nested issue is fixed we can move them back to regular check/gate queue?15:31
ralonsohno, I don't think so15:32
ykarelyes if Team is ok i think we can move back, from infra side it's not recommended to rely on those nodes as they are best effort only15:32
ykarelas those worked great for almost an year for us15:32
ralonsohbut this policy will change, iif I'm not wrong15:32
ykarelif it's policy change then we have no option15:33
ralonsohI mean it is not recommended to use these nodes (or have them as non voting)15:33
slaweqok, so lets do this15:33
lajoskatonaack15:33
slaweqykarel will You propose patches?15:34
ykarelslaweq, will discuss it in nova meeting today and update nova patch as per that15:34
ykareland then update neutron jobs15:34
slaweq++ thx15:34
ykareltill then just will have tests in test patch15:34
lajoskatonathanks ykarel15:34
slaweq#action ykarel to discuss with nova team and update neutron-tempest-plugin jobs15:35
mlavallethanks!15:35
slaweqand that's all what I had for today15:35
slaweqany other CI topics You want to discuss today?15:35
ralonsohno thansk15:35
lajoskatonanothing from me15:36
ykareljust a small one15:36
ykarelhttps://review.opendev.org/c/openstack/neutron/+/88146415:36
ralonsohah yes, sure15:36
slaweqapproved :)15:37
ralonsohqq15:37
ralonsohshould we remove the py38 jobs there?15:37
slaweqIMO not until we support py3815:37
ralonsohI know we didn't migrate yet15:37
ralonsohok then15:37
lajoskatonagood question, and shall we push the changes for the stadiums? or that would brake the tempest jobs?15:38
slaweqit's just UT job so no big deal IMO to keep it for a bit longer15:38
lajoskatonaok, so keep everything else15:38
ralonsohpy39 should work in stadium15:38
lajoskatonaI check if with dnm patch15:38
slaweqthx lajoskatona 15:39
slaweq#action lajoskatona to check with dnm patch stadium projects with py3915:39
ykarelif openstack-python3 template is used py39 jobs should be already running in stadium15:39
ykarelopenstack-python3-jobs15:39
ykarelk i see openstack-python3-jobs-neutron template is being used15:40
lajoskatonayes, agree, what I am not sure what will happen with tempest if the project says "hey I am min py39"15:40
lajoskatonafor stadiums we have less tempest tests, so it should be ok15:41
ykarelhttps://opendev.org/openstack/openstack-zuul-jobs/src/branch/master/zuul.d/project-templates.yaml#L80215:41
ykarellajoskatona, stadium projects too running jobs on focal?15:42
lajoskatonathanks15:42
lajoskatonaykarel: hmmm, good question, I have to check that15:42
ralonsohyes, they are inheriting from neutron and n-t-p15:42
ralonsohor manually setting the nodeset15:43
ralonsohto focal15:43
ykarelok if there is no reason to run on focal then those can be moved to jammy15:43
lajoskatonaok, I propose patches and let's see15:43
ykarel+115:43
lajoskatonatrial and error :-)15:44
slaweq++15:44
slaweqanything else for today?15:44
slaweqif not, I will give You 15 minutes back today15:44
slaweqok, so thanks for attending the meeting and have a nice week15:45
slaweq#endmeeting15:45
opendevmeetMeeting ended Tue Apr 25 15:45:14 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:45
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-25-15.01.html15:45
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-25-15.01.txt15:45
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2023/neutron_ci.2023-04-25-15.01.log.html15:45
mlavalleo/15:45
ralonsohbye!15:45
slaweqo/15:45
lajoskatonaBye15:45
mtomaskao/15:45
ykarelo/15:46
opendevreviewLucas Alvares Gomes proposed openstack/neutron master: [OVN] Retry retrieving metadata port during PortBindingChassisEvent  https://review.opendev.org/c/openstack/neutron/+/88148715:55
opendevreviewMerged openstack/neutron master: Add py39 jobs to tox override template  https://review.opendev.org/c/openstack/neutron/+/88146417:03
opendevreviewRodolfo Alonso proposed openstack/neutron master: [DNM] Test loki  https://review.opendev.org/c/openstack/neutron/+/88145917:09
opendevreviewMiguel Lavalle proposed openstack/neutron master: Add rate-limiting to metadata agents  https://review.opendev.org/c/openstack/neutron/+/85887919:57
opendevreviewMerged openstack/neutron master: [ovn] Drop use of OVN_GW_PORT_EXT_ID_KEY  https://review.opendev.org/c/openstack/neutron/+/87783120:06
opendevreviewMiguel Lavalle proposed openstack/neutron master: Add rate-limiting to metadata agents  https://review.opendev.org/c/openstack/neutron/+/85887922:45
« Monday, 2023-04-24 Index Wednesday, 2023-04-26 »

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