opendevreview | Merged openstack/neutron stable/zed: [S-RBAC] Allow admin user to do all API requests by default https://review.opendev.org/c/openstack/neutron/+/874399 | 00:59 |
---|---|---|
opendevreview | Brian Haley proposed openstack/neutron master: Change DHCP agent setup code to deal with small MTUs https://review.opendev.org/c/openstack/neutron/+/874167 | 01:09 |
opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: Remove FIPAddDeleteEvent event https://review.opendev.org/c/openstack/neutron/+/864000 | 01:45 |
*** pvxe8 is now known as pvxe | 02:18 | |
*** pvxe0 is now known as pvxe | 03:52 | |
opendevreview | Merged 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/+/862109 | 06:40 |
opendevreview | Luis 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/+/873860 | 07:27 |
opendevreview | Merged openstack/networking-sfc master: CI: Add oslo and sqlalchemy master jobs to periodic weekly queue https://review.opendev.org/c/openstack/networking-sfc/+/862102 | 07:30 |
*** ralonsoh_ooo is now known as ralonsoh | 07:32 | |
ralonsoh | slaweq, hi! Please check if https://review.opendev.org/c/openstack/neutron/+/874398 is needed | 07:33 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config https://review.opendev.org/c/openstack/neutron/+/874536 | 08:21 |
tobias-urdin | any 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 work | 08:47 |
tobias-urdin | i'll need to dig deeper, but i've never seen ha ports without any fixed ips | 08:48 |
opendevreview | Luis 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/+/873860 | 09:04 |
isabek | ralonsoh, dalvarez Hi! when you have a time can you please check my comment on bug https://bugs.launchpad.net/neutron/+bug/1985096 ? | 09:06 |
ralonsoh | I'll check it | 09:06 |
opendevreview | Lajos Katona proposed openstack/neutron stable/wallaby: Fullstack: Wait placement process fixtrue to really stop https://review.opendev.org/c/openstack/neutron/+/874499 | 10:22 |
opendevreview | Luis 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/+/873860 | 10:44 |
ralonsoh | lajoskatona, hi! How do I deploy an env with vpnaas (and OVN)? with devstack | 11:38 |
lajoskatona | ralonsoh: Hi, I know this page: https://docs.openstack.org/neutron-vpnaas/latest/contributor/devstack.html | 11:54 |
lajoskatona | ralonsoh: but not sure if it is enough for deploying it with OVN | 11:54 |
ralonsoh | no, I'm testing with OVS | 11:54 |
ralonsoh | checking https://bugs.launchpad.net/neutron/+bug/2007826 | 11:54 |
ralonsoh | thanks!! | 11:55 |
opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master https://review.opendev.org/c/openstack/networking-bagpipe/+/872408 | 12:45 |
ralonsoh | gmann (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#22 | 12:49 |
ralonsoh | what is that line doing? counting the compute nodes AND the controllers? | 12:49 |
ralonsoh | (I'm a newby with zuul ansible) | 12:49 |
opendevreview | Lajos Katona proposed openstack/neutron master: WIP: desperate try to make DVR functional tests more stable https://review.opendev.org/c/openstack/neutron/+/873111 | 12:50 |
opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master https://review.opendev.org/c/openstack/networking-bagpipe/+/872408 | 12:50 |
*** ralonsoh is now known as ralonsoh_lunch | 12:51 | |
opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy master https://review.opendev.org/c/openstack/networking-bagpipe/+/872408 | 12:54 |
opendevreview | Lajos Katona proposed openstack/neutron-dynamic-routing master: CI: Add periodic weekly job with sqlalchemy master https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/872562 | 13:03 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config https://review.opendev.org/c/openstack/neutron/+/874536 | 13:03 |
opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: CI: Add periodic weekly job with sqlalchemy main https://review.opendev.org/c/openstack/networking-bagpipe/+/872408 | 13:05 |
opendevreview | Lajos Katona proposed openstack/networking-bgpvpn master: CI: add oslo_master and sqlalchemy to periodic weekly https://review.opendev.org/c/openstack/networking-bgpvpn/+/861960 | 13:10 |
opendevreview | Lajos Katona proposed openstack/networking-odl master: CI: Add periodic weekly job with sqlalchemy main https://review.opendev.org/c/openstack/networking-odl/+/872416 | 13:16 |
frickler | ralonsoh_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 1 | 13:27 |
opendevreview | Merged openstack/neutron master: [OVN] Bump the port revision number in trunk driver https://review.opendev.org/c/openstack/neutron/+/873296 | 13:28 |
frickler | for 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-L320 | 13:28 |
ralonsoh_lunch | frickler, thanks! we'll need to modify that then | 13:31 |
*** ralonsoh_lunch is now known as ralonsoh | 13:31 | |
opendevreview | Lajos Katona proposed openstack/networking-bgpvpn master: Remove tripleo related jobs https://review.opendev.org/c/openstack/networking-bgpvpn/+/874582 | 13:41 |
opendevreview | Luis 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/+/873860 | 13:47 |
ralonsoh | ping bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, sahid, slawek, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu | 14:00 |
ralonsoh | #startmeeting networking | 14:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
opendevmeet | The meeting name has been set to 'networking' | 14:00 |
lajoskatona | o/ | 14:00 |
ralonsoh | hello all | 14:00 |
isabek | Hi | 14:00 |
obondarev | hi | 14:00 |
rubasov | o/ | 14:00 |
elvira | o/ | 14:01 |
ralonsoh | let's start | 14:01 |
ralonsoh | #topic announcements | 14:01 |
frickler | \o | 14:02 |
ralonsoh | Antelope / 2023.1 schedule: https://releases.openstack.org/antelope/schedule.html | 14:02 |
ralonsoh | we are in R-4 | 14:02 |
ralonsoh | this week I'll push https://releases.openstack.org/antelope/schedule.html#a-cycle-highlights | 14:02 |
ralonsoh | once I have this patch, i'll ping you to review it and comment | 14:02 |
ralonsoh | and remember next week is the RC-1 | 14:02 |
lajoskatona | +1, thanks | 14:03 |
ykarel | o/ | 14:03 |
ralonsoh | same as last week, I'll remember here the bobcat etherpads | 14:03 |
ralonsoh | for the PTG: https://etherpad.opendev.org/p/neutron-bobcat-ptg | 14:03 |
ralonsoh | for Vancouver: https://etherpad.opendev.org/p/neutron-vancouver-2023 | 14:03 |
ralonsoh | please, don't hesitate to add your topics (I'll send a mail today again) | 14:04 |
ralonsoh | and 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 broken | 14:04 |
ralonsoh | fingers crossed | 14:05 |
ralonsoh | next topic | 14:05 |
ralonsoh | #topic bugs | 14:05 |
ralonsoh | ykarel, had a very busy week | 14:05 |
ralonsoh | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032314.html | 14:05 |
ralonsoh | there are some bugs that need to be commented here | 14:06 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2007357 | 14:06 |
ralonsoh | ykarel, do you have any update? | 14:06 |
ykarel | ralonsoh, for that i pushed a patch in grenade to catch console log to debug further | 14:06 |
ykarel | https://review.opendev.org/c/openstack/grenade/+/874417 | 14:06 |
ralonsoh | do you have the link? | 14:06 |
ralonsoh | perfect | 14:06 |
ykarel | seems not linked in bug, will update | 14:07 |
ralonsoh | I'll add it to the bug | 14:07 |
ralonsoh | ok, with this patch we'll have more info | 14:07 |
ralonsoh | thanks! | 14:07 |
ralonsoh | next one | 14:08 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2007353 | 14:08 |
ralonsoh | I'll take this one this week | 14:08 |
ralonsoh | it's failing too often | 14:08 |
slaweq | ++ thx | 14:09 |
ralonsoh | next one | 14:09 |
ralonsoh | #topic https://bugs.launchpad.net/neutron/+bug/1934666 | 14:09 |
ralonsoh | this is something slaweq is working on | 14:09 |
ralonsoh | patch: https://review.opendev.org/c/openstack/neutron/+/874536 | 14:09 |
ralonsoh | that used a 3 node set and only the controller is dvr_snat | 14:10 |
ralonsoh | ^^ please review this patch | 14:10 |
slaweq | I'm working only on change for the ci job, not bug itself | 14:10 |
ykarel | k let's link that too to the bug | 14:10 |
slaweq | just to be clear :) | 14:10 |
ralonsoh | yeah but this is the bug itself: that we can't use snat_dvr on computes | 14:10 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config https://review.opendev.org/c/openstack/neutron/+/874536 | 14:10 |
ralonsoh | I'll add this link in the bug too | 14:11 |
ralonsoh | thanks! | 14:11 |
slaweq | ykarel done | 14:11 |
ykarel | thx | 14:11 |
*** dasm|off is now known as dasm | 14:12 | |
ralonsoh | next one | 14:12 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2007414 | 14:12 |
ralonsoh | a low hanging fruit one | 14:12 |
ralonsoh | next one | 14:12 |
ralonsoh | #link https://bugs.launchpad.net/nova/+bug/2006467 | 14:12 |
ralonsoh | ykarel, ^^ | 14:12 |
ralonsoh | any update? | 14:12 |
ralonsoh | is the cirros 0.6.1 image affecting nova-next? | 14:13 |
ykarel | ralonsoh, no cirros 0.6.1 not related there | 14:13 |
ralonsoh | ok | 14:13 |
ykarel | i commented what i found, can you please check based on that comment | 14:13 |
ralonsoh | ok, I'll check last comment this afternoon (I see my name there) | 14:14 |
ykarel | yeap, Thanks | 14:14 |
ralonsoh | cool, next one | 14:14 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2007674 | 14:14 |
ralonsoh | IMO, this could be a RFE | 14:14 |
ralonsoh | good to have but not a bug itself | 14:15 |
ralonsoh | so if you agree, I'll add the RFE tag | 14:15 |
ykarel | i didn't digged much there on why those many connections are opened by openvswitch-agent, | 14:16 |
ykarel | so those are for purpose? | 14:16 |
ralonsoh | we create one per topic | 14:16 |
ralonsoh | ports, sg, networks, etcv | 14:16 |
lajoskatona | We can make it an RFE, but first should be to understand the current situation | 14:16 |
lajoskatona | and what can we cause if we change it | 14:17 |
ralonsoh | agree. To be honest, I don't know if we can't make this change with our current RPC implementation | 14:17 |
ralonsoh | but I didn't spend too much time on this | 14:17 |
lajoskatona | +1 | 14:18 |
ralonsoh | so first thing is to tag it as RFE and then investigate if that is possible | 14:18 |
ykarel | +1 | 14:18 |
ralonsoh | I'll do it after this meeting | 14:18 |
ralonsoh | last one is | 14:19 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2007938 | 14:19 |
ralonsoh | rubasov, ^^ can you check that? | 14:19 |
ralonsoh | did you check this feature with multiple DHCP agents? | 14:19 |
rubasov | yep | 14:19 |
rubasov | probably not | 14:20 |
ralonsoh | because when I have 2, the second one can't spawn the metadata service | 14:20 |
ralonsoh | when 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 |
rubasov | I'll put this on my todo list | 14:21 |
ralonsoh | this is because we can only have one ipv6 metadata IP | 14:21 |
ralonsoh | rubasov, thanks a lot! | 14:21 |
frickler | how is that different with v4? | 14:21 |
rubasov | I have a vague memory that we already had a similar bug, I will check more throughly | 14:22 |
ralonsoh | I would need to check that, yes I remember somethign related | 14:22 |
ralonsoh | I just reproduced this issue and reported the cause | 14:22 |
rubasov | thanks | 14:23 |
frickler | last 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 RFE | 14:23 |
ralonsoh | I think the goal is, as in other agents, to keep the agent functionality without RPC communication | 14:24 |
ralonsoh | but I understand the current implementation | 14:24 |
ralonsoh | to be honest, not having RPC link is a broken env, so the current behaviour is valid | 14:25 |
ralonsoh | I would consider that as a RFE | 14:25 |
frickler | ok, I'd be fine with that. question either way would be who is willing to work on that | 14:25 |
ralonsoh | I'll check if ltomasbo can (or maybe he can point me to someone else) | 14:26 |
frickler | if not, we could also just keep it as wishlist bug | 14:27 |
lajoskatona | can't we ask the reporter if they can work on this? | 14:27 |
ralonsoh | for sure, I'll do it too | 14:27 |
ralonsoh | new Neutron policy: you report, you fix!! | 14:27 |
lajoskatona | agree, if nobody works on it the RFE is still valid, just hangs | 14:28 |
slaweq | :D | 14:28 |
frickler | note to self: stop reporting bugs at once ;) | 14:28 |
lajoskatona | we can be honest that currently nobody has free time for it, if you need it try to fix it :-) | 14:28 |
ralonsoh | exactly | 14:29 |
ralonsoh | ok, any other bug to be discussed? | 14:29 |
ralonsoh | this week bcafarel is the deputy, next week will be lajoskatona | 14:30 |
ralonsoh | let's move to the next topic | 14:30 |
ralonsoh | #topic community_goals | 14:30 |
ralonsoh | 1) Consistent and Secure Default RBAC | 14:30 |
lajoskatona | ralonsoh: ack | 14:31 |
ralonsoh | there are some backports related to RBAC | 14:31 |
ralonsoh | and a new one reported this morning: https://review.opendev.org/c/openstack/neutron/+/874398 | 14:31 |
ralonsoh | slaweq, ^ do we need to backport it to previous releases? | 14:32 |
*** arnau is now known as averdaguer | 14:32 | |
slaweq | that's good question | 14:32 |
slaweq | I didn't propose it to other branches basically because it changes default policies | 14:33 |
slaweq | I don't even know if we should backport it to Zed | 14:33 |
slaweq | especially that new RBACs are still documented as "experimental" in Neutron | 14:33 |
ralonsoh | so this patch should only be in master (actually in bobcat that is when we'll enable sRABC by default) | 14:34 |
ralonsoh | right? | 14:34 |
slaweq | I proposed it to Zed as Zed may have all other fixes too so it should works there | 14:35 |
slaweq | but I'm also fine with abandoning that backport | 14:35 |
slaweq | I just want to hear about others' opinions | 14:35 |
slaweq | I can also backport it to older branches if that's ok for everyone | 14:35 |
ralonsoh | if sRBAC is not available in Zed, that will affect the current policy behaviour | 14:36 |
ralonsoh | so we should not backport it | 14:36 |
frickler | I think mnaser had some interest in getting that to work on zed? | 14:36 |
lajoskatona | if I understand well, I agree | 14:36 |
slaweq | yes, I can try to change that backport to not delete old default policy but maybe modify just new default's part | 14:37 |
lajoskatona | I mean if that is not supported on older branches..... | 14:37 |
ralonsoh | frickler, I would think in other deployments that won't use sRBAC | 14:37 |
ralonsoh | because this is not supported in Zed | 14:37 |
slaweq | starting from 2023.1 we have tempest job which tests new defaults, but in Zed we didn't had it | 14:37 |
ralonsoh | that's the point | 14:38 |
slaweq | we may propose that job to Zed also and backport all to Zed | 14:38 |
slaweq | but I'm not sure if we should go to older branches too | 14:38 |
ralonsoh | this is a community effort | 14:38 |
frickler | maybe leaving zed backports to interested downstreams would be fine, too | 14:38 |
ralonsoh | sRBAC is not supported in Zed | 14:38 |
lajoskatona | frickler: +1 | 14:39 |
ralonsoh | slaweq, I would check that with gmann but he +1 this patch | 14:39 |
slaweq | ok, I will discuss it with gmann | 14:40 |
ralonsoh | thanks, please ping us with the conclusion | 14:40 |
slaweq | sure | 14:41 |
ralonsoh | and this is all I have in this topic, so let's move to the next one | 14:41 |
ralonsoh | #topic on_demand | 14:41 |
ralonsoh | I have nothing in the agenda | 14:41 |
ralonsoh | please present your topics | 14:41 |
slaweq | just one thing/reminder | 14:41 |
slaweq | I saw email that this week is deadline for cycle highlights | 14:42 |
ralonsoh | yes, I'm doing it now | 14:42 |
slaweq | ahh, great | 14:42 |
slaweq | thx | 14:42 |
slaweq | so that's all from me | 14:42 |
slaweq | :) | 14:42 |
ralonsoh | I'll ping all of you with the patch to add any comment | 14:42 |
slaweq | ++ | 14:42 |
lajoskatona | thanks | 14:42 |
ralonsoh | remember the CI meeting is in 15 mins (today on video) | 14:43 |
ralonsoh | thank you all for attending | 14:43 |
slaweq | yep | 14:44 |
ralonsoh | #endmeeting | 14:44 |
opendevmeet | Meeting ended Tue Feb 21 14:44:06 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:44 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.html | 14:44 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.txt | 14:44 |
opendevmeet | Log: https://meetings.opendev.org/meetings/networking/2023/networking.2023-02-21-14.00.log.html | 14:44 |
slaweq | o/ | 14:44 |
lajoskatona | o/ | 14:44 |
isabek | o/ | 14:44 |
ralonsoh | see you in 15 mins | 14:44 |
ykarel | o/ | 14:45 |
mnaser | hi guys, we are using zed and have it enabled for a bunch of services and neutron is the only missing piece | 14:45 |
mnaser | (for secure rbac) | 14:45 |
mnaser | i would not mind being the person who has to cherry-pick things if we run into breakages | 14:46 |
mnaser | since we are trying to run zed with secure rbac (and we actually have users that are using the 'reader' role) | 14:47 |
ralonsoh | this is being discussed now. Zed does not support sRBAC yet and slaweq is checking if this patch in particular can be backported | 14:50 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Improve "sync_ha_chassis_group" method https://review.opendev.org/c/openstack/neutron/+/872023 | 14:50 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP - Add ``OVNGatewayHAChassisGroup`` scheduler class https://review.opendev.org/c/openstack/neutron/+/872033 | 14:50 |
slaweq | mnaser the problematic backport is https://review.opendev.org/q/I5fe4a0134c6ecf5cf28e2f5d59411134546c98b0 as this changes default config value | 14:51 |
slaweq | I will look into this and will try to maybe change it a bit to not change old policy | 14:51 |
mnaser | slaweq: oh, because the fix assumes that enforce_scope will be permenantly on in since it is in master? | 14:52 |
slaweq | ralonsoh 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 |
slaweq | mnaser it's not on by default yet | 14:53 |
slaweq | we plan to do it in next cycle | 14:53 |
slaweq | but since few weeks we have CI job which is testing those new default policies so IMO we can say it's now supported officially | 14:54 |
ralonsoh | slaweq, if you remove this rule, shouldn't apply the get_network one? | 14:54 |
slaweq | ralonsoh and that ^^ may be good candidate for cycle highlights too :) | 14:54 |
ralonsoh | yes, sRBAC for sure | 14:55 |
slaweq | ralonsoh no, this rule is about who can see "router:external" attribute in network | 14:55 |
slaweq | not about who can show network with router:external=True | 14:55 |
slaweq | so basically attribute "router:external" should be visible for everyone | 14:56 |
ralonsoh | yeah, I mean | 14:56 |
ralonsoh | you should be able to see the parameter if you can see this network | 14:56 |
slaweq | exactly and that behaviour won't change with this backport | 14:56 |
ralonsoh | perfect then | 14:56 |
ralonsoh | so I think is backportable | 14:56 |
slaweq | yes, I think so as well now as we are discussing about it | 14:57 |
slaweq | #startmeeting neutron_ci | 15:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
opendevmeet | The meeting name has been set to 'neutron_ci' | 15:00 |
slaweq | bcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva is starting now | 15:00 |
slaweq | This will be video meeting this time: https://meetpad.opendev.org/neutron-ci-meetings | 15:00 |
lajoskatona | o/ | 15:02 |
slaweq | #link https://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=1 | 15:02 |
slaweq | #topic Actions from previous meetings | 15:02 |
slaweq | lajoskatona to continue checking dvr functional tests issues | 15:03 |
lajoskatona | https://review.opendev.org/c/openstack/neutron/+/873111 | 15:03 |
lajoskatona | https://zuul.opendev.org/t/openstack/status#873111 | 15:04 |
slaweq | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_594/874167/3/check/neutron-fullstack-with-uwsgi/5943274/testr_results.html | 15:05 |
slaweq | #action lajoskatona to continue checking dvr functional tests issues | 15:07 |
slaweq | ralonsoh to try to store journal log in UT job's results to debug "no such table" issues | 15:07 |
slaweq | slaweq to report bug about failed to bind LRP in functional tests | 15:08 |
slaweq | https://bugs.launchpad.net/neutron/+bug/2007353 | 15:08 |
slaweq | lajoskatona to talk with zhouhenglc about fwaas jobs issues | 15:09 |
slaweq | slaweq to report bug with failed ping in grenade jobs | 15:10 |
slaweq | Bug: https://bugs.launchpad.net/neutron/+bug/2007357 | 15:10 |
lajoskatona | https://review.opendev.org/c/openstack/grenade/+/874417 | 15:10 |
ozzzo_work | I'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_work | How can I extend the timeout? | 15:12 |
slaweq | ykarel to fix grenade random fails pcp installation | 15:12 |
ozzzo_work | I can pull the list via CLI no problem;; apparently CLI uses a longer timeout | 15:12 |
slaweq | #topic Stadium projects | 15:12 |
slaweq | #topic Grafana | 15:13 |
slaweq | #topic Rechecks | 15:15 |
slaweq | +---------+----------+... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/zGdkCHJPJcPaKOFRsHSnkNhR>) | 15:15 |
slaweq | https://review.opendev.org/c/openstack/neutron/+/873247 | 15:16 |
slaweq | #topic Unit tests | 15:18 |
slaweq | https://bugs.launchpad.net/neutron/+bug/2007254 | 15:18 |
slaweq | #topic fullstack/functional | 15:18 |
slaweq | https://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.html | 15:19 |
ozzzo_work | Should I try a different channel? Where's the best place to ask about the API? | 15:20 |
slaweq | https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_978/periodic/opendev.org/openstack/neutron/master/neutron-functional/9789c89/testr_results.html | 15:20 |
ralonsoh | ozzzo_work, we are in a meeting now | 15:20 |
ozzzo_work | oic ok | 15:21 |
slaweq | https://64e9807acd80d4cab1ab-851182d93d98b3728f798963c90c7371.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-uwsgi-fips/1914083/testr_results.html | 15: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.html | 15:22 |
slaweq | https://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.html | 15:22 |
slaweq | #topic Tempest/Scenario | 15:23 |
slaweq | https://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.html | 15:23 |
slaweq | https://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.html | 15:23 |
slaweq | https://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.html | 15:23 |
slaweq | #action slaweq to report bug about macspoofing_port test in ovn-tempest-slow job | 15:25 |
slaweq | #topic Periodic | 15:25 |
slaweq | neutron-functional-with-sqlalchemy-master | 15:25 |
slaweq | #action ralonsoh to check neutron-functional-with-sqlalchemy-master failures | 15:27 |
slaweq | #topic On Demand | 15: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 it | 15:28 |
ralonsoh | one quick topic: #link https://bugs.launchpad.net/neutron/+bug/2007986 | 15:30 |
ralonsoh | https://review.opendev.org/c/openstack/tempest/+/873055 | 15:30 |
slaweq | https://github.com/openstack/neutron-tempest-plugin/blob/master/zuul.d/wallaby_jobs.yaml | 15:33 |
slaweq | https://github.com/openstack/neutron-tempest-plugin/blob/1.8.0/zuul.d/rocky_jobs.yaml#L120 | 15:35 |
ykarel | https://review.opendev.org/c/openstack/devstack/+/871782 | 15:36 |
ykarel | https://zuul.openstack.org/builds?job_name=tempest-full-py3&branch=stable%2Fwallaby&skip=0 | 15:36 |
opendevreview | Lajos Katona proposed openstack/python-neutronclient master: OSC: Remove BGP calls to neutronclient https://review.opendev.org/c/openstack/python-neutronclient/+/868321 | 15:36 |
opendevreview | Fernando 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/+/874609 | 15:41 |
opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/zed: Reduce coverage threshold on stable branches https://review.opendev.org/c/openstack/ovn-octavia-provider/+/874426 | 16:01 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Format correctly (dialect=mac_unix_expanded) the MAC addresses https://review.opendev.org/c/openstack/neutron/+/874654 | 16:11 |
opendevreview | Fernando 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/+/874609 | 16:14 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Check port.tag is not DEAD_VLAN_TAG in ``DHCPAgentOVSTestFramework`` https://review.opendev.org/c/openstack/neutron/+/874658 | 16:24 |
*** sean-k-mooney1 is now known as sean-k-mooney | 16:25 | |
opendevreview | Maurice Escher proposed openstack/neutron master: ml2 plugin: use const from neutron-lib https://review.opendev.org/c/openstack/neutron/+/874631 | 17:16 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: DNM WIP remove FT OVN workaround for sqlite https://review.opendev.org/c/openstack/neutron/+/874669 | 17:16 |
ozzzo_work | Is the meeting over now? Does anyone have any ideas on my API question? | 17:40 |
ozzzo_work | I'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 | 17:40 |
ralonsoh | ozzzo_work, what is the unified python API? | 17:46 |
ralonsoh | do you mean you are using the SDK bindings | 17:46 |
ralonsoh | how are you calling this method? | 17:47 |
ozzzo_work | yes sdk | 17:54 |
ralonsoh | and what client is using it? | 17:55 |
ozzzo_work | https://paste.openstack.org/show/bVPEmD2n75LhMfqBaf6e/ | 17:56 |
ozzzo_work | I think I need to increase the timeout value | 17:58 |
ozzzo_work | Looking here: https://docs.openstack.org/openstacksdk/latest/user/proxies/network.html | 18:02 |
ozzzo_work | But it doesn't mention the timeout value. | 18:03 |
ralonsoh | ozzzo_work, in the "register_argparse_arguments", when creating the connect object | 18:08 |
ralonsoh | there is a mention to --timeout | 18:08 |
ralonsoh | what I don't know is how to build this "options" object (that seems to be an ArgumentParser | 18:08 |
ozzzo_work | where do you see --timeout? | 18:10 |
ralonsoh | https://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L755 | 18:13 |
ralonsoh | do this | 18:13 |
ralonsoh | https://paste.opendev.org/show/b3E6bv7jQEaRQzSwTePW/ | 18:13 |
ralonsoh | and when calling this script, pass an input argument | 18:13 |
ralonsoh | ./script.py --timeout=1000 | 18:13 |
ralonsoh | if you check "options" in https://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L770 | 18:14 |
ralonsoh | you'll see that the input argument has been read | 18:14 |
ozzzo_work | ok I'll try that, ty! | 18:17 |
gmann | ralonsoh: RE on https://review.opendev.org/c/openstack/tempest/+/764226/2/zuul.d/base.yaml#22 | 18:24 |
gmann | ralonsoh: basically it count the minimum compute node and set in tempest conf so that we can decide on mulitnode test to be skipped or run | 18:24 |
gmann | example https://github.com/openstack/tempest/blob/1569290be06e61d63061ae35a997aff0ebad68f1/tempest/api/compute/admin/test_live_migration.py#L47 | 18:25 |
gmann | ralonsoh: basically it count the number of compute defined in jobs, for example in base job https://github.com/openstack/devstack/blob/e5c8e2951f8eed2d618bcb7c1d99adddeca4fffe/.zuul.yaml#L128 | 18:28 |
gmann | ralonsoh: 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 |
gmann | basically 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 |
gmann | otherwise 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 |
gmann | I like to slaweq idea of backporting only new RBAC rule and do not remove the old policy rule in zed backport | 18:35 |
gmann | ralonsoh: 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 |
gmann | ralonsoh: 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#b204 | 18:41 |
lajoskatona | gmann: thanks for background | 18:50 |
lajoskatona | gmann, ralonsoh, slaweq: should we discuss this perhaps on Friday during the drivers meeting? | 18:51 |
*** dasm is now known as dasm|off | 19:56 | |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: Change neutron-ovs-tempest-dvr-ha-multinode-full job's config https://review.opendev.org/c/openstack/neutron/+/874536 | 21:20 |
opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Add release note about full support for new policies https://review.opendev.org/c/openstack/neutron/+/874706 | 21:35 |
opendevreview | Merged openstack/neutron stable/victoria: Improve scheduling L3/DHCP agents, missing lower binding indexes https://review.opendev.org/c/openstack/neutron/+/873628 | 21:42 |
opendevreview | Slawek 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/+/874709 | 21:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!