January 2023 - openstack-discuss - lists.openstack.org

[neutron][kolla] Do neutron agents in compute nodes connect to neutron database ?
by ZAOUAM Soufian (EXT) 31 Jan '23

31 Jan '23

Hi all, Do neutron agents in compute nodes have to connect to neutron database ? We are maintaining an Openstack using kolla-ansible (ussuri version). We noticed that the 4 neutron agents on compute nodes: neutron-l3-agent, neutron-metadata-agent, neutron-openvswitch-agent, neutron-dhcp-agent are all using the same neutron.conf config file, but we are wondering if they actually use [database] or is it redundant ? If no, is it safe to remove the [database] section from the neutron.conf for these agents? Best regards, ========================================================= Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential, intended solely for the addresses, and may contain legally privileged information. Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. =========================================================

2 1

[all][elections][ptl][tc] Combined PTL/TC bugbear cycle Election Season
by Ian Y. Choi 30 Jan '23

30 Jan '23

Election details: https://governance.openstack.org/election/ The nomination period officially begins Feb 01, 2023 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/election/#election-officials

1 1

[cinder][requirements] python-cinderclient Yoga gate broken due to rtslib-fb
by Rajat Dhasmana 30 Jan '23

30 Jan '23

Hello, Currently python-cinderclient yoga gate is broken because *python-cinderclient-functional-py39* job is failing. Upon looking into the logs, I found the *cinder-rtstool delete *command failing[1]. Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf cinder-rtstool delete iqn.2010-10.org.openstack:volume-095ce534-8ef7-45c8-867c-f6d4fbc2b02d Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Exit code: 1 Jan 16 07:58:14.935519 np0032740756 cinder-volume[115744]: ERROR cinder.volume.targets.lio Stdout: '' Looking further into the traceback, this seems to be the main issue. line 215, in _gen_attached_luns\n for tpgt_dir in listdir(tpgts_base):\nNotADirectoryError: [Errno 20] Not a directory: \'/sys/kernel/config/target/iscsi/cpus_allowed_list\'\n' I found a similar (not exact) error in thread[2] to which there was a reply that it was fixed[3]. The fix is included in version 2.1.75[4] but the version pinned in upper constraints for yoga is 2.1.74[5]. I've tested the version bump in these DNM patches[6][7] and it works. A quick code search reveals that cinder is the only project actively using this lib[8]. My question for the requirements team is, is it OK to bump the requirement to allow cinderclient yoga gate to pass since it's blocking backports? [1] https://zuul.opendev.org/t/openstack/build/a282bfbb6b0a4148a69694db6ab7eb69… [2] https://www.spinics.net/lists/linux-scsi/msg172264.html [3] https://www.spinics.net/lists/linux-scsi/msg172265.html [4] https://github.com/open-iscsi/rtslib-fb/commit/8d2543c4da62e962661011fea5b1… [5] https://github.com/openstack/requirements/blob/stable/yoga/upper-constraint… [6] https://review.opendev.org/c/openstack/python-cinderclient/+/870513 [7] https://review.opendev.org/c/openstack/requirements/+/870714 [8] https://codesearch.opendev.org/?q=rtslib-fb&i=nope&literal=nope&files=&excl… Thanks Rajat Dhasmana

2 2

[Keystone | python-openstackclient] Fedartion with OAuth2.0/OIDC
by Niklas Schwarz 30 Jan '23

30 Jan '23

Hey there, I'm currently investigating the features of openstack federated identity and oauth2/oidc with keycloak as an identity provider. Following the documentation [1] I have successfully deployed a setup where it is possible to login via the horizion board using the login of keycloak. As defined in the documentation I'm using apache2 with the mod_auth_openidc module. So far so good... If I try to access the api via the openstack-cli using the following configuration ``` OS_AUTH_URL=https://<openstack-ip>/identity/v3 OS_AUTH_TYPE=v3oidcpassword OS_IDENTITY_PROVIDER=keycloak OS_PROTOCOL=openid OS_USERNAME=<keycloak-user> OS_PASSWORD=<keycloak-password> OS_PROJECT=test OS_OPENID_SCOPE='openid email profile' OS_DISCOVERY_ENDPOINT=https:// <keycloak-ip>/realms/<realm>/.well-known/openid-configuration OS_ACCESS_TOKEN_TYPE=access_token OS_CLIENT_ID=<client-id> OS_CLIENT_SECRET=<client-secret> ``` the http-status-code of the server is 500. Inspecting the logs , I found the problem in the mod_auth_openidc modul which expects a content-type of application/x-www-form-urlencoded. Is there any way to change the content-type the openstack-cli from json to urlencoded or am I missing a step in the configuration or something else? Thanks in advanced Niklas [1] https://docs.openstack.org/keystone/zed/admin/federation/configure_federati…

1 0

[Neutron] Bug Deputy Report January 23 - 29
by Oleg Bondarev 30 Jan '23

30 Jan '23

Hello Neutron Team, Bug report for the week of Jan 23 is below: *High:* - https://bugs.launchpad.net/neutron/+bug/2004012 - [Secure RBAC] Delete port on own network which is shared with other project is not possible Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004015 - [Secure RBAC] Sharing Security groups don't works with new RBAC policies Edit Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004014 - [Secure RBAC] Sharing QoS Policies don't works with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004013 - [Secure RBAC] List QoS Policies filtered by tags is not possible with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004017 - [Secure RBAC] List flavors don't work for regular user with new RBAC policies Confirmed Unassigned - https://bugs.launchpad.net/neutron/+bug/2004016 - [Secure RBAC] Cleaning shared networks fails with new RBAC policies Confirmed Unassigned *Medium:* - https://bugs.launchpad.net/neutron/+bug/2003706 - [OVN] Security group logging only logs half of the connection In progress: https://review.opendev.org/c/openstack/neutron/+/871096 Assigned to elvira - https://bugs.launchpad.net/neutron/+bug/2003842 - [OVN] A route inferred from a subnet's default gateway is not added to ovn-nb if segment_id is not None for a subnet Invalid Unassigned - https://bugs.launchpad.net/neutron/+bug/2004004 - keepalived virtual_routes wrong order Triaged Unassigned - https://bugs.launchpad.net/neutron/+bug/2003997 - [ovn-octavia-provider] ovn-lb with VIP on provider network not working In progress Assigned to ltomasbo *Low:* - https://bugs.launchpad.net/neutron/+bug/2003861 - Remove the CLI code from python-neutronclient Triaged Assigned to ralonsoh - https://bugs.launchpad.net/neutron/+bug/2003999 - Stateleful SG API extension should be disabled when old OVN is used In progres: https://review.opendev.org/c/openstack/neutron/+/871982, https://review.opendev.org/c/openstack/neutron/+/871983s Assigned to slaweq *Undecided:* - https://bugs.launchpad.net/neutron/+bug/2004041 - Missing flows with ovs dvr after openvswitch restart Incomplete: more info requested Unassigned Thanks, Oleg

1 0

hacluster_corosync container stuck in restarting
by Karera Tony 30 Jan '23

30 Jan '23

Dear Team, I installed Openstack Wallaby using kolla-ansible. Everything is fine except for the hacluster_corosync container stuck in restarting. Below are the corosync logs. Has anyone faced this issue before ? I have two controllers but this issue is on happening on one Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:19:42 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:19:42 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:19:42 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:19:42 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:19:42 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:19:42 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:20:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:20:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:20:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:20:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:20:43 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:20:43 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:20:43 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:20:43 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:20:43 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:20:43 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:21:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:21:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:21:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:21:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:21:44 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:21:44 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:21:44 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:21:44 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:21:44 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:21:44 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Regards Regards Tony Karera

1 0

hacluster_corosync container stuck in restarting
by Karera Tony 29 Jan '23

29 Jan '23

Dear Team, I installed Openstack Wallaby using kolla-ansible. Everything is fine except for hacluster_corosync container stuck in restarting. Below are the corosync logs. Has anyone faced this issue before ? Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:19:42 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:19:42 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:19:42 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:19:42 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:19:42 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:19:42 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:19:42 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:19:42 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:20:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:20:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:20:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:20:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:20:43 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:20:43 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:20:43 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:20:43 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:20:43 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:20:43 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:20:43 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:20:43 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Jan 30 08:21:43 [7] controller1 corosync notice [MAIN ] Corosync Cluster Engine 3.0.3 starting up Jan 30 08:21:43 [7] controller1 corosync info [MAIN ] Corosync built-in features: dbus monitoring watchdog augeas systemd xmlconf vqsim nozzle snmp pie relro bindnow Jan 30 08:21:43 [7] controller1 corosync warning [MAIN ] Could not increase RLIMIT_MEMLOCK, not locking memory: Operation not permitted (1) Jan 30 08:21:43 [7] controller1 corosync notice [TOTEM ] Initializing transport (Kronosnet). Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] kronosnet crypto initialized: aes256/sha384 Jan 30 08:21:44 [7] controller1 corosync info [TOTEM ] totemknet initialized Jan 30 08:21:44 [7] controller1 corosync info [KNET ] common: crypto_nss.so has been loaded from /usr/lib/x86_64-linux-gnu/kronosnet/crypto_nss.so Jan 30 08:21:44 [7] controller1 corosync notice [SERV ] Service engine loaded: corosync configuration map access [0] Jan 30 08:21:44 [7] controller1 corosync info [QB ] server name: cmap Jan 30 08:21:44 [7] controller1 corosync error [QB ] Could not bind AF_UNIX (): Address already in use (98) Jan 30 08:21:44 [7] controller1 corosync info [QB ] withdrawing server sockets Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Can't initialize IPC Jan 30 08:21:44 [7] controller1 corosync error [SERV ] Service engine 'corosync_cmap' failed to load for reason 'qb_ipcs_run error' Jan 30 08:21:44 [7] controller1 corosync error [MAIN ] Corosync Cluster Engine exiting with status 20 at service.c:356. Regards Tony Karera

1 0

Re: [all][stable][ptl] Propose to EOL Rocky series
by Thomas Goirand 28 Jan '23

28 Jan '23

Hi, I understand the gate is broken, however, Rocky is in Debian LTS, and I would like to keep the possibility to merge patches, even with the gate tests disabled. CVE-2022-47951 is an example why this is important... Thomas Goirand (zigo) On Jan 28, 2023 11:54, Radosław Piliszek <radoslaw.piliszek(a)gmail.com> wrote: > > Masakari is happy to EOL Rocky too. > > Radek > -yoctozepto > > On Fri, 27 Jan 2023 at 20:59, Jay Faulkner <jay(a)gr-oss.io> wrote: > > > > Thanks for doing all this cleanup work Elod. Ironic is OK with retirements of these shared resources up to Train. > > > > - > > Jay Faulkner > > > > On Fri, Jan 27, 2023 at 10:12 AM Elõd Illés <elod.illes(a)est.tech> wrote: > >> > >> Hi, > >> > >> Similarly like the Queens branch EOL proposal [1] I would like to propose > >> to transition every project's stable/rocky to End of Life: > >> > >> - gates are mostly broken > >> - minimal number of activity can be seen on this branch > >> - some core projects already transitioned their stable/rocky to EOL > >> recently (like ironic, neutron, nova) > >> - gate job definitions are still using the old, legacy zuul syntax > >> - gate jobs are based on Ubuntu Xenial, which is also beyond its public > >> maintenance window date and hard to maintain > >> > >> Based on the above, if there won't be any project who wants to keep open > >> their stable/rocky, then I'll start the process of EOL'ing Rocky stable > >> series as a whole. If anyone has any objection then please respond to > >> this mail. > >> > >> Thanks, > >> > >> Előd Illés > >> irc: elodilles @ #openstack-stable / #openstack-release > >> > >> [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/031030… > >> >

1 0

Pulling plugins from my Github repository
by vincent lee 27 Jan '23

27 Jan '23

Hi everyone, I would like to know where exactly I can replace the path for the GitHub repository. For example, I want to pull some plugins, such as zun_ui, blazar_dashboard, etc., from my own GitHub repository instead of the default GitHub repository. I am currently using Kolla-ansible for deploying OpenStack in the yoga version. Best, Vincent

1 0

[all][tc] What's happening in Technical Committee: summary 2023 Jan 27: Reading: 5 min
by Ghanshyam Mann 27 Jan '23

27 Jan '23

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Jan 25. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2023/tc.2023-01-25-16.00.log.html * The next TC weekly meeting will be on Feb 1 Wed at 16:00 UTC, Feel free to add the topic to the agenda[1] by Jan 31. 2. What we completed this week: ========================= * Added Axel to Mistral project DPL list[2] * Remaining two projects (Mistral and Zaqar) which were less active (their release was in question) are green and active now. Their beta releases are also completed[3][4][5][6]. 3. Activities In progress: ================== TC Tracker for the 2023.1 cycle ------------------------------------- * Current cycle working items and their progress are present in the 2023.1 tracker etherpad[7]. Open Reviews ----------------- * Two open reviews for ongoing activities[8]. Cleanup of PyPI maintainer list for OpenStack Projects ---------------------------------------------------------------- The audit process is going on and a few projects have been completed [9]. There is a discussion also going on in ML[10]. The TC discussed it in this week's meeting also and no change in the initial plan for the cleanup of additional PyPi maintainers. The process to find the less active projects early in the cycle: ------------------------------------------------------------------------ I think in every cycle we get some less active projects and that is too little late in the cycle which adds extra work for the release team to release such projects. We discussed in PTG that TC should come up with some process to find such less active projects a little early in the cycle. JayF started the etherpad to collect the data and define the criteria to help in this process[11]. Project updates ------------------- * Add Cinder Huawei charm[12] * Add the woodpecker charm to Openstack charms[13] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [15] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggesti… [2] https://review.opendev.org/c/openstack/governance/+/871302 [3] https://review.opendev.org/c/openstack/releases/+/869470 [4] https://review.opendev.org/c/openstack/releases/+/869448 [5] https://review.opendev.org/c/openstack/zaqar/+/857924 [6] https://review.opendev.org/c/openstack/releases/+/871399 [7] https://etherpad.opendev.org/p/tc-2023.1-tracker [8] https://review.opendev.org/q/projects:openstack/governance+status:open [9] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup [10] https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848… [11] https://etherpad.opendev.org/p/project-health-check [12] https://review.opendev.org/c/openstack/governance/+/867588 [13] https://review.opendev.org/c/openstack/governance/+/869752 [14] hhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0