January 2025 - openstack-discuss - lists.openstack.org

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

08 Dec '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 14

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

08 Nov '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

5 8

[openstack][kolla-ansible]about group node config overwrite
by Nguyễn Hữu Khôi 30 Oct '25

30 Oct '25

Hello Koller. I want to ask if we can overwrite config for a group of nodes. For example, compute01 >> compute10 will have the same nova configuration compute11 >> compute20 will have the same nova configuration. It will be very nice if we support this way. Thank you. Regards Nguyen Huu Khoi

4 7

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

22 Oct '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

3 5

[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

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

25 Jun '25

5 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 02 May '25

02 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

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

17 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

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

25 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

[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

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

14 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

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

12 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

[openstack][manila][cephfs]About access rule
by Nguyễn Hữu Khôi 11 Feb '25

11 Feb '25

Hello. I setup Manila with Cephfs driver-CephFS NFS shares and I use NFS-Ganesha based “ceph nfs” service. I can create a share and can mount after creating access rule: openstack share access create cephnfsshare ip 10.10.11.76 But I can mount my share from any ip. Is it a bug, or do I understand it wrong? My env: Openstack 2024 with Kolla-Ansible deployment Ceph Quincy Thank you. Regards Nguyen Huu Khoi

2 12

[freezer] Moving project bug tracker to launchpad
by Dmitriy Rabotyagov 06 Feb '25

06 Feb '25

Hey there, In order to simplify and align with most OpenStack projects on bug tracker I aim to move Freezer from different Storyboard [1] projects back to unified Launchpad [2] tracker. However, historically the OpenStack Administrators [3] group was not added as Freezer project administrator/owner on Launchpad, which means that no current maintainer of the project has the necessary rights to manage the mentioned Launchpad project. I've added all current Launchpad admins for Freezer project to CC of this email, to either of you to add "openstack-admins" [3] to the Freezer Drivers [4] team, so that OpenStack Infra team could assist with further recovering/managing access to the Launchpad project. That will be very nice if some of you could spend couple of minutes on making this change and help us avoid cumbersome process of recovering access to the project Thanks in advance! [1] https://storyboard.openstack.org/#!/project/list?q=freezer [2] https://launchpad.net/freezer [3] https://launchpad.net/~openstack-admins [4] https://launchpad.net/~freezer-drivers

4 3

Discussion of OpenStack development getting Error.
by Kiran Raja 05 Feb '25

05 Feb '25

Hi Team, We have deployed Open stack and when we are trying to access Neutron Gateway from the Controller node we are unable to access, but It is access able from Namespace Created in neutron , please help me on neutron configuration we are using Self-provision Network Option. root@controller:~# openstack router list +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ | ID | Name | Status | State | Project | Distributed | HA | +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ | 16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 | Admin_Router | ACTIVE | UP | 523711770d5243dd9af5b2356b540b07 | False | False | +--------------------------------------+--------------+--------+-------+----------------------------------+-------------+-------+ root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip route default via 172.16.86.1 dev qg-afb1772f-2f proto static 172.16.86.0/24 dev qg-afb1772f-2f proto kernel scope link src 172.16.86.49 root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.16.86.1 0.0.0.0 UG 0 0 0 qg-afb1772f-2f 172.16.86.0 0.0.0.0 255.255.255.0 U 0 0 0 qg-afb1772f-2f root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ping 172.16.86.1 PING 172.16.86.1 (172.16.86.1) 56(84) bytes of data. ^C --- 172.16.86.1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2042ms root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip address 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 13: qg-afb1772f-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d1:58:50 brd ff:ff:ff:ff:ff:ff inet 172.16.86.49/24 brd 172.16.86.255 scope global qg-afb1772f-2f valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed1:5850/64 scope link valid_lft forever preferred_lft forever root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ping 172.16.86.49 PING 172.16.86.49 (172.16.86.49) 56(84) bytes of data. 64 bytes from 172.16.86.49: icmp_seq=1 ttl=64 time=0.073 ms 64 bytes from 172.16.86.49: icmp_seq=2 ttl=64 time=0.113 ms ^C --- 172.16.86.49 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 0.073/0.093/0.113/0.020 ms root@controller:~# ping 172.16.86.49 PING 172.16.86.49 (172.16.86.49) 56(84) bytes of data. ^C --- 172.16.86.49 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1048ms root@controller:~# ip netns exec qrouter-16d92543-e9a3-4e97-bdb0-ccb3a8b8dd99 ip address 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 13: qg-afb1772f-2f: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d1:58:50 brd ff:ff:ff:ff:ff:ff inet 172.16.86.49/24 brd 172.16.86.255 scope global qg-afb1772f-2f valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed1:5850/64 scope link valid_lft forever preferred_lft forever 15: qr-6be4aabd-b9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:df:a9:ad brd ff:ff:ff:ff:ff:ff inet 172.16.100.1/24 brd 172.16.100.255 scope global qr-6be4aabd-b9 valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fedf:a9ad/64 scope link valid_lft forever preferred_lft forever root@controller:~# ping 172.16.86.1 PING 172.16.86.1 (172.16.86.1) 56(84) bytes of data. 64 bytes from 172.16.86.1: icmp_seq=1 ttl=64 time=0.204 ms ^C --- 172.16.86.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.204/0.204/0.204/0.000 ms root@controller:~# ip a 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 noprefixroute valid_lft forever preferred_lft forever 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:25:f8:21 brd ff:ff:ff:ff:ff:ff altname enp3s0 inet 172.16.85.11/24 brd 172.16.85.255 scope global ens160 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe25:f821/64 scope link valid_lft forever preferred_lft forever 3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:0c:29:25:f8:2b brd ff:ff:ff:ff:ff:ff altname enp11s0 inet6 fe80::20c:29ff:fe25:f82b/64 scope link valid_lft forever preferred_lft forever 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 2e:14:3b:10:5d:42 brd ff:ff:ff:ff:ff:ff 5: br-tun: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 02:fb:f2:93:65:46 brd ff:ff:ff:ff:ff:ff inet6 fe80::fb:f2ff:fe93:6546/64 scope link valid_lft forever preferred_lft forever 6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 00:0c:29:25:f8:2b brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:fe25:f82b/64 scope link valid_lft forever preferred_lft forever 7: br-int: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 72:cb:66:8a:21:4c brd ff:ff:ff:ff:ff:ff inet6 fe80::70cb:66ff:fe8a:214c/64 scope link valid_lft forever preferred_lft forever root@controller:~# ovs-vsctl show 77dc413c-c4a0-4c7a-b3e2-3ba8ecf5bee7 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-int Interface br-int type: internal Port qg-afb1772f-2f tag: 2 Interface qg-afb1772f-2f type: internal Port qr-6be4aabd-b9 tag: 3 Interface qr-6be4aabd-b9 type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port tap93e5731e-d9 tag: 2 Interface tap93e5731e-d9 type: internal Port tap52dcef2e-c9 tag: 3 Interface tap52dcef2e-c9 type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port br-ex Interface br-ex type: internal Port ens192 Interface ens192 ovs_version: "3.4.0" Thanks and Regards CH Kiran Raja M: +91 9959503256 [cid:1df6874c-4456-494d-9e7c-aa3aed63e7af]<https://pidatacenters.com/> [cid:693f6ef0-1ee9-4ea9-a345-8488a3aa8c2b]<https://harbour1.in/> kiran.raja(a)pidatacenters.com<mailto:kiran.raja@pidatacenters.com> [cid:0770d139-f2b6-424b-a451-6ad2a391a96b]

3 3

VPNaaS
by Vincent Godin 04 Feb '25

04 Feb '25

Hello, The VPNaaS provided with Openstack is a Site-to-Site VPN made to interconnect two tenants or an external gateway with a tenant network. I would like to know if there are plans to offer a VPNaaS more like a Remote VPN. This would allow Openstack users to administer their instances securely. A user could mount this VPN from a roaming device, be assigned a local IP address, and then administer the instances of his tenant. Regards Vincent

3 2

[watcher] core team expansion
by Sean Mooney 04 Feb '25

04 Feb '25

Hi everyone, As you may be aware a number of us from Redhat have been trying to revitalize the Watcher project. To enable that one of the changes that we previously discussed on the mailing list and ptg was the expansion of the core team. https://etherpad.opendev.org/p/r.79644f8f3cd04686c4f45c10aa35d8ac#L46 https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… In November the initial phase of that proposal was completed and I took an action to follow up in Q1 to see what steps are needed to rebuild a healthy core team. based on the activity of the last 90 days and the progress of work I think it is time to expand the core teams once again to enable effective maintenance and development of watcher https://openstack.biterg.io/app/dashboards#/view/95487340-6762-11e9-a198-67…:'Gerrit%20Approvals%20panel%20by%20Bitergia',filters:!(('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:watcher),type:phrase),query:(match_phrase:(project:watcher)))),fullScreenMode:!f,options:(darkTheme:!f,hidePanelTitles:!f,useMargins:!t),query:(language:lucene,query:''),timeRestore:!f,title:'Gerrit%20Approvals',viewMode:view) tiny url version of ^ https://tinyurl.com/439wzbdk https://www.stackalytics.io/?module=watcher-group the current core teams are as follows * watcher-core https://review.opendev.org/admin/groups/77cd139bd57514e98e5e694a82f7e261b47… * watcher-dashboard-core https://review.opendev.org/admin/groups/bcc8588732437ceea3533249313e6e96148… * watcher-specs-core https://review.opendev.org/admin/groups/747af616eb8748aee5b17d9493f9ebbc49e… * watcher-tempest-core https://review.opendev.org/admin/groups/09a91d8e24af9ce44b80062c4851a1d2fa3… starting in order watcher-core: https://tinyurl.com/2p8sr7u4 https://www.stackalytics.io/?module=opendev.org/openstack/watcher - add Marios Andreou - add Douglas Viroel Marios and Doug both have past experience as core reviews in other OpenStack projects (triple-o and Manilla), over the last 90 days, they have engaged in reviews of bug fixes and the development of the new Prometheus data source. watcher-dashboard-core: https://tinyurl.com/4259h8nz https://www.stackalytics.io/?module=opendev.org/openstack/watcher-dashboard - add Marios Andreou - add Douglas Viroel as with Watcher itself Doug and Marios have spent time looking at the open review for the watcher-dashboard. watcher-spec-core: is tricky as we have effective only had one spec this cycle that was written by Marios with some minor patches for ci. As watcher core is a member of watcher-spec-core, Marios and Doug will inherit review rights on the specs repo. At this time I do not see a need to make any other changes to the group membership. watcher-tempest-core: https://tinyurl.com/4nbctef8 https://www.stackalytics.io/?module=opendev.org/openstack/watcher-tempest-p… - add Chandan Kumar - add Douglas Viroel - remove Martin Kopec As many of you may know Martin has taken up a new role in Redhat outside of OpenStack and will no longer be working directly on OpenStack. Over the last 90 days, Martin and Gmann have modernized the tempest plugin significantly paying down much of the tech debt. I want to thank them for the efforts they put in to help revive Watcher this cycle and if they return to the OpenStack community in the future I will gladly welcome them back. In their stead, I am proposing adding Chandan and Doug to augment the existing core group. As agreed in the Watcher team meeting earlier today we will review this mail thread in the next Watcher IRC meeting next week. I would like to invite others to provide feedback on this proposal over the next week. In the next PTG, I will also raise the composition of the core teams for discussion. It is my hope that with these additions we will have at least 3 active reviews on all deliverables of the watcher project mitigating the current bus factor and accelerating development. Regards Sean.

1 1

[ironic]About the OS supported by Diskimage-builder
by Junya Noguchi (Fujitsu) 03 Feb '25

03 Feb '25

To whom it may concern. My name is Junya Noguchi. I have some questions about the supported OS for Diskimage-builder operation. Please respond. References https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Does it mean that the OS that says "work but receive only limited testing and support" works but is not supported? References https://docs.openstack.org/diskimage-builder/latest/ This document describes RHEL and other operating systems that are not supported in the previous question. Are these operating systems supported? Also, are there any plans to support more operating systems in the future? Best regards, Junya Noguchi

5 7

[neutron] neutron-core/networking-ovn-core consolidation
by Brian Haley 03 Feb '25

03 Feb '25

Hello Neutrinos: I noticed the other day we still have the networking-ovn-core group [0] included in the neutron-core group [1], a left-over from when we merged the OVN code into the Neutron repo in Ussuri. Most people in the networking-ovn-core group no longer contribute to Neutron, except for one - Terry Wilson (otherwiseguy). In order to cleanup a little I'm going to consolidate things and add Terry as a member of the neutron-core group, and remove the import. Since he has basically been operating as a Neutron core reviewer already for years, I don't think we need to vote on this. So welcome officially Terry! -Brian, Neutron PTL [0] https://review.opendev.org/admin/groups/ecdeda6cb5657af51f20b282cd0525cb7e6… [1] https://review.opendev.org/admin/groups/38

6 5

OpenStack BoF at FOSDEM
by Amy Marrich 03 Feb '25

03 Feb '25

Hey all, Sorry for the late promotion but we will be having an OpenStack BoF at FOSDEM[0] on Saturday at 16:00 in room AW1.121. Hope to see you there! Amy 0 - https://fosdem.org/2025/schedule/event/fosdem-2025-4885-openstack-community…

3 3

[glance][security][vmt] propose Cyril Roelandt for glance coresec
by Brian Rosmaita 31 Jan '25

31 Jan '25

I'd like to propose an update to the Glance Core Security Contacts team [0], which handles embargoed security issues for Glance project deliverables. The OpenStack Vulnerability Management Team prefers to keep the project core security teams small (because otherwise it kind of defeats the point of having embargoed private security issues). Thus, the changes I propose will keep the glance-coresec team at its current size: Add: Cyril Roelandt (croelandt on IRC). Cyril has been a Glance core since June 2021 and is a thorough and respected reviewer and developer; he also organizes the recurring Glance Review Party. Remove: Erno Kuvaja (jokke on IRC). Erno has been focusing his time away from Glance. On behalf of the Glance project team, I thank Erno for his past service on glance-coresec, and note that Erno continues to participate in the Glance project as a "regular" glance core. If you have any concerns about this change, please communicate them to me or Pranali Deore (Glance PTL) before 23:59 UTC on Wednesday, 29 January 2025. cheers, brian [0] https://launchpad.net/~glance-coresec

1 1

[manila] driver_handles_share_servers not recognized as boolean
by Francesco Di Nucci 31 Jan '25

31 Jan '25

Hi all, I'm running OpenStack 2024.1 Caracal, configured through Puppet, and I'm having an issue with Manila. /etc/manila/manila.conf contains the line "driver_handles_share_servers = True", but setup fails, "/var/log/manila/share.log" reports that "Config opt 'driver_handles_share_servers' has improper value - 'None'. Please define it as boolean." Has anyone encountered this? Where else should I define this? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

3 9

[all] Is oslo.vmware still relevant?
by Herve Beraud 31 Jan '25

31 Jan '25

Hey folks, I observed that oslo.vmware has not received any significant modifications since almost 4 years ago [1]. The only changes proposed to oslo.vmware since a while are just related to infra changes (python versions, tox versions, etc...). Due to the recent news about vmware [2], I wonder if oslo.vmware is still a relevant library in our context and I wonder if it is worth spending time on maintaining it. Do you think we should deprecate and retire this library? Thanks in advance for your opinions. [1] https://opendev.org/openstack/oslo.vmware/commits/branch/master [2] the broadcom story -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 6

[neutron] Drivers meeting agenda for Friday, January 31st
by Brian Haley 31 Jan '25

31 Jan '25

Hello Neutrinos: Sorry for the late notice but this is the agenda for tomorrow's drivers meeting: * [RFE] Allow rebalancing of OVN LRPs * https://bugs.launchpad.net/neutron/+bug/2096704 * We quickly discussed this in our weekly meeting and it seemed like a good idea See you then, -Brian

1 0

[manila] Feb 5th and 6th mid cycle
by Carlos Silva 30 Jan '25

30 Jan '25

Hello, zorillas and interested stackers, Manila's 2025.1 Epoxy mid cycle is right around the corner. We will meet next on February 5th and 6th, from 14 to 16 UTC on meetpad [1]. Please add your topics to the mid cycle etherpad [2]. We will use the second day of the mid cycle for collaborative review sessions, so in case you are proposing a feature or would like to have reviewers attention in a specific change, please bring it up and walk us through your change. [1] https://meetpad.opendev.org/manila-epoxy-mid-cycle [2] https://etherpad.opendev.org/p/manila-epoxy-mid-cycle Looking forward to it, carloss

1 0

OS-EXT-SRV-ATTR incomplete in compute api
by Jan 30 Jan '25

30 Jan '25

Hi, is there a reason why some member variables of the nova instance object are returned by the api and some not. For example the "os_type" value is not returned but the "kernel_id" (OS-EXT-SRV-ATTR:kernel_id) is. I have a use case where it would be very helpful to get the "os_type" via the api and python sdk. Is there a chance that a patch implementing this would be accepted? Regards, Jan

3 4

Skip upgrades
by engineer2024 30 Jan '25

30 Jan '25

Is there a way to upgrade openstack older versions like ussuri , victoria, by migrating just the nova, neutron dbs, schema to the latest version by skipping one level at once and then install the latest venvs against the latest migrated galera dbs. On the compute nodes, if we preserve just the var lib nova instances and on top of it reinstall the compute and neutron agents, will it work ? I am asking becos, I don't know what r the dependencies among the major nova versions. Are the db schema and data, the only diffs from one version to another, or is there any thing else ?

5 5

[keystone] Weekly meeting canceled 29-Jan-25
by Dave Wilde 29 Jan '25

29 Jan '25

Hi folks, Apologies for the late notice but I need to cancel the Keystone weekly meeting today due to a scheduling conflict. Please reach out either here or via IRC if you need anything. Thanks!! /Dave

1 0

[rabbitmq] Need help about RabbitMQ quorum HA mode
by İzzettin Erdem 29 Jan '25

29 Jan '25

Hi, In kolla-ansible yoga environment, rabbitmq queues are set to quorum by default instead of classical mirroring, as it seems they are not replicated (per queue has +0 quorum). We tried to find a solution to handle it in configs, but we couldn't find it and we set queues to be replicated by using CLI commands (rabbitmq-queues grow). Now, my questions are: 1- Why do all rabbitmq queues come as non-replicated by default? 2- How can we set HA mode to quorum queues?

5 5

Nova
by engineer2024 29 Jan '25

29 Jan '25

Does nova support flavors where vcpus of a single flavor can be in mixed modes where some of them are pinned and the rest dedicated ? Say, a flavor has 5 vcpus, I want 2 of them to be of dedicated type and the remaining 3 vcpus to be shared

2 2

[neutron][upgrades] IPv6 Prefix Delegation 'dibbler' driver removal
by Brian Haley 29 Jan '25

29 Jan '25

Hi again Stackers, In 2023, during the Bobcat cycle, the Neutron team changed the IPv6 Prefix Delegation (IPv6 PD) 'dibbler' driver to be an experimental feature [0]. The reason was due to it (dibbler) becoming unmaintained/retired upstream, as well as the low level of testing support we had in Neutron for the feature. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the driver from the tree [1]. The framework to support IPv6 PD is *not* being removed, but as this is the only in-tree driver the functionality will no longer be available to end-users. We plan on doing this in the current Epoxy cycle. We realize that there may be deployments using IPv6 PD, although we have not to my knowledge ever received a bug against it, so we think any usage is very small. If there is desire to add an in-tree driver back to the code base, there is an open OVN-related bug for that at [2], we have just not had the interest from downstream customers to warrant the investment in this area. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/879030 [1] https://review.opendev.org/c/openstack/neutron/+/934283 [2] https://bugs.launchpad.net/neutron/+bug/1895972

1 0

[Octavia][magnum] change timeout value
by Satish Patel 29 Jan '25

29 Jan '25

Folks, I am running magnum-cluster-api (mcapi) with openstack to spin up k8s but now I want to change octavia LB timeout. Is there a way to tell magnum to change the timeout value of LB? loadbalancer.openstack.org/timeout-client-data: "120000" loadbalancer.openstack.org/timeout-member-data: "120000"

1 0

[Nova] Nova-compute service flapping on Antelope
by Jakub Darmach 28 Jan '25

28 Jan '25

Hello, Recently I encountered an interesting issue - nova-compute service started to temporarily lose Rabbit connectivity to regain it after a few seconds on Antelope. The issue was replicated on the test environment, without specific steps to replicate though - it just starts to happen after some time. I pasted a log example in the bug I opened [1]. First we can see rabbit logging closing AMQP connection, followed by nova-compute reporting rabbit server being unreachable, with next message being successful reconnection. Restarting nova-compute services helps temporarily, the issue starts to manifest after a few days. Initially disconnects once every few hours, each time in shorter intervals, to the point it happens every minute or so. Did anyone encounter something similar? [1] https://bugs.launchpad.net/nova/+bug/2092297 Pozdrawiam / Best regards, *Jakub Darmach*

3 2

[administrivia] Bounce processing disabled for now
by Jeremy Stanley 28 Jan '25

28 Jan '25

Due to repeated challenges with random messages being rejected by subscribers' mail providers (from DMARC invalidations, lines too long to be forwarded, content misidentified as spam, et cetera), the time required for list administrators to manage the resulting extra work is greater than the benefit we get from Mailman being able to figure out when subscriber addresses become defunct. As such, I've disabled the "bounce processing" feature for the time being, until we can work out solutions to make it less of a burden on our list admins and less confusing/failure prone for the list subscribers. If we do decide to give it another try at some point in the future, after some of the current challenges with it get ironed out, I'll let the list know. -- Jeremy Stanley

1 0

openstack-discuss-owner mailbox
by Albert Braden 28 Jan '25

28 Jan '25

Is anyone manning the openstack-discuss-owner mailbox? I've been writing to that address about the recent glitch that deleted my list subscription and account (and according to the error message, hundreds of others), but I'm not getting a response.

2 3

[publiccloud-sig] Public Cloud SIG Meeting this week
by Felix Kronlage-Dammers 28 Jan '25

28 Jan '25

Hi everyone, This upcoming Wednesday (January 29th) the next meeting of the publiccloud-sig is going to happen or at least would happen: However I’ll not be around tomorrow to facilitate and I did not get any feedback from anyone else on it. Usually we would be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig - so give it a shot ;) See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG felix -- Felix Kronlage-Dammers Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[nova] Performance Issues with OpenStack Server List on os-compute-api-version 2.96
by 黒羽正徳 [Kuroha Masanori] 28 Jan '25

28 Jan '25

Hello, We have recently encountered a situation where the response time for the openstack server list command is significantly slower when specifying os-compute-api-version 2.96 for certain projects. In comparison with version 2.95, some projects experience a response time that is 2-3 times longer, while other projects show little to no difference. We understand that in version 2.96, there was a change to obtain the availability zone from the request_spec [1]. However, upon checking the instance records in request_spec for the projects, we have not identified any differences that would account for this slow response behavior. Additionally, we have observed that when certain ERROR VM is present, the response time for the server list can become considerably slower for specific projects. In one case, we resolved the slow response issue by deleting instances that did not have corresponding fault records in the database. However, the exact reason why this action resolved the issue remains unclear. If anyone has more detailed information or potential solutions regarding these issues, or if you have encountered similar situations, we would greatly appreciate your insights. [1] https://git.linecorp.com/Flava-IaaS/nova/commit/c98c8d84eec6e65f1b67ae1ab82… Best regards, Masanori Kuroha

1 1

[largescale-sig] Next meeting: January 15, 9utc
by Thierry Carrez 28 Jan '25

28 Jan '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=20250115T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 3

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

28 Jan '25

Hello Stackers, We're 9 weeks away from OpenStack's 2025.1 coordinated "Epoxy" release [1]. These weeks leading up to feature freeze (R-5/Feb 24-28) will be about "getting things done" for project teams. As Slawek Kaplonski (slaweq) wrote to you [2], we'll be kicking off combined elections for Project Team Leads for the 2025.2 "Flamingo" release cycle and five seats on the OpenStack Technical Committee next week. In light of this, please confirm your eligibility to vote in these elections by navigating to the CIVS website and entering your Gerrit email address: https://civs1.civs.us/cgi-bin/opt_in.pl In each of the past three elections, we've had roughly a fifth of eligible voters cast their votes. It would make a great difference to our community if we could improve this statistic with your cooperation! In the past week, the OpenStack Technical Committee approved a resolution to welcome the "Freezer" (Disaster-Recovery-as-a-Service) project back into the fold of "active" projects [3]. I'd like to extend a shout-out to Dmitriy Rabotyagov (noonedeadpunk) and Álvaro Soto (khyr0n) for their work to revive the project team. The team is looking to pursue the release of several project deliverables during this release. === Weekly Meeting === The TC weekly IRC meeting on 2025-01-21 [4] was well attended. We were in "getting things done" mode too, as much of the meeting followed up on action items from past meetings. We discussed getting more active review participation for changes to the "openstackdocstheme" repository by working with the Oslo team. We also deliberated on election nomination windows. We are in favor of early nominations from folks who are unable to self-nominate due to holidays or other personal reasons to be away from their computers during the nomination window. However, there were concerns expressed that the election officials may be burdened by the work necessary to shepherd such nominations. Early nominations would fail several CI checks, require re-checks, and potentially create some confusion. We'll attempt to watch this closely for the next election cycle and recalibrate. Our goal is to avoid leaderless projects due to holiday cycles during elections. The TC also discussed the next steps for the newly active Freezer project to release artifacts during the current release cycle. The next meeting of the OpenStack TC is today, 2025-01-28, at 1800 UTC in the #openstack-tc IRC channel on OFTC. Please find the meeting's agenda on the meeting wiki [5]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Retire Freezer DR | https://review.opendev.org/c/openstack/governance/+/938183 - Remove Freezer from inactive state | https://review.opendev.org/c/openstack/governance/+/938938 ==== Open for Review ==== - Retire qdrouterd role | https://review.opendev.org/c/openstack/governance/+/938193 - Reset the DPL model for Oslo project | https://review.opendev.org/c/openstack/governance/+/939485 - Reset the DPL model for Release project | https://review.opendev.org/c/openstack/governance/+/939486 - Add devstack-plugin-prometheus repo to Quality Assurance repos | https://review.opendev.org/c/openstack/governance/+/939953 - Reset the DPL model for Watcher project | https://review.opendev.org/c/openstack/governance/+/939488 - Add Watcher project update liaison | https://review.opendev.org/c/openstack/governance/+/940168 - Adopt DPL model for Watcher 2025.2 | https://review.opendev.org/c/openstack/governance/+/940167 - Define 2025 upstream investment opportunities | https://review.opendev.org/c/openstack/governance/+/939507 - Add resolution for late Freezer release | https://review.opendev.org/c/openstack/governance/+/939792 - Deprecate ironic-lib | https://review.opendev.org/c/openstack/governance/+/939278 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === - 2025-01-28: OpenInfra Board Monthly Meeting: https://board.openinfra.org/ - 2025-02-01: FOSDEM 2025 (https://fosdem.org/2025/) OpenStack's 15th Birthday Celebration - 2025-02-05: Nominations open 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) 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] 2025.2 Election Kickoff: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Remove Freezer from inactive state: https://review.opendev.org/c/openstack/governance/+/938938 [4] TC Meeting IRC Log 2025-01-21: https://meetings.opendev.org/meetings/tc/2025/tc.2025-01-21-18.00.log.html [5] TC Meeting Agenda, 2025-01-28: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[mistral] meetings during next PTG
by Arnaud Morin 28 Jan '25

28 Jan '25

Hey all, Next PTG will take place between April 7 to 10. Is there anyone willing to talk about mistral developement during this PTG? So far, mistral has not evolved that much, but maybe someone is having ideas about it? Also, there is this eventlet-removal topic that could be discussed. Let me know, Cheers, Arnaud.

1 0

[neutron] Bug Deputy Report Jan 20 - Jan 26
by Yatin Karel 27 Jan '25

27 Jan '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ------ - https://bugs.launchpad.net/neutron/+bug/2095807 - OVN loadbalancer via FIP does not work for DVR + VLAN networks Unassigned OVN octavia provider, Asked Fernando to have a look as could be known one - https://bugs.launchpad.net/neutron/+bug/2095598 - test_async_process_respawns functional test failing in fips functional job Unassigned We thought it would get fixed with https://review.opendev.org/c/openstack/neutron/+/939627 but it's not, so have to be checked again - https://bugs.launchpad.net/neutron/+bug/2095595 - The neutron-dhcp-agent resync throttling mechanism doesn't work Assigned to Anton Kurbatov - https://bugs.launchpad.net/neutron/+bug/2095590 - [OVN] Neutron API stops refreshing the hash ring node Assigned to Rodolfo - https://bugs.launchpad.net/neutron/+bug/2095566 - [OVN] Router creation timeouts randomly Unassigned Rodolfo mentioned he has some fixes in flight to cover ovn wsgi related issue, so to confirm if this is also covered. Medium ---------- - https://bugs.launchpad.net/neutron/+bug/2095576 - [OVS] False ERROR log message every time when creating VM Unassigned - https://bugs.launchpad.net/neutron/+bug/2095322 - ADMIN_OR_NET_OWNER_{MEMBER|READER} rules don't work for subnets Unassigned Incomplete --------------- - https://bugs.launchpad.net/neutron/+bug/2096704 - [RFE] Allow rebalancing of OVN LRPs Asked for more context -- Thanks and Regards Yatin Karel

1 0

[all][elections][ptl][tc] Combined PTL/TC 2025.2 cycle Election Season
by Sławek Kapłoński 27 Jan '25

27 Jan '25

Hi, Election details: https://governance.openstack.org/election/ The nomination period officially begins Feb 05, 2025 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in these governance documents[1][2][3]. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. Similarly, there will only be a TC poll if there are more than 5 candidates stepping forward the available TC positions. All members of the community are encouraged to confirm their email address as described at: https://governance.openstack.org/election/#electorate There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you wish to discuss in private please email any of the election officials[4] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/tc/reference/charter.html [2] https://governance.openstack.org/tc/reference/role-of-the-tc.html [3] https://docs.openstack.org/project-team-guide/ptl.html [4] https://governance.openstack.org/election/#election-officials -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0