February 2025 - openstack-discuss

[i18n][infra][horizon] Zanata translation job failures after Python 3.8 deprecation
by Ian Y. Choi 09 Jul '25

09 Jul '25

Hi all, During last week's PTG, the I18n SIG identified Zanata translation job failures for Horizon (and likely related plugins). The root cause appears to be Python 3.8 deprecation on Horizon [1]. Failed jobs have been observed on Zuul [2], and translation proposals were made on Gerrit [3]. Since translation sync on Horizon stable branches is functioning correctly, the error message seems to be related to Python 3.8 deprecation: ERROR: Cannot install -r doc/requirements.txt (line 3) due to conflicting package version dependencies. To address this, I'd like to raise two points: 1/ To resolve the issue, would you support updating translation sync jobs with Bionic-based Zuul jobs by either upgrading to Jammy or modifying the Bionic image to support Python >3.8? 2/ At least me from I18n SIG acknowledges that recognizing these translation job errors was delayed. Moving forward, would it be beneficial to implement periodic (e.g., monthly) reporting on translation job successes and failures? Thank you, /Ian [1] https://docs.openstack.org/releasenotes/horizon/2024.2.html#upgrade-notes [2] https://zuul.opendev.org/t/openstack/builds?job_name=propose-translation-up… [3] https://review.opendev.org/q/owner:proposal-bot+project:openstack/horizon+b…

2 3

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 24 Jun '25

24 Jun '25

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

2 3

Problems with the Placement service
by Ron Gage 24 Jun '25

24 Jun '25

5 7

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 16 Jun '25

16 Jun '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 10

[openstack helm] [Glance] Glance showing OSError: unable to receive chunked part when uploading image
by daniel890723＠gmail.com 10 Jun '25

10 Jun '25

Hello i'm testing using Openstack-helm to install all component but after the installation complete i can't upload the OS image through both openstack CLI or Horizon it stuck at Queueing and when i checking Glance Api log it shows 2024-11-07 07:31:19.362 7 INFO glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2024-11-07 07:31:19.400 7 ERROR glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Failed to upload image data due to internal error: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Caught error: unable to receive chunked part: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Traceback (most recent call last): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1302, in __call__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1345, in dispatch 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return method(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 415, in wrapped 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 299, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 162, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 492, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 443, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/quota/__init__.py", line 322, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 596, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 487, in _upload_to_store 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 397, in add_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 479, in store_add_to_backend_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/driver.py", line 294, in add_adapter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/capabilities.py", line 176, in op_checker 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 764, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise errors.get(e.errno, e) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 746, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi for buf in utils.chunkreadable(image_file, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 294, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = self.data.read(i) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 121, in readfn 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = fd.read(*args) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/format_inspector.py", line 956, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = self._source.read(size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1045, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi data = uwsgi.chunked_read() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Ceph Cluster Status: NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID ceph /var/lib/rook 3 82m Ready Cluster created successfully HEALTH_OK 5cf8b9bb-13e1-4c31-b47d-9e7d92c3c05d Ceph osd status: ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 0.35156 - 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 1.00 - root default -5 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 - host instance-lu-1 2 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 195 up osd.2 -3 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-2 0 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 195 up osd.0 -7 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-3 1 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 197 up osd.1 TOTAL 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 MIN/MAX VAR: 1.00/1.01 STDDEV: 0.01 now i'm able to create Empty Volume using horizon(can't create volume using default cirros image ) and i can start an Instance without volume and mount the empty volume in(Ceph also can detect when i use that volume) is there something i need to set when starting glance? because i'm following the Openstack-helm installation document to install openstack with helm

4 7

[ops][neutron] Neutron-db-manage upgrade from Antelope to Bobcat fails with "foreign key constraint 'porthints_ibfk_1' are incompatible" error
by federica fanzago 20 May '25

20 May '25

Dear all, we are running an OpenStack deployment Yoga on AlmaLinux 9.5 and we are attempting the upgrade Openstack up to Caracal release, one release at time (Zed--Antelope--Bobcat--Caracal) The procedure we are following is to shut down all openstack services, to remove the "old" openstack release and to install the new one, upgrading all service databases. This procedure works well for Zed and Antelope, but during the installation of the Bobcat release, the Neutron database upgrade fails when creating the new "porthints" table. The command we are using is su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron and the error message we receive is ... File "/usr/lib/python3.9/site-packages/pymysql/err.py", line 107, in raise_mysql_exception raise errorclass(errno, errval) sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (3780, "Referencing column 'port_id' and referenced column 'id' in foreign key constraint 'porthints_ibfk_1' are incompatible.") [SQL: CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB ... Our "ports" table uses the collation utf8mb3_general_ci mysql> SHOW FULL COLUMNS FROM ports; +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | project_id | varchar(255) | utf8mb3_general_ci | YES | MUL | NULL | | select,insert,update,references | | | id | varchar(36) | utf8mb3_general_ci | NO | PRI | NULL | | select,insert,update,references | | | name | varchar(255) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | | network_id | varchar(36) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | mac_address | varchar(32) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | admin_state_up | tinyint(1) | NULL | NO | | NULL | | select,insert,update,references | | | status | varchar(16) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | device_id | varchar(255) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | device_owner | varchar(255) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | standard_attr_id | bigint | NULL | NO | UNI | NULL | | select,insert,update,references | | | ip_allocation | varchar(16) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ in Bobcat the collation required for the new "porthints" table is latin1_swedish_ci MariaDB [neutron]> show create table porthints; +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | porthints | CREATE TABLE `porthints` ( `port_id` varchar(36) NOT NULL, `hints` varchar(4095) NOT NULL, PRIMARY KEY (`port_id`), CONSTRAINT `porthints_ibfk_1` FOREIGN KEY (`port_id`) REFERENCES `ports` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci | So, we have tried to create the porthints table in mysql, forcing the collation to utf8mb3_general_ci mysql> CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB DEFAULT CHARSET=utf8 DEFAULT COLLATE utf8mb3_general_ci; and commenting out the creation of the new table in the neutron code /usr/lib/python3.9/site-packages/neutron/db/migration/alembic_migrations/versions/2023.2/expand/6f1145bff34c_port_hints.py. In this way, the upgrade works, but we encounter the same kind of problem during the upgrade to Caracal, specifically with the creation of the new table porthardwareoffloadtype. Have you already encountered this issue during the Neutron upgrade? Do you have any suggestions on how to upgrade the neutron DB, without manually creating new tables? Thanks a lot, cheers, Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

4 8

[manila] Removal of the Standalone CephFS NFS protocol helper in Epoxy
by Ashley Rodriguez 01 May '25

01 May '25

Hi zorillas! As per subject line, we will be deprecating the standalone CephFS NFS protocol helper in this cycle. This is following our deprecation warning we put out in 2024.1 / Caracal [1] [2]. We've supported using a clustered Ceph NFS service since the Zed release. We've also added upgrade helpers to migrate from a standalone NFS-Ganesha service to the ceph-orch-deployed clustered NFS service; this code was backported to stable/2023.1 (Antelope). Although the upgrade path is disruptive, there is a UX improvement in Manila to ease this migration through surfacing “preferred” export paths. Moving forward, deployments must have “cephfs_nfs_cluster_id” in your configuration, otherwise the driver will fail to start. Manila will not make any export changes to NFS-Ganesha, so upgrading manila without an NFS cluster will mean that only the control plane is not going to work; but, data plane will remain unaffected. To assist migration, admins can also configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" metadata key set to False. Best, Manila team [1] https://review.opendev.org/c/openstack/manila/+/912648 [2] https://docs.openstack.org/manila/2024.2/configuration/shared-file-systems/…

5 7

Fwd: DPDK+OVS with OpenStack
by Mark Wittling 23 Apr '25

23 Apr '25

Looking for someone who knows OpenStack with OpenVSwitch, and in addition to that, DPDK with OpenStack and OVS.I am using OpenStack Queens, with OpenVSwitch. The architecture I am using is documented here: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlThe OVS I am using on the Compute Node, is compiled with DPDK, and I have enabled the datapath to netdev (DPDK) on br-prv (provider network bridge), and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv, are patched into another OpenStack bridge, called br-int. I wasn’t actually sure about whether to tinker with this bridge, and wondered what datapath it was using.Then, I realized there is a parameter in the openvswitch_agent.ini file, which I will list here: # OVS datapath to use. 'system' is the default value and corresponds to the # kernel datapath. To enable the userspace datapath set this value to 'netdev'. # (string value) # Possible values: # system - <No description provided> # netdev - <No description provided> #datapath_type = system datapath_type = netdev So in tinkering with this, what I realized, is that when you set this datapath_type to system or netdev, it will adjust the br-int bridge to that datapath type.So here is my question. How can I launch a non-DPDK VM, if all of the bridges are using the netdev datapath type?Here is another question. What if one of the flavors don’t have the largepages property set on them? I assumed OpenStack would revert to a system datapath and not use DPDK for those VM interfaces. Well, I found out in testing, that is not the case. If you set all your bridges up for netdev, and you don’t set the property on the Flavor of the VM (largepages), the VM will launch, but it simply won’t work.Is there no way, on a specific Compute Host, to support both DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VM interface level (VM has one interface that is netdev DPDK and another that is system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or more netdev datapath interfaces and VM 2 has 1 or more system datapath interfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’s DPDK or nothing on that Compute Host? (edited)

3 2

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

[oslo] python-consul2 is unmaintained
by Takashi Kajinami 21 Apr '25

21 Apr '25

Hello, I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years. Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints. Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library. As far as I can think of, there are three options now 1. Deprecate consul driver and remove it 2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns) 3. Replace python-consul2 by py-consul Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs. - Is anyone using the consul coordination driver now ? - Does anyone have experience with python-consul2 and/or py-consul ? Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list... Thank you, Takashi Kajinami [1] https://github.com/poppyred/python-consul2 [2] https://github.com/poppyred/python-consul2/issues/42 [3] https://github.com/criteo-forks/py-consul [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[octavia] Purging ERROR'ed amphora and load balancers stuck in transitional states
by Paul Browne 11 Apr '25

11 Apr '25

Hello Octavia users, For a while I've been trying to find a systematic way to remove Octavia LBs+Amphora that have become stuck in ERROR or transitional PENDING_* states ; $ openstack loadbalancer amphora list -f value | grep ERROR a2323f14-3aaa-418a-8249-111aaa9c21fe 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR MASTER 10.8.0.242 192.168.3.247 e5b236ba-e7ee-4ed7-9f58-57ce7a408489 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe ERROR BACKUP 10.8.0.190 192.168.3.247 6b556f28-93c9-49dd-b6ee-4379288e7957 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR MASTER 10.8.0.39 192.168.3.126 c669db5d-8686-4d5c-9e95-e02030b34301 d5e402fe-2c4b-49af-a700-532cb408cee5 ERROR BACKUP 10.8.0.174 192.168.3.126 $ openstack loadbalancer list -f value | grep -vi active 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe k8s-clusterapi-cluster-default-ci-6386871107-kube-upgrade-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.247 PENDING_UPDATE amphora d5e402fe-2c4b-49af-a700-532cb408cee5 k8s-clusterapi-cluster-default-ci-6386871107-latest-kubeapi 3a06571936a0424bb40bc5c672c4ccb1 192.168.3.126 PENDING_DELETE amphora These resources are marked immutable and so cannot be failed over or deleted; $ openstack loadbalancer amphora failover a2323f14-3aaa-418a-8249-111aaa9c21fe Load Balancer 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe is immutable and cannot be updated. (HTTP 409) (Request-ID: req-6e66c4e8-c3d3-4549-a03c-367017c8c8b3) $ openstack loadbalancer failover 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe Invalid state PENDING_UPDATE of loadbalancer resource 1fa7bd54-f60c-420c-94f3-d4c02f03d4fe (HTTP 409) (Request-ID: req-84b44212-e7a8-4101-a16f-18c774c0577e) The backing Nova instances for these Amphora do seem to exist and be in good working order. Is there any API way to purge these out of Octavia's service state, or would (very careful) DB hackery be required here? Many thanks, Paul Browne ******************* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pfb29(a)cam.ac.uk<mailto:pfb29@cam.ac.uk> Tel: 0044-1223-746548 *******************

4 6

GPU PCI passthrough woes.
by Andy Speagle 09 Apr '25

09 Apr '25

Hey Folks, I could use a little assistance getting GPU passthrough working. I had this working already for one flavor of nvidia gpu... and I've added some hosts with a much newer gpu... I've updated the pci_alias and pci_passthrough variables and those seem to be getting set properly in nova.conf passthrough_whitelist = [{"vendor_id":"10de", "product_id":"1b06"},{"vendor_id":"10de", "product_id":"26b9"}] alias = {"name": "gpu", "product_id": "1b06", "vendor_id": "10de"} alias = {"name": "gpu-l40s", "product_id": "26b9", "vendor_id": "10de"} I believe I have all of the iommu stuff configured and have the pci- stub module entries... dmesg output shows that the GPUs are being claimed by the stub module. $ openstack flavor show t1.small_gpu_l40s +----------------------------+--------------------------------------+ | Field | Value | +----------------------------+--------------------------------------+ | OS-FLV-DISABLED:disabled | False | | OS-FLV-EXT-DATA:ephemeral | 0 | | access_project_ids | None | | description | None | | disk | 0 | | id | af70c94e-0026-4a39-bc1e-dfb93b286a54 | | name | t1.small_gpu_l40s | | os-flavor-access:is_public | True | | properties | pci_passthrough:alias='gpu-l40s:1' | | ram | 2048 | | rxtx_factor | 1.0 | | swap | 0 | | vcpus | 1 | +----------------------------+--------------------------------------+ Yet... I can't seem to get an instance to run using that new flavor... keeps complaining about there not being enough hosts available. Fault: code: 500 created: 2024-10-30T02:04:33Z message: "No valid host was found. There are not enough hosts available." details: | Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 1580, in schedule_and_build_instances host_lists = self._schedule_instances(context, request_specs[0], File "/usr/lib/python3/dist-packages/nova/conductor/manager.py", line 940, in _schedule_instances host_lists = self.query_client.select_destinations( File "/usr/lib/python3/dist- packages/nova/scheduler/client/query.py", line 41, in select_destinations return self.scheduler_rpcapi.select_destinations(context, spec_obj, File "/usr/lib/python3/dist-packages/nova/scheduler/rpcapi.py", line 160, in select_destinations return cctxt.call(ctxt, 'select_destinations', **msg_args) File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/client.py", line 189, in call result = self.transport._send( File "/usr/lib/python3/dist- packages/oslo_messaging/transport.py", line 123, in _send return self._driver.send(target, ctxt, message, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 689, in send return self._send(target, ctxt, message, wait_for_reply, timeout, File "/usr/lib/python3/dist- packages/oslo_messaging/_drivers/amqpdriver.py", line 681, in _send raise result nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. Traceback (most recent call last): File "/usr/lib/python3/dist- packages/oslo_messaging/rpc/server.py", line 241, in inner return func(*args, **kwargs) File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 223, in select_destinations selections = self._select_destinations( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 250, in _select_destinations selections = self._schedule( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 416, in _schedule self._ensure_sufficient_hosts( File "/usr/lib/python3/dist-packages/nova/scheduler/manager.py", line 455, in _ensure_sufficient_hosts raise exception.NoValidHost(reason=reason) nova.exception.NoValidHost: No valid host was found. There are not enough hosts available. Any clues on how/where to dig into this more to see what might be missing? Thanks. -- Andy Speagle

3 2

bug report
by Xavier Benjamin 04 Apr '25

04 Apr '25

whenever i try to connect to trove pts servers it would usually say fails to authenticate or something. Can you fix that please?

2 2

[openstack-helm] Merge openstack-helm and openstack-helm-infra git repos
by Vladimir Kozhukalov 31 Mar '25

31 Mar '25

Hi dear Openstack-Helmers, I would like to suggest merging the two project git repos: https://opendev.org/openstack/openstack-helm-infra.git https://opendev.org/openstack/openstack-helm.git At some point it seemed reasonable to have separate git repos for openstack and infrastructure charts. But now it looks like we are experiencing more cons than pros. When working on some features we are forced to prepare sets of interdependent patches. Some code can be deduplicated. Also when we publish charts we append two commit hashes as package metadata. Also we can reduce the number of test jobs if we have all chats in one repo. Other people also proposed this earlier. So if there are no objections let's make it done. I understand this is going to affect many of our users. Please express your opinions so we don't break any downstream. If we all agree about this, then I would say we can do this in the mid of March/2025 before 2025.2 PTG. The procedure is going to be smth. like 1. Freeze the infra repo and prepare retirement PSs for it 2. Merge openstack-helm-infra repo into openstack-helm ``` git clone https://opendev.org/openstack/openstack-helm.git cd openstack-helm git remote add infra https://opendev.org/openstack/openstack-helm-infra.git git fetch infra git checkout -b infra infra/master git checkout master git merge --allow-unrelated-histories infra # resolve not so many conflicts git review ``` 3. Accept merger PS 4. Update documentation 5. Accept infra retirement PSs (openstack-helm-infra and project-config) -- Best regards, Kozhukalov Vladimir

4 10

[mistral][heat][watcher][aodh] croniter being abandoned
by Thierry Carrez 22 Mar '25

22 Mar '25

Hi everyone, It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA). https://pypi.org/project/croniter/#disclaimer The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency. While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it. -- Thierry Carrez (ttx)

5 8

[Devstack] Trying to setup development environment on VM
by Ishan Shanware (ishanwar) 16 Mar '25

16 Mar '25

Hello Everyone, I am currently trying to setup in all-in-one development environment for OpenStack on a Debian VM. The VM has 16 GB RAM and 4 CPUs. However, I face an error while trying to run FORCE=yes ./stack.sh. I get an error that keystone does not start. This causes the entire process to fail. Requesting assistance in solving this issue. I am following the this guide: https://docs.openstack.org/devstack/latest/guides/single-machine.html PFA the error log and error message on the terminal. [Call Trace] ./stack.sh:1126:start_keystone /opt/stack/devstack/lib/keystone:549:die [ERROR] /opt/stack/devstack/lib/keystone:549 keystone did not start Error on exit World dumping... see /opt/stack/logs/worlddump-2024-11-18-150808.txt for details ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection failed (No such file or directory) Thanks in advance, Ishan

3 5

[all][tc][ptl][qa] Migrating upstream CI/CD jobs to Ubuntu Noble (24.04)
by Ghanshyam Mann 14 Mar '25

14 Mar '25

Hello Everyone, As per the 2025.2 cycle testing runtime, we need to run upstream CI/CD jobs on Ubuntu Noble (24.04) [1]. For better tracking and speeding up this work, it is the community-wide goal for this cycle[2]. This is the etherpad which has the migration plan and will be used for the tracking: - https://etherpad.opendev.org/p/migrate-to-noble I have prepared the change(WIP) for base jobs migration on Noble (openstack tox jobs, devstack, and tempest) which will migrate most of the projects jobs. Tempest change[3] include dependency on openstack tox, devstack base jobs changes so testing project gate using the the tempest change will test the complete set. Refer to the etherpad for the complete migration plan/steps. * Deadline: Nov 29th 2024 (R18) is the deadline to test/fix the projects jobs and to merge the base jobs running on Noble (openstck tox, devstack, and tempest). [1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html [2] https://governance.openstack.org/tc/goals/selected/migrate-ci-jobs-to-ubunt… [3] https://review.opendev.org/c/openstack/tempest/+/932156 -gmann

2 9

[kolla] [nova] API flags ignored in Wallaby
by Albert Braden 12 Mar '25

12 Mar '25

After rebuilding our Train clusters on Wallaby we are seeing some API issues. It appears that flags that work in Train are still documented in Wallaby, but are ignored. Do we have something setup wrong, or are we encountering bugs? The first thing is the “locked” list: Train: openstack server list --all-projects --locked --os-compute-api-version 2.73 <empty list because nothing is locked> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> Wallaby (locked flag is ignored): openstack server list --all-projects --locked --os-compute-api-version 2.73 <list of every VM in the cluster> openstack server list --all-projects --unlocked --os-compute-api-version 2.73 <list of every VM in the cluster> The second problem is the hypervisor list. We can’t get “long” output in Wallaby: Train: openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State | vCPUs Used | vCPUs | Memory MB Used | Memory MB | Wallaby (long flag is ignored): openstack hypervisor list --long | ID | Hypervisor Hostname | Hypervisor Type | Host IP | State |

6 14

[all] Important discussion about the OpenInfra Foundation's future
by Jeremy Stanley 12 Mar '25

12 Mar '25

The OpenInfra Foundation's board of directors is considering a significant organizational change, and your feedback is critical to assist them in their decision. Please read this announcement on the foundation mailing list: https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… You can follow up publicly on that list with any questions or input you have for the board and staff, or in one of the public feedback conference calls mentioned there, as well as privately to Jonathan Bryce or myself if you prefer to give feedback in confidence. Thanks as always for your interest in the future of our community! -- Jeremy Stanley -- Jeremy Stanley

4 11

Confidential VM and TDX support in upstream Openstack
by Ildiko Vancsa 11 Mar '25

11 Mar '25

Hi, I'm reaching out about a topic that came up in the Kata Containers / Confidential Containers communities related to a feature in Kata that is called remote hypervisor and also referred to as peer pods. Kata provides an API that allows users to implement a function to run Kata Containers pods in a remote location, which can include a different host machine or cloud environment. The Cloud API Adaptor in the Confidential Containers project is an implementation of the Kata remote hypervisor interface: https://github.com/confidential-containers/cloud-api-adaptor It recently came up to add support for OpenStack to be a cloud option to run Kata remote VMs in. In order to implement that, OpenStack would need to support the creation of Confidential VMs (CVM) along with things like TDX. I looked around and found 3rd-party implementation to add TDX support to Nova, but the repo has been archived: https://github.com/intel/secured-cloud-management-stack/blob/main/scm3.0/no… Does anyone know if the CVM support along with supporting Intel TDX or related technologies have been added to OpenStack already? Or if there's anyone in the community planning for adding these in the future? Thanks and Best Regards, Ildikó

4 4

Assistance Required: OpenStack Helm Deployment (Version 2023.1) Compatibility Issues
by Thamanna Farhath 05 Mar '25

05 Mar '25

Hello OpenStack Community, I hope you are doing well. I am currently deploying OpenStack on top of a Kubernetes cluster using OpenStack Helm and aiming to install the 2023.1 (Antelope) version. However, I am facing difficulties in installing this specific version via Helm charts. Despite my attempts, I have not been able to successfully deploy the required OpenStack services for this release. Additionally, I am ensuring that the dependent services, such as RabbitMQ, align with the compatibility requirements of OpenStack 2023.1. As per the OpenStack documentation, RabbitMQ 3.11 is the recommended version, but I encountered issues while deploying it. Instead, I found that RabbitMQ 3.12 works without any issues. I would like to know: Is there a way to install OpenStack 2023.1 properly using Helm charts, or should I consider using a newer OpenStack version? Will using RabbitMQ 3.12 instead of 3.11 cause any potential issues with OpenStack services, or is it safe to proceed with this version? Are there any known workarounds or recommendations for deploying OpenStack 2023.1 using Helm? I would appreciate any guidance, best practices, or documentation references that could help resolve these challenges. Looking forward to your valuable insights. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 6

Remove config drive of instances
by Pardhiv Karri 02 Mar '25

02 Mar '25

Hi, We are on the Openstack Queens version. We added the config drive option during its build but never used it. How can we remove it? The "OpenStack server delete --no-config-drive" option isn't available due to the older version we are using. What is the best way to eliminate it, hopefully without rebooting the instances? Thanks, IM

4 7

[release] Release countdown for week R-4, Mar 03 - 07
by Elõd Illés 28 Feb '25

28 Feb '25

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2025.1 Epoxy deliverables can be proposed, well ahead of the final 2025.1 Epoxy release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2025.1 Epoxy release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2025.1 Epoxy, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2025.1 Epoxy that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 27th, 2025 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2025.1 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2025.1 Epoxy changes should be added there to make sure the consumers of your release notes see them. Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 14th, 2025 (R-3 week) Final RC deadline: March 28th, 2025 (R-1 week) Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 Előd Illés irc: elodilles @ #openstack-release

3 2

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 28 Feb '25

28 Feb '25

Hi all, Following on the good session we had last time discussing migrating out of LinuxBridge between operators, I would propose to meet again the first or second week of March. To find a good time slot, please respond to the following survey: https://newdle.cern.ch/newdle/7XbH4fCd For reference, the notes from last meeting: https://etherpad.opendev.org/p/neutron-lb-ovn-migration Best, Daniel Failing CERN Cloud Infrastructure

1 1

[kolla] IRC meeting cancelled - 5-th of March 2025
by Bartosz Bezak 28 Feb '25

28 Feb '25

Hi. Due to OpenInfra US conference related travel, Kolla IRC meeting on 5-th of March is cancelled. Best regards, Bartosz Bezak

1 0

Issues with installing Zun on Compute node
by Vaibhav 28 Feb '25

28 Feb '25

I was trying to install openstack 2024.2 zun on compute node. and following the page https://docs.openstack.org/zun/2024.2/install/compute-install.html for installation. I am facing the issue of docker "--cluster-store" support. I am using Docker 27.5 version. Reading the documentation online, i am confused. Some places it is, mentioned that it is fixed. and some places it suggest to uses docker 22. At few places in your mail you have mentioned to stop using kuryr and use CNI. And official documentation still says to use --cluster store. What is the current state and the correct solution. Please guide me. Vaibhav

3 3

[Openstack-ansible][cinder-volume] deletion of snapshot after creating a volume from it..
by Danish Khan 27 Feb '25

27 Feb '25

Dear All, Is there a way we can delete a volume who has a snapshot available? I have created a volume from snapshot and now we have a full chain of snapshots and volumes that we can't delete. But I need only the last volume to be available. If not then what is the best use case for snapshot? or Should I assume that if I create a snapshot and then create a volume from that snapshot then I need to keep the old volume and snapshot always. Regards, Danish

2 1

[neutron] Drivers meeting canceled Friday, February 28th
by Brian Haley 27 Feb '25

27 Feb '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as discussed at this week's meeting, plan is to have one next week. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

Problem to delete volume backup
by franck 27 Feb '25

27 Feb '25

2 1

[oslo][release][requirements] RFE for taskflow
by Herve Beraud 27 Feb '25

27 Feb '25

Hello, During this cycle we started to deprecat eventlet support in oslo deliverables However one patch missed the epoxy train [1]. We'd like to request approval about the release and also bumping taksflow version in stable/2025.1 requirements to properly align all our deliverables about eventlet support. Thank you in advance for your feedback. [1] https://review.opendev.org/c/openstack/taskflow/+/940884 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 3

Assistance Required: OpenStack Helm Deployment (Version 2023.1) Compatibility Issues
by Thamanna Farhath 26 Feb '25

26 Feb '25

Hello OpenStack Community, I hope you are doing well. I am currently deploying OpenStack on top of a Kubernetes cluster using OpenStack Helm and aiming to install the 2023.1 (Antelope) version. However, I am facing difficulties in installing this specific version via Helm charts. Despite my attempts, I have not been able to successfully deploy the required OpenStack services for this release. Additionally, I am ensuring that the dependent services, such as RabbitMQ, align with the compatibility requirements of OpenStack 2023.1. As per the OpenStack documentation, RabbitMQ 3.11 is the recommended version, but I encountered issues while deploying it. Instead, I found that RabbitMQ 3.12 works without any issues. I would like to know: Is there a way to install OpenStack 2023.1 properly using Helm charts, or should I consider using a newer OpenStack version? Will using RabbitMQ 3.12 instead of 3.11 cause any potential issues with OpenStack services, or is it safe to proceed with this version? Are there any known workarounds or recommendations for deploying OpenStack 2023.1 using Helm? I would appreciate any guidance, best practices, or documentation references that could help resolve these challenges. Looking forward to your valuable insights. Associate Engineer-R&D Thamanna Farhath N Cn: (+91) 9344093591 , thamanna.f(a)zybisys.com Zybisys Consulting LLP | Srinivasa Tower' No.29, 39th E Cross, 4th T Block, Jayanagar , Bangalore India – 560041 http://zybisys.com/ Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[openstack][kolla ansible]ask about Enhance Ceph Integration for Multiple Clusters backport
by Nguyễn Hữu Khôi 26 Feb '25

26 Feb '25

Hello folks. I would like to know if we have a plan for Enhance Ceph Integration for Multiple Clusters port? https://review.opendev.org/c/openstack/kolla-ansible/+/907166 Thank you. Regards Nguyen Huu Khoi

2 6

[all] CI resources usage optimization
by Sławek Kapłoński 26 Feb '25

26 Feb '25

Hi, In of of the recent weekly TC meetings we have discussed usage of our CI resources by projects. After that discussion I did small script [1] to get some more data about it. I checked separately how much nodes and "nodehours" are projects using in the check and gate queue to validate patches. Full results for the time rage 01.01.2025 to 13.02.2025 are in [2] for the check queue and in [3] for the gate queue. 1 "nodehour" means that 1 CI node was busy for 1 hour running job. This email is of course not sent just to tell team to cut their testing coverage but if you can take a closer look at your project's CI jobs configuration, maybe there is some way to improve it easily. For example if you have jobs running as non-voting for long time, maybe you can think of moving them to the experimental or periodic queue instead of running it in the check queue for every patch (or make it voting). This may be one of those small steps to optimize things a bit and make our own live easier as less load on infra means more stable jobs in general. Below there are results of the top 50 projects based on the "nodehours" per patch # Check queue +--------------------------------------------------+-------------------+------------------+----------------------------+-----------------------+---------------------------------+ | Project | Number of patches | Total Nodes used | Total time used [nodehour] | Nodes per patch (avg) | Time per patch (avg) [nodehour] | +--------------------------------------------------+-------------------+------------------+----------------------------+-----------------------+---------------------------------+ | openstack/openstack-ansible-rabbitmq_server | 2 | 72 | 90:06:07 | 36.00 | 45:03:03 | | openstack/octavia-tempest-plugin | 4 | 128 | 164:35:45 | 32.00 | 41:08:56 | | openstack/openstack-ansible-haproxy_server | 3 | 90 | 119:12:36 | 30.00 | 39:44:12 | | openstack/tacker | 14 | 1667 | 506:49:12 | 119.07 | 36:12:05 | | openstack/openstack-ansible-os_neutron | 8 | 204 | 289:32:21 | 25.50 | 36:11:32 | | openstack/openstack-ansible-os_keystone | 3 | 81 | 106:46:15 | 27.00 | 35:35:25 | | openstack/kolla-ansible | 130 | 8461 | 4491:25:21 | 65.08 | 34:32:57 | | openstack/openstack-ansible-os_octavia | 4 | 80 | 135:50:31 | 20.00 | 33:57:37 | | openstack/openstack-ansible | 31 | 872 | 1012:42:34 | 28.13 | 32:40:04 | | openstack/openstack-ansible-os_horizon | 5 | 115 | 162:39:57 | 23.00 | 32:31:59 | | openstack/openstack-ansible-os_aodh | 3 | 66 | 94:01:09 | 22.00 | 31:20:23 | | openstack/openstack-ansible-os_glance | 3 | 69 | 92:57:56 | 23.00 | 30:59:18 | | openstack/openstack-ansible-os_cinder | 3 | 63 | 86:19:38 | 21.00 | 28:46:32 | | openstack/openstack-ansible-os_magnum | 3 | 63 | 84:34:05 | 21.00 | 28:11:21 | | openstack/openstack-ansible-os_cloudkitty | 3 | 48 | 78:30:50 | 16.00 | 26:10:16 | | openstack/openstack-ansible-os_ironic | 6 | 93 | 153:06:27 | 15.50 | 25:31:04 | | openstack/openstack-ansible-os_barbican | 3 | 54 | 76:32:05 | 18.00 | 25:30:41 | | openstack/openstack-ansible-os_gnocchi | 2 | 32 | 51:00:15 | 16.00 | 25:30:07 | | openstack/openstack-ansible-os_ceilometer | 3 | 48 | 75:49:07 | 16.00 | 25:16:22 | | openstack/openstack-ansible-os_swift | 3 | 54 | 75:37:56 | 18.00 | 25:12:38 | | openstack/openstack-ansible-os_skyline | 5 | 89 | 124:53:18 | 17.80 | 24:58:39 | | openstack/openstack-ansible-os_placement | 2 | 36 | 49:46:31 | 18.00 | 24:53:15 | | openstack/tempest | 26 | 854 | 633:21:36 | 32.85 | 24:21:36 | | openstack/openstack-ansible-os_designate | 3 | 51 | 72:30:14 | 17.00 | 24:10:04 | | openstack/openstack-ansible-os_tempest | 2 | 36 | 47:27:46 | 18.00 | 23:43:53 | | openstack/openstack-ansible-os_mistral | 3 | 51 | 71:06:02 | 17.00 | 23:42:00 | | openstack/openstack-ansible-os_heat | 3 | 51 | 70:23:53 | 17.00 | 23:27:57 | | openstack/openstack-ansible-os_blazar | 2 | 32 | 46:30:44 | 16.00 | 23:15:22 | | openstack/openstack-ansible-os_masakari | 3 | 48 | 68:52:54 | 16.00 | 22:57:38 | | openstack/ansible-role-systemd_networkd | 13 | 277 | 297:37:09 | 21.31 | 22:53:37 | | openstack/ironic-tempest-plugin | 12 | 398 | 271:54:14 | 33.17 | 22:39:31 | | openstack/openstack-ansible-galera_server | 5 | 111 | 112:28:29 | 22.20 | 22:29:41 | | openstack/openstack-ansible-os_nova | 3 | 51 | 66:54:40 | 17.00 | 22:18:13 | | openstack/openstack-ansible-os_rally | 2 | 32 | 44:20:06 | 16.00 | 22:10:03 | | openstack/cinder | 127 | 3518 | 2746:32:43 | 27.70 | 21:37:34 | | openstack/openstack-ansible-os_tacker | 3 | 45 | 63:03:01 | 15.00 | 21:01:00 | | openstack/octavia | 38 | 917 | 764:50:26 | 24.13 | 20:07:38 | | openstack/cinder-tempest-plugin | 13 | 176 | 241:51:59 | 13.54 | 18:36:18 | | openstack/neutron-tempest-plugin | 8 | 129 | 147:41:46 | 16.12 | 18:27:43 | | openstack/devstack | 24 | 536 | 442:16:49 | 22.33 | 18:25:42 | | openstack/neutron | 186 | 3580 | 3283:39:42 | 19.25 | 17:39:14 | | openstack/nova | 251 | 6527 | 4383:59:41 | 26.00 | 17:27:58 | | openstack/openstack-ansible-plugins | 7 | 127 | 116:04:29 | 18.14 | 16:34:55 | | openstack/openstack-ansible-repo_server | 5 | 72 | 82:42:24 | 14.40 | 16:32:28 | | openstack/ironic | 79 | 2159 | 1284:28:46 | 27.33 | 16:15:33 | | openstack/ansible-role-systemd_service | 3 | 52 | 46:55:01 | 17.33 | 15:38:20 | | openstack/manila | 36 | 856 | 561:16:54 | 23.78 | 15:35:28 | | openstack/bifrost | 6 | 164 | 93:30:55 | 27.33 | 15:35:09 | | openstack/kolla | 35 | 997 | 530:29:59 | 28.49 | 15:09:25 | | openstack/glance | 43 | 718 | 616:18:37 | 16.70 | 14:19:58 | | openstack/manila-tempest-plugin | 13 | 177 | 178:58:11 | 13.62 | 13:46:00 | # Gate queue +--------------------------------------------------+-------------------+------------------+----------------------------+-----------------------+-------------------------16:35:44 [270/9949] | Project | Number of patches | Total Nodes used | Total time used [nodehour] | Nodes per patch (avg) | Time per patch (avg) [nodehour] | +--------------------------------------------------+-------------------+------------------+----------------------------+-----------------------+---------------------------------+ | openstack/openstack-ansible-rabbitmq_server | 1 | 31 | 32:04:31 | 31.00 | 32:04:31 | | openstack/octavia-tempest-plugin | 2 | 38 | 43:36:32 | 19.00 | 21:48:16 | | openstack/openstack-ansible-galera_server | 3 | 60 | 64:21:11 | 20.00 | 21:27:03 | | openstack/openstack-ansible-os_keystone | 1 | 18 | 20:01:48 | 18.00 | 20:01:48 | | openstack/openstack-ansible | 24 | 460 | 462:28:00 | 19.17 | 19:16:10 | | openstack/openstack-ansible-repo_server | 5 | 76 | 91:39:29 | 15.20 | 18:19:53 | | openstack/openstack-ansible-os_horizon | 3 | 39 | 52:58:46 | 13.00 | 17:39:35 | | openstack/openstack-ansible-plugins | 3 | 48 | 51:28:19 | 16.00 | 17:09:26 | | openstack/openstack-ansible-os_aodh | 1 | 13 | 16:30:26 | 13.00 | 16:30:26 | | openstack/openstack-ansible-os_octavia | 2 | 24 | 32:52:12 | 12.00 | 16:26:06 | | openstack/openstack-ansible-os_neutron | 4 | 61 | 65:06:05 | 15.25 | 16:16:31 | | openstack/openstack-ansible-os_cinder | 1 | 12 | 15:51:46 | 12.00 | 15:51:46 | | openstack/nova | 91 | 1788 | 1326:41:46 | 19.65 | 14:34:44 | | openstack/tempest | 8 | 181 | 116:36:02 | 22.62 | 14:34:30 | | openstack/openstack-ansible-os_glance | 1 | 13 | 14:28:12 | 13.00 | 14:28:12 | | openstack/openstack-ansible-os_skyline | 3 | 34 | 41:15:36 | 11.33 | 13:45:12 | | openstack/neutron | 87 | 1149 | 1033:31:12 | 13.21 | 11:52:46 | | openstack/openstack-ansible-lxc_container_create | 1 | 19 | 11:49:22 | 19.00 | 11:49:22 | | openstack/openstack-ansible-os_ironic | 4 | 36 | 46:49:08 | 9.00 | 11:42:17 | | openstack/devstack | 11 | 183 | 121:32:26 | 16.64 | 11:02:56 | | openstack/openstack-ansible-lxc_hosts | 2 | 27 | 22:00:46 | 13.50 | 11:00:23 | | openstack/ansible-role-httpd | 1 | 17 | 10:55:36 | 17.00 | 10:55:36 | | openstack/openstack-ansible-os_swift | 1 | 9 | 10:54:59 | 9.00 | 10:54:59 | | openstack/kolla-ansible | 44 | 847 | 468:00:27 | 19.25 | 10:38:11 | | openstack/ironic-tempest-plugin | 7 | 121 | 73:14:18 | 17.29 | 10:27:45 | | openstack/openstack-ansible-os_barbican | 1 | 9 | 10:22:22 | 9.00 | 10:22:22 | | openstack/openstack-ansible-os_heat | 1 | 9 | 10:20:01 | 9.00 | 10:20:01 | | openstack/openstack-ansible-os_ceilometer | 1 | 9 | 10:18:23 | 9.00 | 10:18:23 | | openstack/bifrost | 6 | 108 | 60:34:38 | 18.00 | 10:05:46 | | openstack/openstack-ansible-os_masakari | 1 | 9 | 10:00:38 | 9.00 | 10:00:38 | | openstack/ansible-role-systemd_networkd | 11 | 136 | 109:26:42 | 12.36 | 09:56:58 | | openstack/openstack-ansible-os_cloudkitty | 1 | 9 | 09:56:58 | 9.00 | 09:56:58 | | openstack/openstack-ansible-os_designate | 1 | 9 | 09:54:08 | 9.00 | 09:54:08 | | openstack/openstack-ansible-os_mistral | 1 | 9 | 09:50:16 | 9.00 | 09:50:16 | | openstack/openstack-ansible-os_tacker | 1 | 9 | 09:38:43 | 9.00 | 09:38:43 | | openstack/kolla | 14 | 223 | 134:48:14 | 15.93 | 09:37:43 | | openstack/openstack-ansible-os_magnum | 1 | 9 | 09:11:37 | 9.00 | 09:11:37 | | openstack/openstack-ansible-openstack_hosts | 1 | 12 | 08:58:07 | 12.00 | 08:58:07 | | openstack/openstack-ansible-os_nova | 1 | 9 | 08:49:26 | 9.00 | 08:49:26 | | openstack/swift | 21 | 484 | 180:31:42 | 23.05 | 08:35:47 | | openstack/neutron-lib | 10 | 94 | 82:54:52 | 9.40 | 08:17:29 | | openstack/ansible-role-pki | 3 | 40 | 24:50:35 | 13.33 | 08:16:51 | | openstack/kayobe | 21 | 372 | 173:09:54 | 17.71 | 08:14:45 | | openstack/glance | 12 | 140 | 94:42:31 | 11.67 | 07:53:32 | | openstack/openstack-ansible-os_trove | 1 | 6 | 07:50:27 | 6.00 | 07:50:27 | | openstack/ansible-role-python_venv_build | 1 | 6 | 07:34:53 | 6.00 | 07:34:53 | | openstack/ironic | 46 | 671 | 337:51:59 | 14.59 | 07:20:41 | | x/devstack-plugin-tobiko | 6 | 57 | 42:46:30 | 9.50 | 07:07:45 | | openstack/cinder | 20 | 204 | 136:59:33 | 10.20 | 06:50:58 | | openstack/requirements | 47 | 1404 | 320:35:23 | 29.87 | 06:49:15 | | openstack/placement | 4 | 49 | 27:11:05 | 12.25 | 06:47:46 | [1] https://github.com/slawqo/tools/blob/master/jobs_time/infra_usage_stats.py [2]https://paste.opendev.org/show/bzS4jJgGxMq9UUBfwKNn/ [3] https://paste.opendev.org/show/bbrKIKUAGiHsntU1cQ7L/ -- Slawek Kaplonski Principal Software Engineer Red Hat

3 2

[manila] 2025.1 Epoxy Bugsuqash - Mar 3 - 4th
by Carlos Silva 26 Feb '25

26 Feb '25

Hello, Zorillas and interested stackers, Next week, the Zorillas will be meeting for the second bugsquash of the 2025.1 Epoxy cycle. Next week's bugsquash will be focused on stale bugs. We will have a kickoff meeting on Monday (March 3rd) at 15 UTC using meetpad [1], and work on the list of bugs. [1] https://meetpad.opendev.org/manila-epoxy-bugsquash Looking forward to it! carloss

1 0

[oslo][release][requirements] RFE for oslo.db and oslo.service
by Takashi Kajinami 26 Feb '25

26 Feb '25

Hi ! We've identified a few regressions in the latest Epoxy release of oslo libraries, and these are currently blocking a few projects such as octavia or watcher. We already published a new releases with the required fixes. Although we already passed the requirement freeze, I'd like to request a freeze exception to unblock the affected projects. I'm specifically talking about the following two requirement bumps. oslo.db https://review.opendev.org/c/openstack/requirements/+/942829 fixes https://launchpad.net/bugs/2099908 oslo.service https://review.opendev.org/c/openstack/requirements/+/942830 fixes https://launchpad.net/bugs/2099955 Please let me know if you have any question, and I appreciate your help ! -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 1

[all][elections][tc] 2025.2/F Technical Committee Election Results
by Sławek Kapłoński 26 Feb '25

26 Feb '25

Hi, Please join me in congratulating the 5 newly elected members of the Technical Committe (TC). * Amy Marrich (spotz) * Artem Goncharov (gtema) * Goutham Pacha Ravi (gouthamr) * Dmitriy Rabotyagov (noonedeadpunk) * Michal Nasiadka (mnasiadka) Election: no election required. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Slawek Kaplonski on behalf of the OpenStack Technical Election Officials

1 0

[all][elections][ptl] 2025.2/F: PTL Election Conclusion & Results
by Sławek Kapłoński 26 Feb '25

26 Feb '25

Hi, Thank you to the electorate, and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant - Dale Smith (dalees) * Blazar - Matt Crees (mattcrees) * Cinder - Jon Bernard () * Cloudkitty - Rafael Weingartner () * Cyborg - alex song (songwenping) * Designate - Omer Schwartz (oschwart) * Glance - Cyril Roelandt (croelandt) * Heat - Takashi Kajinami (tkajinam) * Horizon - Tatiana Ovchinnikova (tmazur) * Keystone - Artem Goncharov (gtema) * Kolla - Michal Nasiadka (mnasiadka) * Magnum - Dale Smith (dalees) * Manila - Carlos Silva (carloss) * Mistral - Axel Vanzaghi (avanzaghi) * Monasca - Hasan Acar () * Neutron - Brian Haley (haleyb) * Nova - René Ribaud (rribaud) * Octavia - Michael Johnson (johnsom) * OpenStack Helm - Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible - Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK - Artem Goncharov (gtema) * Puppet OpenStack - Takashi Kajinami (tkajinam) * Quality Assurance - Ghanshyam Mann (gmann) * Rally - Andrey Kurilin (andreykurilin) * Skyline - Wenxiang Wu (wu_wenxiang) * Storlets - Takashi Kajinami (tkajinam) * Sunbeam - Hemanth Nakkina (hemanth-n) * Swift - Tim Burke (timburke) * Tacker - Yasufumi Ogawa (yasufum) * Telemetry - Juan Larriba (jlarriba) * Trove - Wu Chunyang (wuchunyang) * Venus - Sirui Jia () * Vitrage - Dmitriy Rabotyagov (noonedeadpunk) * Zun - Hongbin Lu () Elections: no election required. For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, Slawek Kaplonski, on behalf of the OpenStack Technical Election Officials

1 0

[release][swift][horizon][ironic] Deliverables missing Epoxy releases
by Thierry Carrez 26 Feb '25

26 Feb '25

Hi everyone, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the 2025.1 Epoxy cycle: swift horizon bifrost ironic-inspector ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch Those should be released ASAP, and in all cases before March 14th, so that we have a release to include in the final 2025.1 Epoxy release. -- Thierry Carrez (ttx)

2 1

[openstack-helm] Retire Senlin chart
by Vladimir Kozhukalov 25 Feb '25

25 Feb '25

Hi team, This is to suggest retiring the senlin chart. The project is retired now and there has been little interest in this chart recently. So I believe we can remove the chart painlessly. Opinions are welcome. -- Best regards, Kozhukalov Vladimir

3 2

[publiccloud-sig] Next meeting of Public Cloud SIG upcoming - February 26th at 0800 UTC
by Felix Kronlage-Dammers 25 Feb '25

25 Feb '25

Hi everyone, This upcoming Wednesday (February 26th) the next meeting of the publiccloud-sig is going to happen. We’ll be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG See ya Wednesday (depending on the timezone, this is tomorrow ;) ! felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-5)
by Goutham Pacha Ravi 24 Feb '25

24 Feb '25

Hello Stackers, We're a couple of days away from milestone-3 of the 2025.2 ("Epoxy") release cycle [1]. For OpenStack project teams with deliverables following the "cycle-with-rc" release model [2], 2025-02-27 marks a Feature Freeze [2]. Client software releases are also due on this date, and from next week, we'll be actively squashing bugs to tag and ship release candidates. Last week, we concluded the nomination period for project leaders for 40+ OpenStack project teams and for 5 seats on the Technical Committee. We have just enough or fewer nominees than there are positions. Since no polls are needed, Ian Y Choi (ianychoi) and Slawek Kaplonski (slaweq), our election officials, are working with the TC to conclude the process. The TC will also work with project teams to appoint leaders for projects where there were no PTL nominees during the nomination window. More details about this will be shared on this mailing list as soon as they are available. Also, in the past week, the TC made some governance changes regarding the Ironic project. Several project contributors stepped up to be liaisons and adopt the Distributed Project Leadership model for the upcoming release [3]. The team also deprecated ironic-lib [4], as its relevant code has moved into the Ironic service and Ironic Python Agent. === Weekly Meeting === The TC met on OFTC's #openstack-tc channel on 2025-02-18 [5]. Ghanshyam Mann (gmann) and Artem Goncharov (gtema) noted their collaboration with the OSLO project team to expand the core team of the openstackdocstheme and os-api-ref repositories. This expansion is expected to support work to create OpenAPI specifications for OpenStack API services. We discussed the kinds of contributions that qualify individuals as Active Contributors, making them eligible to vote or contest in OpenStack elections. This follows our recent inclusion of governance repositories in the list of repositories counted for contributions. We encouraged project teams to actively nominate additional contributors—those who support their teams through invaluable work such as code review, bug grooming, documentation, mentoring, managing trackers, events, and communication. This can be done by adding "extra-acs" to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-AC freeze. The freeze has passed for the 2025.1 release cycle; however, you can propose Extra-ACs for the upcoming cycle now. Besides being eligible as candidates and voters, Extra-ACs will also appear on the release contributor list. We also brought up patches proposing to tag "end-of-life" for "unmaintained" branches: Wallaby [6], Xena [7], and Yoga [8]. These patches will remain open for 30 days, allowing contributors who wish to maintain these branches to step up. If no objections arise, these patches will be merged, and the branches will be deleted. Finally, we analyzed recent CI usage statistics and found that some projects, such as openstack/tacker, had significantly high node usage (averaging 119 nodes per patch in the check queue), consuming approximately 25% of the total aggregate quota. We will summarize our findings in a separate post to this list. The next IRC meeting of the OpenStack TC will be held today, 2025-02-25, at 1800 UTC in the #openstack-tc channel on OFTC. Please find the agenda in the meeting wiki [9]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Switch Ironic to Distributed Leadership | https://review.opendev.org/c/openstack/governance/+/941935 - Cleanup policy popup leads list | https://review.opendev.org/c/openstack/governance/+/941148 - Deprecate ironic-lib | https://review.opendev.org/c/openstack/governance/+/939278 ==== Open for Review ==== - Add TC/PTL results from 2025.2 election | https://review.opendev.org/c/openstack/governance/+/942507 - Add Extra-ACs to the tech committee repos | https://review.opendev.org/c/openstack/governance/+/942296 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === - 2025-02-28: 2025.1 ("Epoxy") Feature Freeze and release milestone 3 [1] - 2025-03-06: SCALE 2025 + OpenInfra Days NA (https://www.socallinuxexpo.org/scale/22x) - 2025-03-11: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-04-07: OpenInfra PTG Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] "cycle-with-rc" release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [2] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [3] Switch Ironic to Distributed Leadership: https://review.opendev.org/c/openstack/governance/+/941935 [4] Deprecate ironic-lib: https://review.opendev.org/c/openstack/governance/+/939278 [5] TC Meeting IRC Log 2025-02-18: https://meetings.opendev.org/meetings/tc/2025/tc.2025-02-04-18.00.log.html [6] Transition unmaintained/wallaby to EOL: https://review.opendev.org/c/openstack/releases/+/941458 [7] Transition unmaintained/xena to EOL: https://review.opendev.org/c/openstack/releases/+/942201 [8] Transition unmaintained/yoga to EOL: https://review.opendev.org/c/openstack/releases/+/942218 [9] TC Meeting Agenda, 2025-02-25: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[nova]Intel RDT CAT Support Missing from OpenStack
by Junya Noguchi (Fujitsu) 24 Feb '25

24 Feb '25

To whom it may concern I have a question regarding the lack of Intel RDT CAT implementation in OpenStack We are planning to commit Resource Monitoring functionality to Openstack for ARM, and are exploring the implementation of Intel RDT on Openstack. We found the following blueprint for the Intel RDT CAT implementation in nova. https://blueprints.launchpad.net/nova/+spec/cat-support However, the Intel RDT CAT feature is not currently implemented in OpenStack. Has the implementation of Intel RDT CAT functionality in Openstack been rejected? Or is it just a development delay? Best regards, Junya Noguchi.

5 9

Keystone Tokenless
by Ryan Belgrave 24 Feb '25

24 Feb '25

Hey All! I've been reading the documentation here https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.h… and poking through the Keystone code to figure out how tokenless authentication works. However, It doesn't seem like tokenless auth can be used as a full replacement for usernames and passwords when using ephemeral users? I can manage to get a role assignment created that allows tokenless to work for domain and project scopes but it doesn't seem possible to set up tokenless for the system scope. Without system scope I can't list catalog services or get their endpoints. Re-reading through the documentation it says: This feature is designed to reduce the complexity of user token validation in Keystone auth_token middleware by eliminating the need for service user token for authentication and authorization. Which seems like tokenless should only be used for user token validation and nothing else. It doesn't look like this auth mechanism can be used in the same manner as others for service-to-service communication? I can't really tell if I am doing something wrong or my understanding of the documentation is correct and it should only be used for user token validation. If tokenless should only be used for user token validation are there any plans to support it normally as a full replacement of usernames and passwords? Thanks! - Ryan

1 0

some more Mistral questions.
by Alvin Starr 24 Feb '25

24 Feb '25

I am trying to create a VM with an attached volume. Does someone have a pointer to or an example of a workflow that creates a volume. -- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin(a)netvel.net ||

2 2

#eventle-removal - Progress & Updates Epoxy Milestones 2-3
by Herve Beraud 24 Feb '25

24 Feb '25

Today we wanted to share with you the latest updates on our ongoing efforts to phase out Eventlet across our various OpenStack projects. Below you’ll find a summary of our progress, key milestones, and important dates to keep in mind as we continue to move forward with this critical initiative. ## Current Status The lib freeze is next week and we are close from milestone 3. At the time I wrote these lines 105 eventlet removal patches have been submitted on our gerrit and 61 patches are now merged. That shows really good progress. https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22 Eventlet is now in version 0.39.0 and is compatible and ready to be used with Python 3.13, meaning that we are ready for an upgrade of our runtimes within the coming series. ## Achievements Among all the contributions, we can highlight these achievements: - 2 deliverables are now completely migrated: python-manilaclient and mistral-lib; - Neutron implemented their new socket server in replacement of the eventlet WSGI features and they started to migrate their OVN agent other that new server; - Mistral has made excellent progress and significantly reduced their usages of Eventelt. From moving from coroutines to threading, or migrating their messaging executor. We will been soon able to consider mistral as fully migrated; - Glance started a wide clean up of Eventlet into their functional tests; - oslo.service's backend mechanism is now implemented and the Eventlet isolation as been merged, opening the door of its refactoring based on threading; - Almost all Oslo deliverables (apart oslo.vmware) deprecated Eventlet from their usages; - Eventlet's support of Python 3.13 has been implemented and released; - Eventlet stabilization works have been done during the past months and we now observe less negative feedback and less new bugs. No news, good news; - The community goal is now selected, officializing the starting of this initiative. ## Latest Updates There are side conversations concerning the deprecation/removal of oslo.rootwrap and oslo.vmware. Those both deliverables rely on Eventlet and are in some way considered as deprecated or experimental. In parallel to that, we think we should also have a discussion about heat and heat-templates. The activity of these projects seems quite slow and (do not hesitate to correct me if I'm wrong) they are more or less in a way to be replaced with more modern ways to orchestrate OpenStack. Should we not prioritize their deprecation or at least start a wider discussion about their fate? ## Call to Action Epoxy is a SLURP series, and as we are close from lib freeze and from milestone 3, that's the right time to prioritize your deprecations in your deliverables in view of removing these pieces with non-SLURP series. The sooner they are deprecated the better. ## Important Dates Please do not hesitate to join us during our bi-weekly meeting on #openstack-eventlet-removal. Bring your own topics and do not hesitate to ask questions. All the details are available in the links below: - https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events - https://etherpad.opendev.org/p/epoxy-eventlet-tracking ## Final Thoughts This series strongly demonstrated the feasibility to remove our dependency to Eventlet. There is still a long way to go but the path is now well cleared. Do not hesitate to take example on the ongoing efforts, and If there are any questions or if you need assistance with your project’s transition away from Eventlet, please join the discussion on the #openstack- eventlet-removal OFTC channels . We will be happy to help you! Thank you for your dedication and hard work! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 6

[NOVA] - Instances got stuck at boot with PCI passthrough mechanism enabled
by jeanpierre.roquesalane＠dell.com 24 Feb '25

24 Feb '25

Hello all! Our new env uses Zuul and nodepool for managing vms on which will be executed devstack and tempest. Those VMS are hosted on an openstack cloud with nodepool spinning them up every time a CI job is triggered. This is something very common in OpenStack end users but can be challenging for our powermax product line as it requires HBA which are seen by the host not the guest. We have followed documentation to set it up and I confirm the HBAs are visible to the instances but unfortunately once those cards are seen the instance get stuck at the boot process just like they were waiting for something. Any advice would be highly appreciated. Thank you.

1 0

Separate the read/write SQL requests
by Mia 24 Feb '25

24 Feb '25

Hi OpenStack community, I'm currently working on read/write database splitting in my OpenStack environment using this document: https://docs.openstack.org/large-scale/journey/configure/database.html#reve… Here is what I've done up to this point: - Configured HAProxy as recommended - Added the slave_connection parameter to all service configurations(nova.conf, cinder.conf, etc.) To test this, I enabled MariaDB's general_log on all nodes. However, upon checking the logs, most SELECT queries still reach the first database node instead of the other replicas. Did I miss a configuration step somewhere? Any guidance would be super helpful.

3 3

Re: CLI clients and neutron QoS packet_rate_limit rules
by Nell Jerram 24 Feb '25

24 Feb '25

FYI the attached patches, against openstacksdk 0.62.0 and python-openstackclient 5.8.1, allow me to successfully execute `openstack network qos rule create --type packet-rate-limit --max-kpps 111 --ingress bw-limiter`. (I'm using those old base versions because of testing against a Yoga system.) If I may whinge for a brief moment: it's quite tedious that boilerplate changes are needed in multiple different places for this change. I'm only really saying this in case there are others who agree and my opinion might help to build their case... Best wishes - Nell On Mon, Feb 24, 2025 at 9:46 AM Nell Jerram <nell(a)tigera.io> wrote: > Many thanks Rodolfo. I'll experiment locally with possible fixes here, > and follow up later. > > Best wishes - Nell > > > On Sat, Feb 22, 2025 at 4:22 PM Rodolfo Alonso Hernandez < > ralonsoh(a)redhat.com> wrote: > >> Hi Nell: >> >> The neutronclient project is now deprecated, at least the CLI part. As >> you mentioned, the OSC cannot create these packet rate rules. I'll create a >> bug. >> >> Regards. >> >> On Fri, Feb 21, 2025 at 7:04 PM Nell Jerram <nell(a)tigera.io> wrote: >> >>> Is it just an oversight that the openstack client doesn't support >>> packet_rate_limit rules? [1] >>> >>> Looking at the file names under [2], it looks like that might be true >>> for the neutron client as well. >>> >>> [1] >>> https://github.com/openstack/python-openstackclient/blob/master/openstackcl… >>> >>> [2] >>> https://github.com/openstack/python-neutronclient/tree/master/neutronclient… >>> >>> Best wishes - Nell >>> >>>

2 2

[neutron] Bug deputy report from week of 17th February
by Sławek Kapłoński 24 Feb '25

24 Feb '25

Hi, I was bug deputy last week. Here's summary of what new bugs do we have and their current state: ### Critical - none ### High - none ### Medium - https://bugs.launchpad.net/neutron/+bug/2098996 - empty_string_filtering extension is not enabled for ML2/OVN - fix already proposed: https://review.opendev.org/c/openstack/neutron/+/942387 - https://bugs.launchpad.net/neutron/+bug/2099450 - Incorrect ovsdb_connection validation - fix already proposed https://review.opendev.org/c/openstack/neutron/+/942412 - https://bugs.launchpad.net/neutron/+bug/2099706 - [OVN][QoS] QoS rule addition to an exiting net work policy only updates the first port - assigned to Rodolfo, patch proposed https://review.opendev.org/c/openstack/neutron/+/942516 - https://bugs.launchpad.net/neutron/+bug/2099755 - # [whitebox-neutron-tempest-plugin] ``QosTestExternalNetwork.test_dscp_bwlimit_external_network`` must check BW with VMs on different compute nodes - assigned to Rodolfo ### Low - https://bugs.launchpad.net/neutron/+bug/2098815 - # attempting to write bad value to column external_ids (ovsdb error: expected string, got <class 'NoneType'>) - assigned to Terry and already have fix proposed, - https://bugs.launchpad.net/neutron/+bug/2099798 - error when running `osken` in os_ken CLI in python 3.13 - this is osken bug impacting osken CLI tool (I didn't even know there is something like that there :)) - needs volunteer if we want to fix it, - https://bugs.launchpad.net/neutron/+bug/2099799 - `os_ken.topology.switches` cannot be stopped when observing links - yet another os-ken bug, needs volunteer ### RFE - https://bugs.launchpad.net/neutron/+bug/2098736 - [RFE] Use quota engine to replace config option "max_allowed_address_pair" - needs owner, - https://bugs.launchpad.net/neutron/+bug/2098737 - # Create a restricted default policy for undefined API calls - this needs owner but I may most likely take ownership of it, it may also require some oslo_policy changes but I am not sure about it yet, - https://bugs.launchpad.net/neutron/+bug/2099818 - ovn-sync add -reported by and already assigned to Kevin Carter, ### To triage - https://bugs.launchpad.net/neutron/+bug/2099675 - trunk subport vnic_type not inherited from parent, DHCP for baremetal ports does not work - this one deeds to be checked by someone who knows more about trunk and baremetal ports in OVN, ### Invalid (for Neutron) - https://bugs.launchpad.net/python-openstackclient/+bug/2098980 - "openstack port list -c" showing non existing columns - I moved it to be OSC bug, not the neutron one, needs assignment, should be low-hanging-fruit bug to fix -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[designate] Kubernetes External-DNS webhook provider for OpenStack Designate
by Christian Rohmann 22 Feb '25

22 Feb '25

Hello openstack-discuss, the external-dns [1] controller is the de-facto standard to integrate Kubernetes with DNS services, one of them being OpenStack Designate. 1) For quite a while there is a push to move the provider specific code out of tree, see [2], [3]. With (larger) changes not being reviewed / merged for the in-tree Designate code, [4] we bit the bullet and wrote a webhook provider implementation for OpenStack Designate, [5], which I also proposed to be added to the list of new providers via [6]. If you are running Kubernetes on top of OpenStack, I kindly ask you to give this webhook a try and see if it works or if there are still some kinks to iron out. If so: Open helpful issues, send PRs! 2) I am also reaching out to see if potentially you would even want to adopt this project as OpenStack Designate. While one could argue that it's out of OpenStack Designates element to care about Kubernetes. I believe a good integration and well working interfaces are key to keep OpenStack attractive as a platform (to run Kubernetes on). And with the webhook provider being an independent piece of software, just implementing the webhook provider interface [7], the contact surface with Kubernetes is very limited to non-existing. It's mostly Gophercloud ([8]) calling the Designate-API for the DNS record management actions external-dns requires. Looking a bit more closely to this widely used controller hitting the Designate-API might give also provide good insights or ideas for improvements or in the very least facilitates adoption. Regards Christian [1] https://github.com/kubernetes-sigs/external-dns [2] https://github.com/kubernetes-sigs/external-dns/issues/4347 [3] https://github.com/kubernetes-sigs/external-dns?tab=readme-ov-file#status-o… [4] https://github.com/kubernetes-sigs/external-dns/pull/3024 [5] https://github.com/inovex/external-dns-designate-webhook [6] https://github.com/kubernetes-sigs/external-dns/pull/5115 [7] https://kubernetes-sigs.github.io/external-dns/v0.15.1/docs/tutorials/webho… [8] https://github.com/gophercloud/gophercloud

1 0

CLI clients and neutron QoS packet_rate_limit rules
by Nell Jerram 22 Feb '25

22 Feb '25

Is it just an oversight that the openstack client doesn't support packet_rate_limit rules? [1] Looking at the file names under [2], it looks like that might be true for the neutron client as well. [1] https://github.com/openstack/python-openstackclient/blob/master/openstackcl… [2] https://github.com/openstack/python-neutronclient/tree/master/neutronclient… Best wishes - Nell

2 1

[release] Release countdown for week R-5
by Thierry Carrez 21 Feb '25

21 Feb '25

Development Focus ----------------- We are getting close to the end of the 2025.1 Epoxy cycle! Next week on February 27th, 2025 is the Epoxy-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the 2025.2 Flamingo cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on February 27th, 2025. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2025.1 branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… February 27th, 2025 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Epoxy-3 milestone (feature freeze): February 27th, 2025 (R-5 week) RC1 deadline: March 14th (R-3 week) Final RC deadline: March 28th (R-1 week) Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 -- Thierry Carrez (ttx)

1 0

[neutron] Drivers meeting canceled Friday, February 21st
by Brian Haley 20 Feb '25

20 Feb '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as I have a conflict. We can cover an RFEs added this week next Friday. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

OVN in latest OpenStack
by Jani Heikkinen 20 Feb '25

20 Feb '25

We have been installing openstack Dalmatian based on Debian packages on our institution. I am currently trying to configure OVN neutron metadata service, but it seems very hard to find how OVN actually currently does it. See [1.]. The documentation states first, that ovn-metadata-agent will run with a netns and haproxy instance on hypervisor. But there is also a reference to having metadata support in ovn-controller. In addition, I have seen hints suggesting that neutron-ovn-agent and neutron-ovn-metadata-agent would be exclusive to each other. What is the currently up-to-date way to configure OVN metadata agent? Especially, is there any up-to-date instructions how to properly configure neutron's related config files? We have following versions of ovn and ovs: openvswitch-common 3.1.0-2 (+deb12u1) ovn-common 23.03.1-1 (~deb12u2) ovn-host 23.03.1-1 (~deb12u2) neutron-ovn-metadata-agent 2:25.0.0 (-5~bpo12+1) neutron-ovn-agent 2:25.0.0 (-5~bpo12+1) Best Regards, Jani Heikkinen [1.] https://docs.openstack.org/networking-ovn/latest/contributor/design/metadat… -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen(a)bfh.ch

5 10

how to clear instance actions
by Jiatong Shen 20 Feb '25

20 Feb '25

Hello Experts, During operating an old deployment, we found that instance_action as well as instance_action_event stores many records. The instance with actions are still in use. I would like to ask if there is any tool to clear instance action & events? Thank you very much for your help. -- Best Regards, Jiatong Shen

2 1

[all][elections][tc] 2025.2 cycle TC Election Campaigning Kickoff
by Ian Y. Choi 19 Feb '25

19 Feb '25

Developers, The TC Election Campaigning Period has now started [1]. Although there are no polls that need to be held [2], during the next couple days, you are all encouraged to ask the candidates questions about their platforms [3], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. TC Candidates, Each of you has posted a platform [3], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. Ian Y. Choi, on behalf of the election officials. [1] https://governance.openstack.org/election/ [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://opendev.org/openstack/election/src/branch/master/candidates/2025.2/…

1 0

[all][elections][ptl][tc] Combined PTL/TC 2025.2 cycle Election Nominations End
by Ian Y. Choi 19 Feb '25

19 Feb '25

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 6 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Barbican, Ironic, Masakari, OpenStack_Charms, Oslo, Zaqar There are 0 projects that will have elections: . -- TC Election Details -- There are 5 candidates for 5 seats. The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Given that there are no polls that need to be held, this concludes the election process. Congratulations to our new and returning leaders. Thank you, Ian Y. Choi, on behalf of the election officials. [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[horizon] Automatic refresh of page elements/content
by Barros Frossard, Davi 19 Feb '25

19 Feb '25

Hi everyone, I would like to query about implementing a feature: Automatic refresh of page elements/content on openstack dashboard (horizon). I'm a developer working on starlingx dashboard (gui) project, which is based on openstack dashboard. We noticed that all content on starlingx dashboard doesn't get updated if a change occurs. So, as a workaround, a full page reload is required. We have added a patch to customize horizon package and enable automatic refresh in some of the content. But this is not a definitive solution, since it doesn't solve auto refresh for all page elements/content: https://review.opendev.org/c/starlingx/upstream/+/941145 We also noticed errors on browser's console related to mutation events, although I'm not sure this is relevant for the discussion: https://bugs.launchpad.net/horizon/+bug/2098785 Do you have any plans to add such a feature? Or should we submit a blueprint? Thank you for your time. Regards, Davi Frossard

2 1

[largescale-sig] Next meeting: February 19, 9utc
by Thierry Carrez 19 Feb '25

19 Feb '25

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250219T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

2 2

[election][cloudkitty] PTL candidacy for the 2025.2 release cycle
by Rafael Weingärtner 19 Feb '25

19 Feb '25

Hi all, I would like to self-nominate for the role of PTL of CloudKitty for the 2025.2 release cycle. I have been PTL since the Victoria cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. I have opened the patch with my candidacy: https://review.opendev.org/c/openstack/election/+/942176 -- Rafael Weingärtner

1 0

[cinder][nova] NVMe over RMDA
by holger.bielefeld＠uponu.com 18 Feb '25

18 Feb '25

Hi all, does anyone know if NVMe over RDMA is supported to attach it with Cinder/Nova to a QemuKVM Hypervisor? In addition to our ceph, we would also like to connect a block storage and in order to be able to retrieve the full performance, this must be done with the above-mentioned connection. Thanks in advance. Holger

4 3

LAST CALL: PTG April 2025 Team Signup Deadline!
by Kendall Nelson 18 Feb '25

18 Feb '25

Hello Everyone, This is your *LAST CALL* to sign your team up for the next virtual Project Teams Gathering (PTG), which will be held from Monday, April 7th to Friday, April 11th 2025! If you haven't already done so and your team is interested in participating, you need to complete the team-signup survey[1] by Feb 21st, 2025 at 7:00 UTC. Then make sure to register[2] - it’s free :) Individual registrations help us coordinate details of the event to attendees. Thanks! -Kendall (diablo_rojo) [1] Team Survey: https://openinfrafoundation.formstack.com/forms/ptg_april_2025_survey [2] PTG Registration: http://ptg.openinfra.dev/

1 0

Cinder volume service and high availability question
by Jim Kilborn 18 Feb '25

18 Feb '25

Hello, I am trying to figure out how to get cinder volume service to use a virtual name for the cinder volume host. We have three controllers that are setup with keepalived and haproxy with a virtualized servername that is used in the various openstack .conf files. This allows either server to shutdown and we can still access the web interface, create vms and volumes, etc. because the virtual hostname is used in all the configurations. However, for cinder volumes, it puts the hostname of the server in os-vol-host-attr:host rather than my virtual name. This causes issues if the controller that was used to create the volume is down, we can't easily manage the volume without modifying that field in the cinder database. If the virtual name could be used, either server could manage the volume with the backend, with no manual changes to the db. The only server related setting in my cinder.conf is my_ip, and that is the ip of the actual server, not the virtual ip Is active/active cluster not supported with cinder?

2 1

[horizon] Automatic refresh of page elements/content
by dbarrosf＠windriver.com 18 Feb '25

18 Feb '25

Hi everyone, I would like to query about implementing a feature: Automatic refresh of page elements/content on openstack dashboard (horizon). I'm a developer working on starlingx dashboard (gui) project, which is based on openstack dashboard. We noticed that all content on starlingx dashboard doesn't get updated if a change occurs. So, as a workaround, a full page reload is required. We have added a patch to customize horizon package and enable automatic refresh in some of the content. But this is not a definitive solution, since it doesn't solve auto refresh for all page elements/content: https://review.opendev.org/c/starlingx/upstream/+/941145 We also noticed errors on browser's console related to mutation events, although I'm not sure this is relevant for the discussion: https://bugs.launchpad.net/horizon/+bug/2098785 Do you have any plans to add such a feature? Or should we submit a blueprint? Thank you for your time. Regards, Davi Frossard

1 0

[horizon] Automatic refresh of page elements/content
by Barros Frossard, Davi 18 Feb '25

18 Feb '25

Hi everyone, I would like to query about implementing a feature: Automatic refresh of page elements/content on openstack dashboard (horizon). I'm a developer working on starlingx dashboard (gui) project, which is based on openstack dashboard. We noticed that all content on starlingx dashboard doesn't get updated if a change occurs. So, as a workaround, a full page reload is required. We have added a patch to customize horizon package and enable automatic refresh in some of the content. But this is not a definitive solution, since it doesn't solve auto refresh for all page elements/content: https://review.opendev.org/c/starlingx/upstream/+/941145 We also noticed errors on browser's console related to mutation events, although I'm not sure this is relevant for the discussion: https://bugs.launchpad.net/horizon/+bug/2098785 Do you have any plans to add such a feature? Or should we submit a blueprint? Thank you for your time. Regards, Davi Frossard

1 0

BaaS
by Odil Yusupov 18 Feb '25

18 Feb '25

As I researched there is no solution for backing up openstack virtual machines. What is the best way to organize BaaS on openstack environment? I have used snapshots and converted them to images, but this is not production solution. Thank you for your support

6 6

[octavia] Blocking a specific network for the VIP of LBs
by Thomas Goirand 18 Feb '25

18 Feb '25

Hi there! In our setup, we offer to our customers, on top of floating IPS, access to an OpenStack internal network that contains public IPs. The idea is that they can, using this network, spawn VMs with a public IP directly on the NIC of their VMs. The issue is, some customers also use this network for the VIP of their LBs. While this seems to work, actually, instead of reserving a single public IP address, it reserves 3 IPs. Not a big deal for us, as they are billed internally, though it's rather bad for our customers. On top of that, whenever one of the subnet of this network becomes full, it becomes impossible to failover amphoras spawned in this subnet. Each time one runs into ERROR, it's kind of a bad situation where we have no way to fix, except contacting the customer and ask them to fix their setup. So we advise our customers to spawn a port first, use that port for the LB, and associate a floating IP address to the original port. This is described in our doc here: https://docs.infomaniak.cloud/network/loadbalancer_usecase_simple_http/ However, as you may know, customers never read the docs. And therefore, we'd like to forbid the use of that shared OpenStack internal network for the VIP of LBs. But as much as possible, this isn't a feature of Octavia. Is it? I'd like to implement the feature. What's the best way to do so? Would a new "forbidden_networks" directive would do, and then have a check at the API level? Or is there a better way using the API policy? Also, wouldn't it be possible that Octavia just reuse the ports that it currently hold, rather than asking new ports for the failover? If so, any clue where the code that does that could be fixed? I'd love to have this fixed AND the forbid network feature too... Cheers, Thomas Goirand (zigo)

4 3

[tc][election] mnasiadka TC candidacy for 2025.2
by Michał Nasiadka 18 Feb '25

18 Feb '25

Hello, I'd like to announce my candidacy for the Technical Committee. This is would be my first TC term (I have never applied for a TC seat). My relations with OpenStack started around Liberty release as a user and Ocata as a Kolla developer. Since Yoga release I became PTL for Kolla (that also includes Kolla-Ansible and Kayobe). I'm also a core reviewer for the Magnum project and diskimage-builder. Throughout my commercial career I've been working with OpenStack clouds in service provider (including VMware and Microsoft hypervisors managed by OpenStack), telco and HPC environments - which give me a broad view of the different use cases for running a cloud. Due to my PTLship of a deployment project - I will probably be focused on operators' perspective and cloud managability aspects - which if possible I'd like to improve - and by that also improve the overall experience of using OpenStack. Thank you for considering my candidacy, Regards, Michal Nasiadka

1 0

Issues with installing Zun on Compute node
by Milan M 18 Feb '25

18 Feb '25

I was trying to install openstack 2024.2 zun on compute node. and following the page https://docs.openstack.org/zun/2024.2/install/compute-install.html for installation. I am facing the issue of docker "--cluster-store" support. I am using Docker 27.5 version. Reading the documentation online, i am confused. Some places it is, mentioned that it is fixed. and some places it suggest to uses docker 22. At few places in your mail you have mentioned to stop using kuryr and use CNI. And official documentation still says to use --cluster store. What is the current state and the correct solution. Please guide me.

1 0

[openstack-helm] [Ceilomter] Image docker.io/kolla/ubuntu-source-ceilometer-api:wallby does not exist
by daniel890723＠gmail.com 17 Feb '25

17 Feb '25

Hello daniel here Recently we somehow has to test the telementry for Openstack right now we have the promethues Openstack-exporter set up and works pretty well but when installing ceilometer it shows the image does not exist search the repository and seems like the ubuntu-source-ceilometer-api image only support up to ocata and the ceilometer Chart for openstack-helm hasn't been up date for a while Do you guys still support ceilometer? or it's better to just stick with promethues? Daniel

2 2

vm migration
by engineer2024 17 Feb '25

17 Feb '25

I am testing vm migration manually using virsh from one compute node to another: --- nova@ccompute:~$ virsh migrate instance-0003457f0 qemu+ssh://<remote-ip>/system --live --verbose --unsafe error: Unable to open file: /var/lib/nova/instances/f4d4r423r4d/console.log: No such file or directory nova@ccompute:~$ ll /var/lib/nova/instances/f4d4r423r4d/ drwxr-xr-x 2 nova nova 4096 Feb 17 15:43 ./ drwxr-xr-x 14 nova nova 4096 Dec 16 22:31 ../ -rw------- 1 nova root 56864 Feb 17 15:43 console.log -rw-r--r-- 1 libvirt-qemu kvm 1154624 Feb 17 15:35 disk -rw-r--r-- 1 nova nova 79 Dec 16 22:30 disk.info ------ I am doing the above as 'nova' user. Why is it failing even though it has r/w access to the console file ? Thanks elinux

5 7

[openstack-helm] Vasyl Saienko as new core reviewer
by Vladimir Kozhukalov 17 Feb '25

17 Feb '25

Hi dear helmers, I would like to suggest a new member of the Openstack-Helm core team. Vasyl Saienko from Mirantis has been actively contributing to the project recently. He prepared lots of improvements for Mariadb, Memcached, Libvirt, Rabbitmq and other charts. He also made plenty of valuable code reviews (28 reviews for the last 90 days). Please share you opinion on this. -- Best regards, Kozhukalov Vladimir

4 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-6)
by Goutham Pacha Ravi 17 Feb '25

17 Feb '25

Hello Stackers, We're six weeks away from the coordinated 2025.1 ("Epoxy") release [1]. The next couple of weeks are chock-full of release deadlines. We're closing the nomination period for the OpenStack PTL+TC elections on 2025-02-19 at 23:45 UTC [2]. If you're looking to lead a project team or join the OpenStack TC, do nominate yourself at the earliest. Election officials will also be generating electoral rolls at this deadline. To ensure you are able to vote, please confirm that you've signed up for emails from the CIVS voting platform before that deadline: https://civs1.civs.us/cgi-bin/opt_in.pl In the past week, the OpenStack Technical Committee defined an Upstream Investment Opportunity for the year [3]. The community is actively looking for organizations to sponsor a Quality Assurance developer to augment the OpenStack QA team. Since the team has a far-reaching impact on the quality and maintainability of all OpenStack software, support would be most appreciated. The TC also defined the Tested Runtimes for the 2025.2 ("Flamingo") release cycle. This will be a non-SLURP release and we are expanding testing with Python 3.13 while simultaneously dropping support for Python 3.9 [4]. A number of other governance proposals remain under community review. Finally, the TC expressed support for the proposal to move the OpenInfra Foundation under the Linux Foundation. This conversation is ongoing, and several important concerns have been raised and answered [5]. === Weekly Meeting === The TC meeting last week was held over IRC, and it was well attended [6]. We followed up on several long-running tasks, including the maintenance of the "openstackdocstheme" and "os-api-ref" repositories. Both of these are widely used across OpenStack documentation; however, we need more code reviewer attention to get some critical maintenance patches in. We discussed fixes to the election roll generation scripts to expand the list of repositories used to collate contributors. We'll follow up on this before the electoral roll generation deadline [2]. Dr. Jens Harbott (frickler) discussed the effort to transition "unmaintained/wallaby" branches across OpenStack repositories to "end-of-life." He proposed the change this week [7], and we have until 2025-03-14 to make any modifications to the patch. The final topic was a strategic consideration regarding the OpenInfra Foundation potentially joining the Linux Foundation. Several important concerns were raised during the meeting. One key concern was the LF's recommendations to limit contributions from certain countries. These restrictions currently exist within the OpenInfra Foundation as well. By joining forces with LF, Jonathan Bryce (jbryce) mentioned that he was "hopeful we can have a bigger impact on getting these regulations to view open source properly." The next meeting of the OpenStack TC is today, 2025-02-18. It will be held via IRC on OFTC's #openstack-tc channel at 18:00 UTC. Please find the agenda in the meeting wiki [8]. I hope you'll be able to join us! === Governance Proposals === ==== Merged ==== - Define 2025 upstream investment opportunities | https://review.opendev.org/c/openstack/governance/+/939507 - Define testing runtime for 2025.2 release | https://review.opendev.org/c/openstack/governance/+/941141 - Propose Extra-ACs from I18n SIG (2025.1) | https://review.opendev.org/c/openstack/governance/+/941743 ==== Open for Review ==== - Deprecate ironic-lib | https://review.opendev.org/c/openstack/governance/+/939278 - Cleanup policy popup leads list | https://review.opendev.org/c/openstack/governance/+/941148 - Switch Ironic to Distributed Leadership | https://review.opendev.org/c/openstack/governance/+/941935 - Add Watcher project update liaison | https://review.opendev.org/c/openstack/governance/+/940168 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === - 2025-02-19: Nominations submission deadline for 2025.2 TC/PTL Elections: https://governance.openstack.org/election/ - 2025-02-28: 2025.1 ("Epoxy") Feature Freeze and release milestone 3 [1] - 2025-03-06: SCALE 2025 + OpenInfra Days NA (https://www.socallinuxexpo.org/scale/22x) - 2025-03-11: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-04-07: OpenInfra PTG Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] OpenStack Election Website: https://governance.openstack.org/election/ [3] QA Developers Needed: https://governance.openstack.org/tc/reference/upstream-investment-opportuni… [4] Tested runtimes for 2025.2: https://governance.openstack.org/tc/reference/runtimes/2025.2.html [5] Help us shape the OpenInfra Foundation's next chapter: https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… [6] TC Meeting IRC Log 2025-02-11: https://meetings.opendev.org/meetings/tc/2025/tc.2025-02-04-18.00.log.html [7] Transition unmaintained/wallaby to EOL: https://review.opendev.org/c/openstack/releases/+/941458 [8] TC Meeting Agenda, 2025-02-18: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[manila][election] Carlos da Silva candidacy for 2025.2 Manila PTL
by Carlos Silva 17 Feb '25

17 Feb '25

Hello zorillas and interested stackers, I would like to announce my candidacy to be Manila PTL over the 2025.2 (Flamingo) cycle. I have been working with these amazing contributors and community members for many cycles. If elected, this will be my 6th cycle as a PTL. We shared a lot of accomplishments and faced lots of challenges together. We have continuously been delivering features, fixes, and enhancements requested by operators. We are making solid progress on enhancing the review bandwidth by actively adding more people to the core team and promoting engaging activities around reviews, to get more traction. We have also been closing the gap on the Manila UI features, implementing OpenAPI schemas, integrating manila with OpenStack SDK and enhancing our documentation. For the next cycle, I would like to continue what we have been doing, but also focus on: * Tech debt: continue the efforts to get parity between Manila APIs and Manila UI, complete the rootwrap->privsep migration. * Eventlet: python-manilaclient is successfully migrated, and we will continue the process for all other manila repositories. * Ensuring we are making progress on the integration Barbican and the implementation of share encryption. * Work with the contributors to ensure we have healthy testing jobs for first party CI drivers. Thank you for your consideration. Carlos da Silva IRC: carloss

1 0

[tc][election] gouthamr's TC Candidacy for 2025.2
by Goutham Pacha Ravi 17 Feb '25

17 Feb '25

Hello Stackers, I am submitting my candidacy for another term on the OpenStack Technical Committee. Over the past year, I had a rare privilege of being a first-time TC member, and its Chair. I was lucky to have enormous support from the team and past chairs to be effective. Over this time, I fostered open, consensus-driven discussions, making my best effort to let every voice be heard and ensure that governance is accessible to all contributors. I worked to bridge the gap between the community and the TC through weekly summary emails, and engagement with contributors at PTGs, in-person events and online meetings. TC decisions are more transparent and inclusive in the process. I advocated for contributor initiatives, conducted onboarding workshops, promoted internships, and helped connect contributors and project leadership. I assisted in the revival of project teams, improving election processes, securing project trackers, and OpenStack’s presence on PyPI and Launchpad. This ensured that our community was a reliable and well-maintained ecosystem for its users and contributors. Beyond community engagement, the TC I was part of collectively made meaningful governance changes to direct our limited resources to high-impact areas, things that were more important to the community, than any single contributing organization. I will continue pushing for this, with a bias toward strengthening the community. Looking ahead, my priorities for the next year include grooming the next set of OpenStack leaders, furthering cross-community collaboration, driving work that ensure OpenStack’s continued relevance, including a sustained focus on critical community goals and improvements. I'm excited to support the OpenInfra community as a project leader should OpenStack and OpenInfra projects move under the Linux Foundation. I believe OpenStack thrives because we've created a welcoming, productive environment for all contributors, new and experienced alike. If re-elected, I'll ensure that OpenStack remains an inclusive, innovative, and technically strong open-source community. Thank you for your consideration. Sincerely, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/election/+/942001

1 0

Understanding update in Heat orchestration templates
by Uday Dikshit 17 Feb '25

17 Feb '25

Hello Team we are using Heat to automate orchestration of our application nodes. So please consider a case: I am running 3 nodes in the heat stack. And let's say I have made some updates in the the application code over these 3 nodes. So when I scale up the stack orchestrates and add another node but with the original image. To deal with this if I update the stack template heat rebuilds the original 3 nodes as well with the new snapshot image which makes my application to be unavailable during the update process. It would be really helpful if anybody could put in some ideas around this on how work this case around? Thanks in advance Uday Dikshit

1 0

[elections][ptl][keystone] Stepping down as PTL
by Dave Wilde 17 Feb '25

17 Feb '25

Hello, Due to a recent change in my career path I’ve come to the difficult decision that I need to step down as the Keystone PTL. Over the past 4 years as the PTL the Keystone project has really come a long way, from the establishment of reviewathons and an engaged team of core reviewers to the implementation of some long sought after features and a clean up and modernization of the codebase. This is all due to some very dedicated folks and I’ld like to pass on my personal thanks to them for all of the hard work. Keystone is at a very interesting point in it’s history and I think the future holds bright things for the project, I would like to still be involved but due to the time constraints of my new position I no longer have the bandwidth to manage the day to day aspects of such a large project. I’m looking forward to helping whoever takes the reins in whatever ways that I can. Thanks again, it’s been a pleasure. /Dave

1 0

[blazar][elections][ptl] Leaving the PTL role
by Pierre Riteau 17 Feb '25

17 Feb '25

Hello Blazar community, Having been Blazar PTL since the Stein cycle, it is time to pass the torch to someone else. I would be happy to help the new PTL with their duties, especially during their first cycle. I will stay involved in the community anyway. Cheers, Pierre Riteau (priteau)

1 0

[neutron] Bug deputy report (week starting on February 10)
by Elvira Garcia Ruiz 17 Feb '25

17 Feb '25

Hi folks! Here you have the list of bugs reported for Neutron during last week (10 Feb - 16 Feb). There is one Undecided bug because I'm unsure on how to prioritize it, so we can discuss it at tomorrow's meeting if that is ok. Critical --------- - https://review.opendev.org/c/openstack/neutron/+/941511 Regular user can modify router SNAT flag Fix proposed by Rodolfo: https://review.opendev.org/c/openstack/neutron/+/941511. Rodolfo noted this might need more than just this patch. High ------ - https://bugs.launchpad.net/neutron/+bug/2098085 SRIOV mechanism driver may attach to the wrong segment where a host has access to multiple segments of the same network Assigned to Andrew Bonney Incomplete --------------- - https://bugs.launchpad.net/neutron/+bug/2097747 neutron not update ovn routers Undecided --------------- - https://bugs.launchpad.net/neutron/+bug/2098621 ports can attempt to bind to the wrong segment Best regards, Elvira

1 0

[all][elections][ptl][tc] Combined PTL/TC 2025.2 cycle Election Nominations Last Days
by Sławek Kapłoński 17 Feb '25

17 Feb '25

Hi, A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Feb 19, 2025 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at[1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. All members of the community are encouraged to confirm their email address and opt in to the CIVS election as described at: https://governance.openstack.org/election/#electorate Election statistics[2]: Nominations started @ 2025-02-05 23:45:00 UTC Nominations end @ 2025-02-19 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 2 days, 13:41:25 Nominations progress : 81.64% --------------------------------------------------- Projects[1] : 40 Projects with candidates : 15 ( 37.50%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 25 (Barbican Blazar Cinder Cloudkitty Glance Heat Ironic Keystone Manila Masakari Monasca Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms Oslo Puppet_OpenStack Quality_Assurance Storlet s Sunbeam Swift Tacker Telemetry Vitrage Zaqar) --------------------------------------------------- TC Candidates : 1 (5 Required) =================================================== Stats gathered @ 2025-02-17 10:03:35 UTC This means that with approximately 2 days left, 25 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.opendev.org/q/project:openstack/election+is:open+file:candid… have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] Support for Portworx
by Waines, Greg 16 Feb '25

16 Feb '25

Does anyone know how to use a https://portworx.com/ kubernetes-based storage solution as the storage backend for Cinder ? There is a Pure Storage driver listed in https://docs.openstack.org/cinder/latest/configuration/block-storage/volume… . https://docs.openstack.org/cinder/latest/configuration/block-storage/driver… BUT I do NOT believe this is the correct driver for interfacing with an https://portworx.com/ storage cluster. AND Neither the portworx documentation site ( https://docs.portworx.com/ ) nor the portworx github ( https://github.com/portworx ) have any information about integration with Cinder or OpenStack. ( ... although I believe it used to ... ) any info would be appreciated, Greg.

2 2

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 16 Feb '25

16 Feb '25

Hello everyone, As you might know, the Monasca project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Monasca retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

6 17

[kolla-ansible]how to set ovn_cms_opts in non gateway chassis
by Satish Patel 15 Feb '25

15 Feb '25

Folks, I have 3 controller nodes and they are gateway nodes also but now I want to add 2 more compute nodes who will have the following flag to handle external port traffic to reply to DHCP for sriov nodes. $ ovs-vsctl set open_vswitch . external_ids:ovn-cms-options="enable-chassis-as-extport-host" How and where do I tell kolla-ansible to put the above option for those 2 new compute nodes so options will survive re-deployment.

2 2

[ironic][nova] deploying VMware ESXi
by Doug Goldstein 14 Feb '25

14 Feb '25

Hello all, I’ve got a need to boot bare metal machines with VMware ESXi. ESXi 7 and newer is resistant to an image that can be reused like other OS images are used from Nova. As I mentioned it’s a bare metal machine so I’m working with Ironic but ultimately looking to drive this via Nova (through the Ironic hypervisor backend). Coming up empty in my Google-fu for an example of someone doing this so I figured I’d crowd source asking the ML. Right now I’m able to get an ISO of a system and it’s using VMware’s “weasel” installer which appears to be a fork/related to Anaconda and using Kickstart. Ironic supports an Anaconda deploy mechanism but the files are different and so it won’t just work out of the box (there is no stage2 but instead like 80 individual files) so my plan is to make a “weasel” deploy mechanism for Ironic. But just wanted to see if someone had any better approaches or ideas before I plod forward. Thanks. — Doug

1 0

[release] Release countdown for week R-6, Feb 17 - 21
by Elõd Illés 14 Feb '25

14 Feb '25

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on February 20th, 2025. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2025.1 branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (February 27th, 2025) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, February 27th, 2025. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2025.1 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2025.1 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2025.1 Epoxy will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 20th, 2025 (R-6 week) Client library freeze: February 27th, 2025 (R-5 week) Epoxy-3 milestone: February 27th, 2025 (R-5 week) Cycle Highlights Due: March 6th, 2025 (R-4 week) 2025.1 Epoxy final release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[charms][elections][ptl] PTL non-candidacy
by James Page 14 Feb '25

14 Feb '25

Hi OpenStack Charmers Due to some changes in my focus I won't be standing as PTL for the OpenStack Charms project for the upcoming cycle. Thanks James

1 0

[neutron] Drivers meeting agenda for Friday, February 14th
by Brian Haley 13 Feb '25

13 Feb '25

Hello Neutrinos: Sorry for the late notice but this is the agenda for tomorrow's drivers meeting: * Router PUT behavior discussion: - https://review.opendev.org/c/openstack/neutron/+/941511 - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/941545 Not an RFE, but something Rodolfo wanted to talk about based on a recent bug. See you then, -Brian

2 1

[Neutron] Router external GW info policies bug
by Rodolfo Alonso Hernandez 13 Feb '25

13 Feb '25

Hello all: Yesterday I opened a bug because of an issue in the router's external GW info policies: https://bugs.launchpad.net/neutron/+bug/2098109. At the end of the day I found that the issue is more complicated than the trivial fixes I proposed. NOTE: I've reverted two backports of a patch that was not merged in master branch. I've also -W the patches proposed. I would like you to read https://bugs.launchpad.net/neutron/+bug/2098109/comments/11, that describes the current issue. Today I'm going to propose several patches to fix that problem, first in n-lib to fix the definitions and then in Neutron, to implement the needed policies for these new actions and their sub-attributes. Please don't hesitate to ping me in IRC for more info. @Brian Haley <haleyb.dev(a)gmail.com> I don't think it will be needed to add this topic to the drivers meeting. I think I've better described it in the bug comment and we can continue any discussion offline. So I think we can remove the section you added; it will be better to "digest" this info reading the bug and commenting async in IRC. Regards.

1 0

[nova] How to gain approval for a new feature on unavailable hardware
by taketani.ryo＠fujitsu.com 13 Feb '25

13 Feb '25

To Whom It May Concern, We are considering to propose and develop a new feature on OpenStack Nova for building Arm Confidential Computing Architecture (Arm CCA)-encrypted instances. I have some questions for doing it. * While specification of Arm CCA is already open(https://developer.arm.com/documentation/den0125/0300/Overview), No Arm CCA-enabled hardware is currently available to our knowledge. Therefore, we plan to conduct testing in an internal environment. * Would a proposal for a feature utilizing publicly unavailable hardware be acceptable to OpenStack? Alternatively, in this case, what steps or preparations are required for approval? * Should the blueprint and specification be submitted simultaneously? * The specification is currently incomplete. Building Arm CCA instances requires libvirt APIs, similar to AMD SEV instances(https://blueprints.launchpad.net/nova/+spec/amd-sev-libvirt-suppo…, but specification of these are not yet determined publicly. We are considering submitting the blueprint first to inform the community of our ongoing development efforts. Regards

3 6

#eventlet-removal Meeting canceled - Feb 18
by Herve Beraud 13 Feb '25

13 Feb '25

Hey folks, The coming meeting (Feb 18) is canceled. The next meeting will be on March 04. For more details about meetings: - https://etherpad.opendev.org/p/epoxy-eventlet-tracking - https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events Thanks for your attention. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[ironic][elections][ptl] Leaving the PTL role
by Riccardo Pittau 13 Feb '25

13 Feb '25

Hello ironicers! It's been a pleasure and an honor to serve as PTL for 2 cycles. I've decided to not be a candidate for the next cycle, mainly because of time constraints. Huge thanks to the community for having me, I hope in the future I'll be able to repeat the experience. Ciao! Riccardo #irc rpittau

9 18

[manila] Postpone Removal of Standalone CephFS NFS helper
by Ashley Rodriguez 12 Feb '25

12 Feb '25

Hi all! As per subject line, after some discussions on this mailing list and during our mid-cycle review, we have decided to postpone the deprecation of the standalone CephFS NFS protocol helper in Epoxy. This gives administrators a little more time to migrate to the ceph-orch-deployed clustered NFS service, at least until the next SLURP Release AKA "G" cycle. In the meantime, we will continue to maintain the associated CI for standalone NFS-Ganesha as best we can. Please understand that our focus is on clustered deployments, and we welcome any assistance offered. To assist migration, admins can configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside the required "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" export location metadata key set to False. We encourage folks interested to join us at the "All things CephFS" discussion during the upcoming PTG within the Manila room. Details regarding the exact scheduling will be shared closer to the event. Best, Manila Team

1 0

[all] [diversity] Looking for sponsors for Outreachy 2025
by Dmitry Tantsur 12 Feb '25

12 Feb '25

Hi folks, As some of you might have noticed, OpenStack did not participate in the December 2024 cohort of Outreachy (a DEI program providing paid internships to people from underrepresented or discriminated groups). This was because we could not find anyone to sponsor our participation. It looks like the situation might not improve at all in 2025. If so, I think it will be over for OpenStack in Outreachy. I'd like to ask companies developing or using OpenStack and caring about DEI to step in. We're talking about $8000 per intern, more details in https://www.outreachy.org/docs/community/#intern-funding. OpenStack had been very active in Outreachy before the last round. You can check it for yourself by searching for "OpenStack" on https://www.outreachy.org/alums/2024-05/ and the previous rounds. I'd like to keep it this way. Can we do it together? Please reach out to Mahati and me if you can help. Thank you! Dmitry

4 5

[nova][elections][ptl] Application for the PTL role
by René Ribaud 12 Feb '25

12 Feb '25

Hello, I would like to run for the PTL election for Nova and Placement. I am fortunate to be employed by Red Hat to work on this project, and I have been doing so for about three years. This means I am quite familiar with the project's processes and codebase, though I wouldn’t call myself an expert. To be honest, I initially thought of becoming a core member before running for this election. However, knowing that Sylvain wants to step down, and after discussing it with him and other members of the community, I realized that becoming PTL, while challenging, is a viable path and a great opportunity. I know this role will push me out of my comfort zone and require me to work on areas where I have less experience. But I believe that sometimes, growth comes from facing new challenges. So, I took a deep breath and decided to write this message. Regarding the future of the project, my goal is not to revolutionize anything. I believe I will need some time to find my footing, and I will do my best to continue in the direction that Sylvain has set. It won’t always be easy, but I trust in the kindness of those involved in this project to support me. I also rely on Sylvain’s mentoring, as he proposed during his candidacy, to ensure a smooth transition. One aspect I intend to be particularly mindful of is supporting contributors in getting their code merged. Having recently merged a major feature (virtiofs) that I carried for a long time, I know how difficult and demanding the process can be—it requires a lot of resilience. That’s why I'll pay attention to making this process smoother and support contributors as effectively as I can. Thanks, René

5 6

cinder volumes
by engineer2024 12 Feb '25

12 Feb '25

Is there a feature in openstack as of now, where we can specify an option while vm creation, which suggests the cinder to automatically use from the pool of available volumes for that project, instead of creating new volumes ? As of now, we need to explicitly specify a volume id to be attached to the vm after creation.. Thanks elinux

2 1

[Glance]Cancelling Weekly Meeting (Feb 13)
by Mridula Joshi 11 Feb '25

11 Feb '25

Hello, Cancelling this week's weekly meeting, As most of the members are not around. Thanks, Mridula Joshi

1 0

openstack instances unable to reach the internet
by collinl＠churchofjesuschrist.org 11 Feb '25

11 Feb '25

I have been banging my head on this issue for quite some time now. I am hoping that somebody can help me see what I have misconfigured. Here is the situation. I have tried setting up several openstack installs, and in none of them am I able to reach the internet from the instances running inside of openstack. All of them are on Rocky Linux 9.5, running the dalmatian version of openstack, installed using packstack. (I have tried an all-in-one, with everything on a single node, and a cluster with the controller/networking on one node, and the compute running on separate nodes). I can get the cirros instances running on the backend network within openstack, and can ssh to them via the floating ip from the host without issues. The cirros instance can ping other cirros instances in the openstack controlled network (both on the backend network(subnet is in the 192.168.100.0/24 range, or on the external public network(subnet is in the 172.24.4.024 range) Even trying the simplest configuration, where everything is all on a single node (compute/networking/controller/etc), Everything from instance creation to VM migration/etc all seems to work just fine. However, the cirros instances cannot ping anything on the internet -- for example, I am unable to ping 8.8.8.8 or even the gateway that the host can reach (The host has an ip used to reach horizon on the 10.61.157.0/24 subnet on our internal lan) I can ping all interfaces from the cirros interface through the backend_network (192.168.100.0/24) through the public interface (172.24.4.0/24), and can even ping the host ip address (10.61.157.59) . . .However, I can't ping anything beyond that (i.e. the 10.61.147.1 gateway does not ping from the cirros instance) From the host commandline, it is able to reach everything external just fine (i.e. it can ping it's gateway 10.61.147.1 and 8.8.8.8 or anything else external) Here is the ip addr output from the host: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:1d:d8:b7:1e:df brd ff:ff:ff:ff:ff:ff inet6 fe80::21d:d8ff:feb7:1edf/64 scope link valid_lft forever preferred_lft forever 3: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 56:d8:51:53:10:b0 brd ff:ff:ff:ff:ff:ff 4: br-int: <BROADCAST,MULTICAST> mtu 1442 qdisc noop state DOWN group default qlen 1000 link/ether 62:8c:b0:c2:3e:5a brd ff:ff:ff:ff:ff:ff 5: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 00:1d:d8:b7:1e:df brd ff:ff:ff:ff:ff:ff inet 10.61.157.59/24 brd 10.61.157.255 scope global br-ex valid_lft forever preferred_lft forever inet 172.24.4.1/24 brd 172.24.4.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::2446:29ff:fe58:6541/64 scope link valid_lft forever preferred_lft forever 6: tapeffe7cc1-56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1442 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000 link/ether fe:16:3e:e2:66:5d brd ff:ff:ff:ff:ff:ff inet6 fe80::fc16:3eff:fee2:665d/64 scope link valid_lft forever preferred_lft forever 7: tap65170f1f-e0@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovs-system state UP group default qlen 1000 link/ether 3a:26:09:cf:3d:4f brd ff:ff:ff:ff:ff:ff link-netns ovnmeta-65170f1f-e837-4b5e-a471-13e783e6b48e inet6 fe80::3826:9ff:fecf:3d4f/64 scope link valid_lft forever preferred_lft forever And the output from the ovs-vsctl show command: 46294eda-8a39-4775-875d-ef6ec9929346 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-int fail_mode: secure datapath_type: system Port tap65170f1f-e0 Interface tap65170f1f-e0 Port patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24 Interface patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24 type: patch options: {peer=patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int} Port tapeffe7cc1-56 Interface tapeffe7cc1-56 Port br-int Interface br-int type: internal Bridge br-ex fail_mode: standalone Port patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int Interface patch-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24-to-br-int type: patch options: {peer=patch-br-int-to-provnet-371bdb7c-d2f3-4e70-aca9-1c4838c57e24} Port br-ex Interface br-ex type: internal Port eth0 Interface eth0 ovs_version: "3.3.1" Here is the info for the networks/subnets currently configured: From "openstack network list --long" +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ | ID | Name | Status | Project | State | Shared | Subnets | Network Type | Router Type | Availability Zones | Tags | +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ | 65170f1f-e837-4b5e-a47 | backend_network | ACTIVE | c5f408c4daed4fb2afefa4 | UP | False | b1e5aef4-77da-4b0b-9b9 | geneve | Internal | | | | 1-13e783e6b48e | | | 4fa039fe26 | | | 4-5aaf395484e0 | | | | | | b8e7a305-65f0-44ea-93a | public | ACTIVE | c5f408c4daed4fb2afefa4 | UP | False | 6cff8f70-9dc8-4f17-b78 | flat | External | | | | a-cc6ec741d408 | | | 4fa039fe26 | | | 0-32cf2aedb017 | | | | | | c0c67da4-22bf-4dd2-b4c | private | ACTIVE | 2967b1fe70794fa88cbb3d | UP | False | caed16ae-22ff-427a-a37 | geneve | Internal | | | | 2-2edcb41ffb97 | | | e7227cec77 | | | 0-6b891755bfa7 | | | | | +------------------------+-----------------+--------+------------------------+-------+--------+------------------------+--------------+-------------+--------------------+------+ From "openstack subnet list --long" +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ | ID | Name | Network | Subnet | Project | DHCP | Name Servers | Allocation Pools | Host Routes | IP Version | Gateway | Service Types | Tags | +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ | 6cff8f70-9dc8 | public_subnet | b8e7a305-65f0 | 172.24.4.0/24 | c5f408c4daed4 | False | | 172.24.4.2-172.2 | | 4 | 172.24.4.1 | | | | -4f17-b780-32 | | -44ea-93aa- | | fb2afefa44fa0 | | | 4.4.254 | | | | | | | cf2aedb017 | | cc6ec741d408 | | 39fe26 | | | | | | | | | | b1e5aef4-77da | backend_subne | 65170f1f-e837 | 192.168.100.0 | c5f408c4daed4 | True | | 192.168.100.100- | | 4 | 192.168.100.1 | | | | -4b0b-9b94-5a | t | -4b5e-a471-13 | /24 | fb2afefa44fa0 | | | 192.168.100.250 | | | | | | | af395484e0 | | e783e6b48e | | 39fe26 | | | | | | | | | | caed16ae-22ff | private_subne | c0c67da4-22bf | 10.0.0.0/24 | 2967b1fe70794 | True | | 10.0.0.2-10.0.0. | | 4 | 10.0.0.1 | | | | -427a-a370-6b | t | -4dd2-b4c2-2e | | fa88cbb3de722 | | | 254 | | | | | | | 891755bfa7 | | dcb41ffb97 | | 7cec77 | | | | | | | | | +---------------+---------------+---------------+---------------+---------------+-------+--------------+------------------+-------------+------------+---------------+---------------+------+ From "openstack floating ip list" +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ | ID | Floating IP Address | Fixed IP Address | Port | Floating Network | Project | +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ | 61d98a1c-f19a-451f-9353-6cb8305a0c | 172.24.4.175 | 192.168.100.128 | effe7cc1-566d-4574-b4e3-d9f440b776 | b8e7a305-65f0-44ea-93aa- | c5f408c4daed4fb2afefa44fa039fe26 | | 2f | | | 5e | cc6ec741d408 | | +------------------------------------+---------------------+------------------+------------------------------------+------------------------------------+----------------------------------+ From "openstack server list" +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ | e42372d2-946d-4c90-bf2d-1e36cda80e2f | test3 | ACTIVE | backend_network=172.24.4.175, 192.168.100.128 | N/A (booted from volume) | m1.tiny | +--------------------------------------+-------+--------+-----------------------------------------------+--------------------------+---------+ Any assistance in helping me figure out what I am missing to get external access would be greatly appreciated. Thank you!

4 14

Flat openstack network
by Mateusz Woźniakowski 11 Feb '25

11 Feb '25

Good day, I have a question, how to configure neutron in openstack kolla, so as not to make a vrouter but to make a flat network and pass vlans to openstack and make a public network directly in openstack kolla. at the moment I have it on vrouter but it is not a good solution for me. and I would need to set up several networks in openstack Could someone suggest where to find it and how to set it up?

2 3

Building kolla-ansible in china region
by Satish Patel 11 Feb '25

11 Feb '25

Folks, I am trying to build kolla-ansible in China but somehow my docker repository not accessible. I understand geo location and the great firewall. Does anyone know if there is any local china repo or docker hub which I can use in that region to build the openstack. # docker run -d --network host --name registry --restart=always -e REGISTRY_HTTP_ADDR=0.0.0.0:4000 -v registry:/var/lib/registry registry:2 Unable to find image 'registry:2' locally docker: Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers). See 'docker run --help'.

4 4

[kolla-ansible] why swift deployment support has been deprecated for removal in 2025.2?
by Sara khosravi 11 Feb '25

11 Feb '25

Hello everyone, I’m new to Kolla-Ansible. I have used Swift with a simple Ansible playbook and have tested with GitLab CI. But now I’m following the CI/CD procedures in Kolla-Ansible. I’m trying to understand why swift deployment support has been deprecated for removal in 2025.2. I’m having trouble finding the exact failure points in the CI pipeline related to the Swift role, and I can’t seem to find any clues about failures that occurred in the CI process. I really appreciate any help you can provide.

2 1