15:00:28 #startmeeting neutron_ci 15:00:28 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:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 The meeting name has been set to 'neutron_ci' 15:00:30 bcafarel, lajoskatona, mlavalle, mtomaska, ralonsoh, ykarel, jlibosva is starting now 15:00:31 This will be video meeting this time: https://meetpad.opendev.org/neutron-ci-meetings 15:02:11 o/ 15:02:53 #link https://grafana.opendev.org/d/f913631585/neutron-failure-rate?orgId=1 15:02:58 #topic Actions from previous meetings 15:03:03 lajoskatona to continue checking dvr functional tests issues 15:03:50 https://review.opendev.org/c/openstack/neutron/+/873111 15:04:05 https://zuul.opendev.org/t/openstack/status#873111 15:05:57 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:07:04 #action lajoskatona to continue checking dvr functional tests issues 15:07:14 ralonsoh to try to store journal log in UT job's results to debug "no such table" issues 15:08:42 slaweq to report bug about failed to bind LRP in functional tests 15:08:48 https://bugs.launchpad.net/neutron/+bug/2007353 15:09:07 lajoskatona to talk with zhouhenglc about fwaas jobs issues 15:10:02 slaweq to report bug with failed ping in grenade jobs 15:10:08 Bug: https://bugs.launchpad.net/neutron/+bug/2007357 15:10:59 https://review.opendev.org/c/openstack/grenade/+/874417 15:11:45 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:12:00 How can I extend the timeout? 15:12:06 ykarel to fix grenade random fails pcp installation 15:12:14 I can pull the list via CLI no problem;; apparently CLI uses a longer timeout 15:12:17 #topic Stadium projects 15:13:59 #topic Grafana 15:15:23 #topic Rechecks 15:15:32 +---------+----------+... (full message at ) 15:16:00 https://review.opendev.org/c/openstack/neutron/+/873247 15:18:10 #topic Unit tests 15:18:24 https://bugs.launchpad.net/neutron/+bug/2007254 15:18:51 #topic fullstack/functional 15:19:09 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:20:02 Should I try a different channel? Where's the best place to ask about the API? 15:20:29 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:36 ozzzo_work, we are in a meeting now 15:21:21 oic ok 15:21:39 https://64e9807acd80d4cab1ab-851182d93d98b3728f798963c90c7371.ssl.cf5.rackcdn.com/periodic/opendev.org/openstack/neutron/master/neutron-functional-with-uwsgi-fips/1914083/testr_results.html 15:22:11 #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:40 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:02 #topic Tempest/Scenario 15:23:12 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:47 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:54 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:25:18 #action slaweq to report bug about macspoofing_port test in ovn-tempest-slow job 15:25:24 #topic Periodic 15:25:39 neutron-functional-with-sqlalchemy-master 15:27:52 #action ralonsoh to check neutron-functional-with-sqlalchemy-master failures 15:28:09 #topic On Demand 15:28:16 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:30:04 one quick topic: #link https://bugs.launchpad.net/neutron/+bug/2007986 15:30:12 https://review.opendev.org/c/openstack/tempest/+/873055 15:33:11 https://github.com/openstack/neutron-tempest-plugin/blob/master/zuul.d/wallaby_jobs.yaml 15:35:12 https://github.com/openstack/neutron-tempest-plugin/blob/1.8.0/zuul.d/rocky_jobs.yaml#L120 15:36:04 https://review.opendev.org/c/openstack/devstack/+/871782 15:36:29 https://zuul.openstack.org/builds?job_name=tempest-full-py3&branch=stable%2Fwallaby&skip=0 15:36:45 Lajos Katona proposed openstack/python-neutronclient master: OSC: Remove BGP calls to neutronclient https://review.opendev.org/c/openstack/python-neutronclient/+/868321 15:41:53 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 16:01:50 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:11:02 Rodolfo Alonso proposed openstack/neutron master: Format correctly (dialect=mac_unix_expanded) the MAC addresses https://review.opendev.org/c/openstack/neutron/+/874654 16:14:59 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:24:50 Rodolfo Alonso proposed openstack/neutron master: Check port.tag is not DEAD_VLAN_TAG in ``DHCPAgentOVSTestFramework`` https://review.opendev.org/c/openstack/neutron/+/874658 17:16:01 Maurice Escher proposed openstack/neutron master: ml2 plugin: use const from neutron-lib https://review.opendev.org/c/openstack/neutron/+/874631 17:16:25 Rodolfo Alonso proposed openstack/neutron master: DNM WIP remove FT OVN workaround for sqlite https://review.opendev.org/c/openstack/neutron/+/874669 17:40:22 Is the meeting over now? Does anyone have any ideas on my API question? 17:40:53 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:46:49 ozzzo_work, what is the unified python API? 17:46:59 do you mean you are using the SDK bindings 17:47:12 how are you calling this method? 17:54:10 yes sdk 17:55:33 and what client is using it? 17:56:29 https://paste.openstack.org/show/bVPEmD2n75LhMfqBaf6e/ 17:58:50 I think I need to increase the timeout value 18:02:40 Looking here: https://docs.openstack.org/openstacksdk/latest/user/proxies/network.html 18:03:05 But it doesn't mention the timeout value. 18:08:16 ozzzo_work, in the "register_argparse_arguments", when creating the connect object 18:08:24 there is a mention to --timeout 18:08:58 what I don't know is how to build this "options" object (that seems to be an ArgumentParser 18:10:54 where do you see --timeout? 18:13:12 https://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L755 18:13:17 do this 18:13:31 https://paste.opendev.org/show/b3E6bv7jQEaRQzSwTePW/ 18:13:44 and when calling this script, pass an input argument 18:13:54 ./script.py --timeout=1000 18:14:18 if you check "options" in https://github.com/openstack/openstacksdk/blob/master/openstack/config/loader.py#L770 18:14:31 you'll see that the input argument has been read 18:17:17 ok I'll try that, ty! 18:24:00 ralonsoh: RE on https://review.opendev.org/c/openstack/tempest/+/764226/2/zuul.d/base.yaml#22 18:24:40 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:25:12 example https://github.com/openstack/tempest/blob/1569290be06e61d63061ae35a997aff0ebad68f1/tempest/api/compute/admin/test_live_migration.py#L47 18:28:46 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:31:35 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:33:56 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:56 - 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:56 - in operator upgrading from zed to 2023.1, get those new RBAC as default so no surprise to them. 18:34:38 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:35:04 I like to slaweq idea of backporting only new RBAC rule and do not remove the old policy rule in zed backport 18:37:49 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:41:51 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:50:50 gmann: thanks for background 18:51:23 gmann, ralonsoh, slaweq: should we discuss this perhaps on Friday during the drivers meeting? 21:20:21 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:35:58 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:42:16 Merged openstack/neutron stable/victoria: Improve scheduling L3/DHCP agents, missing lower binding indexes https://review.opendev.org/c/openstack/neutron/+/873628 21:44:49 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 02:10:19 Merged openstack/neutron-tempest-plugin master: [Secure RBAC] Add scope enforcement enabled job for master branch https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/867518 07:30:13 lajoskatona, gmann I don't think this friday is a good day, we all have PTO in Red Hat 07:30:22 but let me check that first 07:30:59 in any case, I've talked to slaweq and he is in favor of backporting all these patches 07:31:09 including the router:external one 07:32:15 if the plan is to support sRBAC in Zed to make the transition to A with full support, I'm in favor of this 07:59:22 ralonsoh: ack, anyway, let's discuss this to have a common understanding, I think next week is good also 08:00:45 ralonsoh: I am fine with it, my concern is only that yesterday we agreed the other way and perhaps there are more background which we forgot yesterday and considering those the team will agree to do the backport 08:13:31 lajoskatona, sure, let's discuss first during the next team meeting 08:19:06 Hi, yesterday I proposed to have this "new-policies" job also for stable/zed 08:19:28 I will update the router:external patch today to not remove old rule but maybe just change the new one somehow 08:20:07 but still I think that if there is no rule at all, it will work as "RULE_ANY" so default behaviour of this get network:router:external shouldn't change IMO 08:20:59 I think we can keep the patch as is now 08:21:32 about the RBAC backport, we'll have a new discussing next tuesday 08:21:53 ++ 08:24:05 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 08:24:40 Slawek Kaplonski proposed openstack/neutron stable/zed: Remove policy rule for get_network:router:external https://review.opendev.org/c/openstack/neutron/+/874398 08:25:30 Slawek Kaplonski proposed openstack/neutron master: Set DVR qr-xyz interfaces DOWN on backup node https://review.opendev.org/c/openstack/neutron/+/869741 08:26:21 Slawek Kaplonski proposed openstack/neutron master: Set DVR qr-xyz interfaces DOWN on backup node https://review.opendev.org/c/openstack/neutron/+/869741 08:26:31 Slawek Kaplonski proposed openstack/neutron master: Set DVR qr-xyz interfaces DOWN on backup node https://review.opendev.org/c/openstack/neutron/+/869741 08:26:51 ralonsoh lajoskatona patch https://review.opendev.org/c/openstack/neutron/+/874536 seems to be fine now and I just proposed https://review.opendev.org/c/openstack/neutron/+/869741 on top of this mine patch to check if this dvr job will now be fine really 08:27:59 cool, let me check your patch 08:28:05 thx 08:38:37 +1 08:48:19 #endmeeting