Tuesday, 2023-02-21

opendevreviewMerged openstack/neutron stable/zed: [S-RBAC] Allow admin user to do all API requests by default  https://review.opendev.org/c/openstack/neutron/+/87439900:59
opendevreviewBrian Haley proposed openstack/neutron master: Change DHCP agent setup code to deal with small MTUs  https://review.opendev.org/c/openstack/neutron/+/87416701:09
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: Remove FIPAddDeleteEvent event  https://review.opendev.org/c/openstack/neutron/+/86400001:45
*** pvxe8 is now known as pvxe02:18
*** pvxe0 is now known as pvxe03:52
opendevreviewMerged openstack/tap-as-a-service master: CI: Add openstack-tox-py39-with-oslo-master to periodic weekly queue  https://review.opendev.org/c/openstack/tap-as-a-service/+/86210906:40
opendevreviewLuis Tomas Bolivar proposed openstack/ovn-octavia-provider master: Ensure HM also apply to FIPs associated to LB VIPs  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87386007:27
opendevreviewMerged openstack/networking-sfc master: CI: Add oslo and sqlalchemy master jobs to periodic weekly queue  https://review.opendev.org/c/openstack/networking-sfc/+/86210207:30
*** ralonsoh_ooo is now known as ralonsoh07:32
ralonsohslaweq, hi! Please check if https://review.opendev.org/c/openstack/neutron/+/874398 is needed07:33
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config  https://review.opendev.org/c/openstack/neutron/+/87453608:21
tobias-urdinany idea why an L3 HA router would have no fixed ips assigned to the "ha" ports, so when l3_db builds it skips those interfaces, so they are bound by ovs agent but since they don't have any interfaces keepalived goes into fault (backup as reported by neutron) and causes it to not work08:47
tobias-urdini'll need to dig deeper, but i've never seen ha ports without any fixed ips08:48
opendevreviewLuis Tomas Bolivar proposed openstack/ovn-octavia-provider master: Ensure HM also apply to FIPs associated to LB VIPs  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87386009:04
isabekralonsoh, dalvarez Hi! when you have a time can you please check my comment on bug https://bugs.launchpad.net/neutron/+bug/1985096 ?09:06
ralonsohI'll check it09:06
opendevreviewLajos Katona proposed openstack/neutron stable/wallaby: Fullstack: Wait placement process fixtrue to really stop  https://review.opendev.org/c/openstack/neutron/+/87449910:22
opendevreviewLuis Tomas Bolivar proposed openstack/ovn-octavia-provider master: Ensure HM also apply to FIPs associated to LB VIPs  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87386010:44
ralonsohlajoskatona, hi! How do I deploy an env with vpnaas (and OVN)? with devstack11:38
lajoskatonaralonsoh: Hi, I know this page: https://docs.openstack.org/neutron-vpnaas/latest/contributor/devstack.html11:54
lajoskatonaralonsoh: but not sure if it is enough for deploying it with  OVN11:54
ralonsohno, I'm testing with OVS11:54
ralonsohchecking https://bugs.launchpad.net/neutron/+bug/200782611:54
ralonsohthanks!!11:55
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master  https://review.opendev.org/c/openstack/networking-bagpipe/+/87240812:45
ralonsohgmann (and slaweq) hi! We are pushing https://review.opendev.org/c/openstack/neutron/+/874536. I saw https://review.opendev.org/c/openstack/tempest/+/764226/2/zuul.d/base.yaml#2212:49
ralonsohwhat is that line doing? counting the compute nodes AND the controllers?12:49
ralonsoh(I'm a newby with zuul ansible)12:49
opendevreviewLajos Katona proposed openstack/neutron master: WIP: desperate try to make DVR functional tests more stable  https://review.opendev.org/c/openstack/neutron/+/87311112:50
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master  https://review.opendev.org/c/openstack/networking-bagpipe/+/87240812:50
*** ralonsoh is now known as ralonsoh_lunch12:51
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master  https://review.opendev.org/c/openstack/networking-bagpipe/+/87240812:54
opendevreviewLajos Katona proposed openstack/neutron-dynamic-routing master: CI: Add periodic weekly job with sqlalchemy master  https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/87256213:03
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config  https://review.opendev.org/c/openstack/neutron/+/87453613:03
opendevreviewLajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy main  https://review.opendev.org/c/openstack/networking-bagpipe/+/87240813:05
opendevreviewLajos Katona proposed openstack/networking-bgpvpn master: CI: add oslo_master and sqlalchemy to periodic weekly  https://review.opendev.org/c/openstack/networking-bgpvpn/+/86196013:10
opendevreviewLajos Katona proposed openstack/networking-odl master: CI: Add periodic weekly job with sqlalchemy main  https://review.opendev.org/c/openstack/networking-odl/+/87241613:16
fricklerralonsoh_lunch: that line is counting the number of hosts in the compute group only. if that group doesn't exist, it returns length(['controllers']), which is 113:27
opendevreviewMerged openstack/neutron master: [OVN] Bump the port revision number in trunk driver  https://review.opendev.org/c/openstack/neutron/+/87329613:28
fricklerfor your openstack-three-node-focal it should return 3, since the controller is part of the compute group, too: https://opendev.org/openstack/devstack/src/branch/master/.zuul.yaml#L316-L32013:28
ralonsoh_lunchfrickler, thanks! we'll need to modify that then13:31
*** ralonsoh_lunch is now known as ralonsoh13:31
opendevreviewLajos Katona proposed openstack/networking-bgpvpn master: Remove tripleo related jobs  https://review.opendev.org/c/openstack/networking-bgpvpn/+/87458213:41
opendevreviewLuis Tomas Bolivar proposed openstack/ovn-octavia-provider master: Ensure HM also apply to FIPs associated to LB VIPs  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87386013:47
ralonsohping bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu 14:00
ralonsoh#startmeeting networking14:00
opendevmeetMeeting started Tue Feb 21 14:00:38 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
lajoskatonao/14:00
ralonsohhello all14:00
isabekHi14:00
obondarevhi14:00
rubasovo/14:00
elvirao/14:01
ralonsohlet's start14:01
ralonsoh#topic announcements14:01
frickler\o14:02
ralonsohAntelope / 2023.1 schedule: https://releases.openstack.org/antelope/schedule.html14:02
ralonsohwe are in R-414:02
ralonsohthis week I'll push https://releases.openstack.org/antelope/schedule.html#a-cycle-highlights14:02
ralonsohonce I have this patch, i'll ping you to review it and comment14:02
ralonsohand remember next week is the RC-114:02
lajoskatona+1, thanks14:03
ykarelo/14:03
ralonsohsame as last week, I'll remember here the bobcat etherpads14:03
ralonsohfor the PTG: https://etherpad.opendev.org/p/neutron-bobcat-ptg14:03
ralonsohfor Vancouver: https://etherpad.opendev.org/p/neutron-vancouver-202314:03
ralonsohplease, don't hesitate to add your topics (I'll send a mail today again)14:04
ralonsohand that's all I have in this topic. Good news are that the CI is working 1 week before the RC1 and nothing seems to be broken14:04
ralonsohfingers crossed 14:05
ralonsohnext topic14:05
ralonsoh#topic bugs14:05
ralonsohykarel, had a very busy week14:05
ralonsoh#link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032314.html14:05
ralonsohthere are some bugs that need to be commented here14:06
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200735714:06
ralonsohykarel, do you have any update?14:06
ykarelralonsoh, for that i pushed a patch in grenade to catch console log to debug further14:06
ykarelhttps://review.opendev.org/c/openstack/grenade/+/87441714:06
ralonsohdo you have the link?14:06
ralonsohperfect14:06
ykarelseems not linked in bug, will update14:07
ralonsohI'll add it to the bug14:07
ralonsohok, with this patch we'll have more info14:07
ralonsohthanks!14:07
ralonsohnext one14:08
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200735314:08
ralonsohI'll take this one this week14:08
ralonsohit's failing too often14:08
slaweq++ thx14:09
ralonsohnext one14:09
ralonsoh#topic https://bugs.launchpad.net/neutron/+bug/193466614:09
ralonsohthis is something slaweq is working on14:09
ralonsohpatch: https://review.opendev.org/c/openstack/neutron/+/87453614:09
ralonsohthat used a 3 node set and only the controller is dvr_snat14:10
ralonsoh^^ please review this patch14:10
slaweqI'm working only on change for the ci job, not bug itself14:10
ykarelk let's link that too to the bug14:10
slaweqjust to be clear :)14:10
ralonsohyeah but this is the bug itself: that we can't use snat_dvr on computes14:10
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config  https://review.opendev.org/c/openstack/neutron/+/87453614:10
ralonsohI'll add this link in the bug too14:11
ralonsohthanks!14:11
slaweqykarel done14:11
ykarelthx14:11
*** dasm|off is now known as dasm14:12
ralonsohnext one 14:12
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200741414:12
ralonsoha low hanging fruit one14:12
ralonsohnext one14:12
ralonsoh#link https://bugs.launchpad.net/nova/+bug/200646714:12
ralonsohykarel, ^^14:12
ralonsohany update?14:12
ralonsohis the cirros 0.6.1 image affecting nova-next?14:13
ykarelralonsoh, no cirros 0.6.1 not related there14:13
ralonsohok14:13
ykareli commented what i found, can you please check based on that comment14:13
ralonsohok, I'll check last comment this afternoon (I see my name there)14:14
ykarelyeap, Thanks14:14
ralonsohcool, next one14:14
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200767414:14
ralonsohIMO, this could be a RFE14:14
ralonsohgood to have but not a bug itself14:15
ralonsohso if you agree, I'll add the RFE tag14:15
ykareli didn't digged much there on why those many connections are opened by openvswitch-agent,14:16
ykarelso those are for purpose?14:16
ralonsohwe create one per topic14:16
ralonsohports, sg, networks, etcv14:16
lajoskatonaWe can make it an RFE, but first should be to understand the current situation14:16
lajoskatonaand what can we cause if we change it14:17
ralonsohagree. To be honest, I don't know if we can't make this change with our current RPC implementation14:17
ralonsohbut I didn't spend too much time on this14:17
lajoskatona+114:18
ralonsohso first thing is to tag it as RFE and then investigate if that is possible14:18
ykarel+114:18
ralonsohI'll do it after this meeting14:18
ralonsohlast one is14:19
ralonsoh#link https://bugs.launchpad.net/neutron/+bug/200793814:19
ralonsohrubasov, ^^ can you check that?14:19
ralonsohdid you check this feature with multiple DHCP agents?14:19
rubasovyep14:19
rubasovprobably not14:20
ralonsohbecause when I have 2, the second one can't spawn the metadata service14:20
ralonsohwhen using the metadata service + ipv6 from the dhcp agent, we'll probably need to check that and spawn only one (despite the DHCP agent redundancy)14:21
rubasovI'll put this on my todo list14:21
ralonsohthis is because we can only have one ipv6 metadata IP14:21
ralonsohrubasov, thanks a lot!14:21
fricklerhow is that different with v4?14:21
rubasovI have a vague memory that we already had a similar bug, I will check more throughly14:22
ralonsohI would need to check that, yes I remember somethign related14:22
ralonsohI just reproduced this issue and reported the cause 14:22
rubasovthanks14:23
fricklerlast week we talked about https://bugs.launchpad.net/neutron/+bug/2006145, I responded on the bug, but I'm still not sure whether this is a bug really or an RFE14:23
ralonsohI think the goal is, as in other agents, to keep the agent functionality without RPC communication14:24
ralonsohbut I understand the current implementation14:24
ralonsohto be honest, not having RPC link is a broken env, so the current behaviour is valid14:25
ralonsohI would consider that as a RFE14:25
fricklerok, I'd be fine with that. question either way would be who is willing to work on that14:25
ralonsohI'll check if ltomasbo can (or maybe he can point me to someone else)14:26
fricklerif not, we could also just keep it as wishlist bug14:27
lajoskatonacan't we ask the reporter if they can work on this?14:27
ralonsohfor sure, I'll do it too14:27
ralonsohnew Neutron policy: you report, you fix!!14:27
lajoskatonaagree, if nobody works on it the RFE is still valid, just hangs14:28
slaweq:D14:28
fricklernote to self: stop reporting bugs at once ;)14:28
lajoskatonawe can be honest that currently nobody has free time for it, if you need it try to fix it :-)14:28
ralonsohexactly14:29
ralonsohok, any other bug to be discussed?14:29
ralonsohthis week bcafarel is the deputy, next week will be lajoskatona14:30
ralonsohlet's move to the next topic14:30
ralonsoh#topic community_goals14:30
ralonsoh1) Consistent and Secure Default RBAC14:30
lajoskatonaralonsoh: ack14:31
ralonsohthere are some backports related to RBAC14:31
ralonsohand a new one reported this morning: https://review.opendev.org/c/openstack/neutron/+/87439814:31
ralonsohslaweq, ^ do we need to backport it to previous releases?14:32
*** arnau is now known as averdaguer14:32
slaweqthat's good question14:32
slaweqI didn't propose it to other branches basically because it changes default policies14:33
slaweqI don't even know if we should backport it to Zed14:33
slaweqespecially that new RBACs are still documented as "experimental" in Neutron14:33
ralonsohso this patch should only be in master (actually in bobcat that is when we'll enable sRABC by default)14:34
ralonsohright?14:34
slaweqI proposed it to Zed as Zed may have all other fixes too so it should works there14:35
slaweqbut I'm also fine with abandoning that backport14:35
slaweqI just want to hear about others' opinions14:35
slaweqI can also backport it to older branches if that's ok for everyone14:35
ralonsohif sRBAC is not available in Zed, that will affect the current policy behaviour14:36
ralonsohso we should not backport it14:36
fricklerI think mnaser had some interest in getting that to work on zed?14:36
lajoskatonaif I understand well, I agree14:36
slaweqyes, I can try to change that backport to not delete old default policy but maybe modify just new default's part14:37
lajoskatonaI mean if that is not supported on older branches.....14:37
ralonsohfrickler, I would think in other deployments that won't use sRBAC14:37
ralonsohbecause this is not supported in Zed14:37
slaweqstarting from 2023.1 we have tempest job which tests new defaults, but in Zed we didn't had it14:37
ralonsohthat's the point14:38
slaweqwe may propose that job to Zed also and backport all to Zed14:38
slaweqbut I'm not sure if we should go to older branches too14:38
ralonsohthis is a community effort14:38
fricklermaybe leaving zed backports to interested downstreams would be fine, too14:38
ralonsohsRBAC is not supported in Zed14:38
lajoskatonafrickler: +114:39
ralonsohslaweq, I would check that with gmann but he +1 this patch14:39
slaweqok, I will discuss it with gmann14:40
ralonsohthanks, please ping us with the conclusion14:40
slaweqsure14:41
ralonsohand this is all I have in this topic, so let's move to the next one14:41
ralonsoh#topic on_demand14:41
ralonsohI have nothing in the agenda14:41
ralonsohplease present your topics14:41
slaweqjust one thing/reminder14:41
slaweqI saw email that this week is deadline for cycle highlights14:42
ralonsohyes, I'm doing it now14:42
slaweqahh, great14:42
slaweqthx14:42
slaweqso that's all from me14:42
slaweq:)14:42
ralonsohI'll ping all of you with the patch to add any comment14:42
slaweq++14:42
lajoskatonathanks14:42
ralonsohremember the CI meeting is in 15 mins (today on video)14:43
ralonsohthank you all for attending14:43
slaweqyep14:44
ralonsoh#endmeeting14:44
opendevmeetMeeting ended Tue Feb 21 14:44:06 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:44
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.html14:44
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.txt14:44
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.log.html14:44
slaweqo/14:44
lajoskatonao/14:44
isabeko/14:44
ralonsohsee you in 15 mins14:44
ykarelo/14:45
mnaserhi guys, we are using zed and have it enabled for a bunch of services and neutron is the only missing piece14:45
mnaser(for secure rbac)14:45
mnaseri would not mind being the person who has to cherry-pick things if we run into breakages14:46
mnasersince we are trying to run zed with secure rbac (and we actually have users that are using the 'reader' role)14:47
ralonsohthis is being discussed now. Zed does not support sRBAC yet and slaweq is checking if this patch in particular can be backported14:50
opendevreviewRodolfo Alonso proposed openstack/neutron master: Improve "sync_ha_chassis_group" method  https://review.opendev.org/c/openstack/neutron/+/87202314:50
opendevreviewRodolfo Alonso proposed openstack/neutron master: WIP - Add ``OVNGatewayHAChassisGroup`` scheduler class  https://review.opendev.org/c/openstack/neutron/+/87203314:50
slaweqmnaser the problematic backport is https://review.opendev.org/q/I5fe4a0134c6ecf5cf28e2f5d59411134546c98b0 as this changes default config value14:51
slaweqI will look into this and will try to maybe change it a bit to not change old policy14:51
mnaserslaweq: oh, because the fix assumes that enforce_scope will be permenantly on in since it is in master?14:52
slaweqralonsoh from the other hand, if I think about it - the default behaviour for someone who uses old policies shouldn't change as it was RULE_ANY and without specifying anything it still will behave the same way, right?14:53
slaweqmnaser it's not on by default yet14:53
slaweqwe plan to do it in next cycle14:53
slaweqbut since few weeks we have CI job which is testing those new default policies so IMO we can say it's now supported officially14:54
ralonsohslaweq, if you remove this rule, shouldn't apply the get_network one?14:54
slaweqralonsoh and that ^^ may be good candidate for cycle highlights too :)14:54
ralonsohyes, sRBAC for sure14:55
slaweqralonsoh no, this rule is about who can see "router:external" attribute in network14:55
slaweqnot about who can show network with router:external=True14:55
slaweqso basically attribute "router:external" should be visible for everyone14:56
ralonsohyeah, I mean14:56
ralonsohyou should be able to see the parameter if you can see this network14:56
slaweqexactly and that behaviour won't change with this backport14:56
ralonsohperfect then14:56
ralonsohso I think is backportable14:56
slaweqyes, I think so as well now as we are discussing about it14:57
slaweq#startmeeting neutron_ci15:00
opendevmeetMeeting started Tue Feb 21 15:00:28 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
slaweqbcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva is starting now15:00
slaweqThis will be video meeting this time: https://meetpad.opendev.org/neutron-ci-meetings15:00
lajoskatonao/15:02
slaweq#link https://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=115:02
slaweq#topic Actions from previous meetings15:02
slaweqlajoskatona to continue checking dvr functional tests issues15:03
lajoskatonahttps://review.opendev.org/c/openstack/neutron/+/87311115:03
lajoskatonahttps://zuul.opendev.org/t/openstack/status#87311115:04
slaweqhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_594/874167/3/check/neutron-fullstack-with-uwsgi/5943274/testr_results.html15:05
slaweq#action lajoskatona to continue checking dvr functional tests issues15:07
slaweqralonsoh to try to store journal log in UT job's results to debug "no such table" issues15:07
slaweqslaweq to report bug about failed to bind LRP in functional tests15:08
slaweqhttps://bugs.launchpad.net/neutron/+bug/200735315:08
slaweqlajoskatona to talk with zhouhenglc about fwaas jobs issues15:09
slaweqslaweq to report bug with failed ping in grenade jobs15:10
slaweq    Bug: https://bugs.launchpad.net/neutron/+bug/200735715:10
lajoskatonahttps://review.opendev.org/c/openstack/grenade/+/87441715:10
ozzzo_workI'm using the unified python API (cloud.network.security_groups) to pull security groups, but in large clusters it times out:  The server didn't respond in time.: 504 Gateway Time-out abraden@osjump2.shared-bo.brn1:~/cloud-support/cloud-scripts [ent-ansible-2.9.20:qde3:admin]$ 15:11
ozzzo_workHow can I extend the timeout?15:12
slaweqykarel to fix grenade random fails pcp installation15:12
ozzzo_workI can pull the list via CLI no problem;; apparently CLI uses a longer timeout15:12
slaweq#topic Stadium projects15:12
slaweq#topic Grafana15:13
slaweq#topic Rechecks15:15
slaweq+---------+----------+... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/zGdkCHJPJcPaKOFRsHSnkNhR>)15:15
slaweqhttps://review.opendev.org/c/openstack/neutron/+/87324715:16
slaweq#topic Unit tests15:18
slaweqhttps://bugs.launchpad.net/neutron/+bug/200725415:18
slaweq#topic fullstack/functional15:18
slaweqhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b8d/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-oslo-master/b8d8c53/testr_results.html15:19
ozzzo_workShould I try a different channel? Where's the best place to ask about the API?15:20
slaweqhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_978/periodic/opendev.org/openstack/neutron/master/neutron-functional/9789c89/testr_results.html15:20
ralonsohozzzo_work, we are in a meeting now15:20
ozzzo_workoic ok15:21
slaweqhttps://64e9807acd80d4cab1ab-851182d93d98b3728f798963c90c7371.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-uwsgi-fips/1914083/testr_results.html15:21
slaweq#action slaweq to check https://64e9807acd80d4cab1ab-851182d93d98b3728f798963c90c7371.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-uwsgi-fips/1914083/testr_results.html15:22
slaweqhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_138/874342/2/check/neutron-ovn-tempest-ipv6-only-ovs-release/138097d/testr_results.html15:22
slaweq#topic Tempest/Scenario15:23
slaweqhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_138/874342/2/check/neutron-ovn-tempest-ipv6-only-ovs-release/138097d/testr_results.html15:23
slaweqhttps://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_992/periodic/opendev.org/openstack/neutron/master/neutron-ovn-tempest-slow/992d108/testr_results.html15:23
slaweqhttps://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_64e/periodic/opendev.org/openstack/neutron/master/neutron-ovn-tempest-slow/64eb479/testr_results.html15:23
slaweq#action slaweq to report bug about macspoofing_port test in ovn-tempest-slow job15:25
slaweq#topic Periodic15:25
slaweqneutron-functional-with-sqlalchemy-master15:25
slaweq#action ralonsoh to check neutron-functional-with-sqlalchemy-master failures15:27
slaweq#topic On Demand15:28
slaweq    Regarding to the discussion in https://review.opendev.org/c/openstack/neutron/+/869741 I proposed today https://review.opendev.org/c/openstack/neutron/+/874536 - please tell me what do You think about it15:28
ralonsohone quick topic: #link https://bugs.launchpad.net/neutron/+bug/200798615:30
ralonsohhttps://review.opendev.org/c/openstack/tempest/+/87305515:30
slaweqhttps://github.com/openstack/neutron-tempest-plugin/blob/master/zuul.d/wallaby_jobs.yaml15:33
slaweqhttps://github.com/openstack/neutron-tempest-plugin/blob/1.8.0/zuul.d/rocky_jobs.yaml#L12015:35
ykarelhttps://review.opendev.org/c/openstack/devstack/+/87178215:36
ykarelhttps://zuul.openstack.org/builds?job_name=tempest-full-py3&branch=stable%2Fwallaby&skip=015:36
opendevreviewLajos Katona proposed openstack/python-neutronclient master: OSC: Remove BGP calls to neutronclient  https://review.opendev.org/c/openstack/python-neutronclient/+/86832115:36
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Member provisioning_status comes back to NO_MONITOR after HM delete  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87460915:41
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider stable/zed: Reduce coverage threshold on stable branches  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87442616:01
opendevreviewRodolfo Alonso proposed openstack/neutron master: Format correctly (dialect=mac_unix_expanded) the MAC addresses  https://review.opendev.org/c/openstack/neutron/+/87465416:11
opendevreviewFernando Royo proposed openstack/ovn-octavia-provider master: Reset member provisioning status to NO_MONITOR when a HM is deleted  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/87460916:14
opendevreviewRodolfo Alonso proposed openstack/neutron master: Check port.tag is not DEAD_VLAN_TAG in ``DHCPAgentOVSTestFramework``  https://review.opendev.org/c/openstack/neutron/+/87465816:24
*** sean-k-mooney1 is now known as sean-k-mooney16:25
opendevreviewMaurice Escher proposed openstack/neutron master: ml2 plugin: use const from neutron-lib  https://review.opendev.org/c/openstack/neutron/+/87463117:16
opendevreviewRodolfo Alonso proposed openstack/neutron master: DNM WIP remove FT OVN workaround for sqlite  https://review.opendev.org/c/openstack/neutron/+/87466917:16
ozzzo_workIs the meeting over now? Does anyone have any ideas on my API question?17:40
ozzzo_workI'm using the unified python API (cloud.network.security_groups) to pull security groups, but in large clusters it times out:  The server didn't respond in time.: 504 Gateway Time-out17:40
ralonsohozzzo_work, what is the unified python API?17:46
ralonsohdo you mean you are using the SDK bindings17:46
ralonsohhow are you calling this method?17:47
ozzzo_workyes sdk17:54
ralonsohand what client is using it?17:55
ozzzo_workhttps://paste.openstack.org/show/bVPEmD2n75LhMfqBaf6e/17:56
ozzzo_workI think I need to increase the timeout value17:58
ozzzo_workLooking here: https://docs.openstack.org/openstacksdk/latest/user/proxies/network.html18:02
ozzzo_workBut it doesn't mention the timeout value.18:03
ralonsohozzzo_work, in the "register_argparse_arguments", when creating the connect object18:08
ralonsohthere is a mention to --timeout18:08
ralonsohwhat I don't know is how to build this "options" object (that seems to be an ArgumentParser18:08
ozzzo_workwhere do you see --timeout?18:10
ralonsohhttps://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L75518:13
ralonsohdo this18:13
ralonsohhttps://paste.opendev.org/show/b3E6bv7jQEaRQzSwTePW/18:13
ralonsohand when calling this script, pass an input argument18:13
ralonsoh./script.py --timeout=100018:13
ralonsohif you check "options" in https://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L77018:14
ralonsohyou'll see that the input argument has been read18:14
ozzzo_workok I'll try that, ty!18:17
gmannralonsoh: RE on https://review.opendev.org/c/openstack/tempest/+/764226/2/zuul.d/base.yaml#2218:24
gmannralonsoh: basically it count the minimum compute node and set in tempest conf so that we can decide on mulitnode test to be skipped or run18:24
gmannexample https://github.com/openstack/tempest/blob/1569290be06e61d63061ae35a997aff0ebad68f1/tempest/api/compute/admin/test_live_migration.py#L4718:25
gmannralonsoh: basically it count the number of compute defined in jobs, for example in base job https://github.com/openstack/devstack/blob/e5c8e2951f8eed2d618bcb7c1d99adddeca4fffe/.zuul.yaml#L12818:28
gmannralonsoh: slaweq lajoskatona frickler on new RBAC fixes backport to zed, as background yes mnaser was testing the new defaults on zed and to make new RBAC work we need to backport those fixes. I think we said ok to backport at the time fixing those on master but did not find ref.18:31
gmannbasically we had new RBAC released in zed and they were disable by default but anyone can enable them and use it. for that I think we should fix it. basically migration plan will be:18:33
gmann-  operator upgrading from Yoga to Zed get the new RBAC option to enable but as it is disabled by default in zed they can try and fix the things during this cycle.18:33
gmann- in operator upgrading from zed to 2023.1, get those new RBAC as default so no surprise to them.18:33
gmannotherwise operator will get chance to use/try new RBAC only in 2023.1 and it is enabled by default there so it does not give them a cycle time for something new coming as default 18:34
gmannI like to slaweq idea of backporting only new RBAC rule and do not remove the old policy rule in zed backport18:35
gmannralonsoh: slaweq: lajoskatona: if we are not making neutron new RBAC working in zed then I will say we should not enable it by default in 2023.1 instead enable by default in 2023.2. BUT to ship nova+neutron together with new RBAC and make it usable at operator side, we should backport and make neutron new rbac work on zed  18:37
gmannralonsoh: slaweq: lajoskatona: I just realized we should keep old rule on master also because old rules are still supported (disabled by default) unless we remove them https://review.opendev.org/c/openstack/neutron/+/865032/1/neutron/conf/policies/network.py#b20418:41
lajoskatonagmann: thanks for background18:50
lajoskatonagmann, ralonsoh, slaweq: should we discuss this perhaps on Friday during the drivers meeting?18:51
*** dasm is now known as dasm|off19:56
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config  https://review.opendev.org/c/openstack/neutron/+/87453621:20
opendevreviewSlawek Kaplonski proposed openstack/neutron master: [S-RBAC] Add release note about full support for new policies  https://review.opendev.org/c/openstack/neutron/+/87470621:35
opendevreviewMerged openstack/neutron stable/victoria: Improve scheduling L3/DHCP agents, missing lower binding indexes  https://review.opendev.org/c/openstack/neutron/+/87362821:42
opendevreviewSlawek Kaplonski proposed openstack/neutron-tempest-plugin master: [Secure RBAC] Add scope enforcement enabled job for Zed branch  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/87470921:44

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