March 2025 - openstack-discuss - lists.openstack.org

[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

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

19 May '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 9

[openstack-helm] Are there any real users of the umbrella chart?
by Vladimir Kozhukalov 17 May '25

17 May '25

Hi team, This is to start the discussion about the future of the Openstack super (umbrella) chart [1]. My personal impression (maybe I am wrong) is that this chart is of extremely little interest. We continue to maintain this code (and spend testing resources) but maybe there are no real users of it. The chart deploys a compute-kit scheme but the same result can be achieved if one deploys multiple separate charts one-by-one. It seems convenient to have this single super chart that deploys Openstack with a single command, but IMO even small operators prefer using separate charts. Having said that, I would suggest removing this chart if it is not needed. [1] https://opendev.org/openstack/openstack-helm/src/branch/master/openstack -- Best regards, Kozhukalov Vladimir

3 4

[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

[all] OpenInfra Summit Europe Scheduled for October 2025
by Jeremy Stanley 08 Apr '25

08 Apr '25

In case anyone hasn't seen the news already, OpenInfra Summit Europe has been officially scheduled for October 17-19, 2025, at École Polytechnique near Paris, France: https://openinfra.dev/blog/openinfra-summit-2025 The OpenInfra Foundation is currently recruiting interested individuals to join a Programming Committee kickoff call on Thursday (2025-03-27). This call will be used to plan the conference tracks for the OpenInfra Summit ahead of the CFP, and will greatly benefit from OpenStack's involvement as always. If you would like to participate in the Programming Committee or assist in any other way, please email Helena Spease <helena(a)openinfra.dev>. I am also happy to try and point people in the right direction if you have any questions and prefer to reach out to me. On behalf of the foundation, we’re excited to bring the OpenInfra community together in France, and sincerely hope you'll join us! -- Jeremy Stanley

1 1

[manila]NFS-Ganesha exports
by Mikhail Okhrimenko 06 Apr '25

06 Apr '25

Hello community, Trying to setup the Manila version of Caracal with NFS-Ganesha backend. Ganesha version 4.0 is deployed using ceph orch in a ceph cluster version 17. Backend configuration in manila.conf [ganesha_nfs] driver_handles_share_servers = False share_backend_name = ganesha_nfs Share_driver = manila.share.drivers.cephfs.driver.CephFSDriver cephfs_protocol_helper_type = NFS cephfs_conf_path = /etc/ceph/ceph.conf cephfs_auth_id = manila cephfs_cluster_name = ceph cephfs_filesystem_name = {{ cephfs_filesystem_name }} cephfs_nfs_cluster_id = {{ cephfs_nfs_cluster_id }} I see the subvolume being created in ceph ceph fs subvolume ls <volume_name> but no export ceph nfs export ls <cluster_id> what am I doing wrong? what am I missing? in the manila-share logs I see a request to create a subvolume, but I don't see a request to create an export, for some reason manila doesn't even try to create an export

3 6

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

[octavia][nova][neutron] failed to failover loadbalancer
by Winicius Allan 02 Apr '25

02 Apr '25

Hello stackers! release: zed deploy-tool: kolla-ansible After an outage, all the load balancers from my cluster came to provisioning status ERROR because the o-hm0 interface was unavailable on controller nodes. I've created them again and tried a failover on load balancers. The octavia-worker logs show that failover was completed successfully, but the provisioning status remains with ERROR. Looking into nova-compute logs, I see that an exception was raised os_vif.exception.NetworkInterfaceNotFound: Network interface qvob8ac0f5f-46 not found The instance id for that interface matches the new amphora id. I'll attach the nova-compute logs here[1]. In neutron-server logs, there is no ERROR or WARNING that I can found, the only suspicious entry is Port b8ac0f5f-4613-4b95-9690-7cf59f739fd0 cannot update to ACTIVE because it is not bound. _port_provisioned /var/lib/kolla/venv/lib/python3.10/site-packages/neutron/plugins/ml2/plugin.py:360 Can anyone give me a light? [1] https://pastebin.com/hV3xgu0e

2 6

[nova] nova-manage fails when upgrading to Antelope
by Roby G 01 Apr '25

01 Apr '25

Hello everyone, I´m trying to upgrade to Antelope and have a problem when executing the db migrations. `nova-manage db sync` fails when upgrading from Zed to Antelope (same for Yoga --> Antelope) - Nova: 27.4.0 - Database: PostgreSQL 16 - Operating System: Ubuntu 22.04 - OpenStack Zed --> Antelope Full Log. /var/log/nova-manage.log: ``` 2025-03-04 11:42:14.963 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Context impl PostgresqlImpl. 2025-03-04 11:42:14.964 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Will assume transactional DDL. 2025-03-04 11:42:14.967 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Running upgrade ccb0fa1a2252 -> 960aac0e09ea, de-duplicate_indexes_in_instances__console_auth_tokens 2025-03-04 11:42:14.970 2519974 WARNING oslo_db.sqlalchemy.exc_filters [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] DBAPIError exception wrapped.: psycopg2.errors.DependentObjectsStillExist: cannot drop index uuid because other objects depend on it DETAIL: constraint block_device_mapping_instance_uuid_fkey on table block_device_mapping depends on index uuid constraint consoles_instance_uuid_fkey on table consoles depends on index uuid constraint fixed_ips_instance_uuid_fkey on table fixed_ips depends on index uuid constraint instance_actions_instance_uuid_fkey on table instance_actions depends on index uuid constraint instance_extra_instance_uuid_fkey on table instance_extra depends on index uuid constraint instance_faults_instance_uuid_fkey on table instance_faults depends on index uuid constraint instance_info_caches_instance_uuid_fkey on table instance_info_caches depends on index uuid constraint instance_metadata_instance_uuid_fkey on table instance_metadata depends on index uuid constraint instance_system_metadata_instance_uuid_fkey on table instance_system_metadata depends on index uuid constraint migrations_instance_uuid_fkey on table migrations depends on index uuid constraint security_group_instance_association_instance_uuid_fkey on table security_group_instance_association depends on index uuid constraint virtual_interfaces_instance_uuid_fkey on table virtual_interfaces depends on index uuid HINT: Use DROP ... CASCADE to drop the dependent objects too. 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters Traceback (most recent call last): 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1802, in _execute_context 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters self.dialect.do_execute( 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 732, in do_execute 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters cursor.execute(statement, parameters) 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters psycopg2.errors.DependentObjectsStillExist: cannot drop index uuid because other objects depend on it 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters DETAIL: constraint block_device_mapping_instance_uuid_fkey on table block_device_mapping depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint consoles_instance_uuid_fkey on table consoles depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint fixed_ips_instance_uuid_fkey on table fixed_ips depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_actions_instance_uuid_fkey on table instance_actions depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_extra_instance_uuid_fkey on table instance_extra depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_faults_instance_uuid_fkey on table instance_faults depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_info_caches_instance_uuid_fkey on table instance_info_caches depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_metadata_instance_uuid_fkey on table instance_metadata depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_system_metadata_instance_uuid_fkey on table instance_system_metadata depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint migrations_instance_uuid_fkey on table migrations depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint security_group_instance_association_instance_uuid_fkey on table security_group_instance_association depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint virtual_interfaces_instance_uuid_fkey on table virtual_interfaces depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters HINT: Use DROP ... CASCADE to drop the dependent objects too. 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters ``` Any suggestions? Thanks!

3 3

[Octavia]
by Vincent Godin 01 Apr '25

01 Apr '25

Hello Octavia Team, We have an Openstack infrastructure with 3 Nova AZ and 3 Cinder AZ. Furthermore, Octavia will use cinder for Amphora disk. Is there a way to create an Amphora so that the Compute AZ match the Cinder AZ ? As the storage is AZ specific, it's not possible to launch an Amphora on a Compute AZ with a storage on an alternate AZ. As a client, there is no need to fix where the Amphora will be launched, we just want to be sure that if the Amphora is planned to be launched on a specific AZ, its storage will be selected on the corresponding AZ too ! Vincent

3 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R+0)
by Goutham Pacha Ravi 31 Mar '25

31 Mar '25

Hello Stackers, The release team will be tagging the GA release for all cycle-with-rc projects for 2025.1 ("Epoxy") on 2025-04-02 [1][2]. Remarkably, this will be the 31st release of OpenStack and one of two that will mark 15 years of the community! There will be an OpenInfra Live event on 2025-04-03, where a few project maintainers will reflect on how the release cycle went, what it will bring to users, and project priorities for the 2025.2 ("Flamingo") release cycle [3]. Alongside project teams, the OpenStack Technical Committee has been preparing for the upcoming virtual Project Teams Gathering. We're still gathering topics, so please add yours if you're interested in seeding a relevant discussion. You can find all the discussion etherpads linked on the PTG Website [4]. In the past week, we completed the community testing goal to upgrade CI integration testing ("migrate-to-noble") [5]. Kudos to our goal champion, Ghanshyam Mann (gmann), and to everyone who helped with the effort! === Weekly Meeting === The last weekly meeting of the OpenStack TC was held over IRC in OFTC's #openstack-tc channel on 2025-03-25 [6]. We added a discussion topic on operator engagement to the os-operators' PTG slot. We caught up on CI issues that needed attention from several quarters, including a kernel regression that prevented release-critical patches from merging in Neutron and Kolla and warranted a workaround. A breaking change in Setuptools 78 impacted many projects on Zuul; however, OpenStack was minimally affected before the issue was resolved in Setuptools. A broken CentOS 9 mirror briefly caused problems due to an inconsistent state from an upstream source. It was brought to the TC's attention that the Skyline project commits pre-built static files (e.g., JavaScript bundles generated using Yarn) directly into its repository. This manual intervention creates a potential security risk similar to the XZ backdoor attack since there is no verifiable way to check whether these builds contain malicious code. The TC brainstormed that it would be better to offload the build process to Zuul, preventing manual intervention, and to ensure the yarn.lock file is always included in releases for better traceability. Operators and project contributors must be aware of this issue and the fact that builds are currently not reproducible, complicating packaging. There was a suggestion that OpenStack governance should enforce standardized project security practices. Since we haven't identified concrete steps to resolve the current issue, we'll revisit this topic in a future discussion. The next meeting of the OpenStack TC is today, 2025-04-01, at 1700 UTC. Please note the change in timing—it is an hour earlier than our past meetings. This meeting will be held simultaneously on Video (Zoom) and IRC (OFTC's #openstack-tc channel). Please find the conference details and agenda on the meeting's wiki page [7]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Mark CI migration to Ubuntu Noble goal complete | https://review.opendev.org/c/openstack/governance/+/945641 ==== Open for Review ==== - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 === Upcoming Events === - 2025-04-01 - 2025-04-04: KubeCon+CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2025-04-02: OpenStack 2025.1 ("Epoxy") Release - 2025-04-03: OpenInfra LIVE - Epoxy release [3] - 2025-04-08: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-04-07 - 2025-04-12: 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] 2025.1 Release tags: https://review.opendev.org/c/openstack/releases/+/945949 [3] Introducing OpenStack 2025.1 Epoxy on OpenInfra Live: https://openinfra.org/live/ [4] OpenInfra Flamingo vPTG: https://ptg.opendev.org/ptg.html [5] "migrate to noble" community goal: https://governance.openstack.org/tc/goals/completed/2025.1/migrate-ci-jobs-… [6] TC Meeting IRC Log 2025-03-25: https://meetings.opendev.org/meetings/tc/2025/tc.2025-03-25-18.00.log.html [7] TC Meeting Agenda 2025-04-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[scientific-sig] Wiki update
by Jimmy McArthur 31 Mar '25

31 Mar '25

Hi Scientific Folks! I was trying to direct someone to your meetings, but noticed the wiki page is quite out of date: https://wiki.openstack.org/wiki/Scientific_SIG I know you all are meeting at the PTG, is this something that could be added to the agenda? I’ve got a few orgs that I’d like to send your way. Cheers, Jimmy

1 0

[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

[neutron] Bug deputy report March 24 - March 30
by Oleg Bondarev 31 Mar '25

31 Mar '25

Hello Neutron Team, Bug report for the week of March 24 is below: *High:* - https://bugs.launchpad.net/neutron/+bug/2104019 - random failures in L3 HA fullstack failover tests - Confirmed - assigned to Miguel Lavalle - https://bugs.launchpad.net/neutron/+bug/2104134 - ovs/linuxbridge jobs running on ubuntu noble broken with latest kernel 6.8.0-56.58 - Confirmed - unassigned (looks like yatin is tracking it) - https://bugs.launchpad.net/neutron/+bug/2105383 - [OVN] The filter to add the MTU to a LRP changes the options dictionary population - In progress - patch from Rodolfo Alonso: https://review.opendev.org/c/openstack/neutron/+/945905 - https://bugs.launchpad.net/neutron/+bug/2104160 - [DB] Stop expand migrations with field drop exceptions - Confirmed - unassigned ---------- *Low:* - https://bugs.launchpad.net/neutron/+bug/2104927 - [OVN] HA_Chassis_Group creation returns an exception in the logs Edit - In progress - patch from Rodolfo Alonso: https://review.opendev.org/c/openstack/neutron/+/945837 - https://bugs.launchpad.net/neutron/+bug/2104979 - Possible deadlock on closing ip_monitor thread - Triaged - unassigned ---------- *Undecided:* - https://bugs.launchpad.net/neutron/+bug/2104037 - Unable to open stream to ssl::6641 to retrieve schema: Exec format error - Incomplete Thanks, Oleg

1 0

PCI passthrough - flavor not found
by Francesco Di Nucci 31 Mar '25

31 Mar '25

Hi all, I am trying to setup PCI passthrough with Nova, following guides such as this <https://superuser.openinfra.org/articles/a-comprehensive-guide-to-configuri…> and this <https://medium.com/@thomasal14/gpu-passthrough-in-openstack-da2a98a16f7b>: * installed a GPU on a compute node, configured kernel etc and now it is using the vfio-pci driver * set [pci]/device_spec = { "vendor_id": "10de", "product_id": "1ff2" } on compute node (formerly [pci]/passthrough_whitelist) and restarted openstack-nova-* * On the controller node set [pci]/alias: { "vendor_id":"10de", "product_id":"1ff2", "device_type":"type-PCI", "name":"nvidia-t400" }, [filter_scheduler]/enabled_filters = PciPassthroughFilter, [filter_scheduler]/available_filters = nova.scheduler.filters.all_filters and restarted openstack-nova-* * Created a flavor with openstack flavor create --vcpus 4 --ram 8192 --disk 40 --property "pci_passthrough:alias"="nvidia-t400:1" gpu_flavor, it is shown with openstack flavor list * Created an image with --property img_hide_hypervisor_id=true * Tried to create an instance with openstack server create --flavor gpu_flavor --image Almalinux_GPU --key-name "My Key" --network my_network test-gpu (also with --availability-zone nova:my-gpu-node.example.com) * VM creation fails with this errors on the controller node /nova-api.log/ HTTP exception thrown: Flavor gpu_flavor could not be found. /nova-scheduler.log/ Filter PciPassthroughFilter returned 0 hosts Filtering removed all hosts for the request with instance ID '131d5c1c-1927-42c0-bb48-618c05d31c2a'. Filter results: ['PciPassthroughFilter: (start: 19, end: 0)'] /nova-conductor.log/ Failed to schedule instances: nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. If I understand correctly it's a cascading error generating from the flavor not found, even though it exists... Anyone has encountered something like this/has suggestions? Am I missing some config? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

6 10

[nova][manila] How to deploy the new Manila virtio-fs driver?
by Thomas Goirand 31 Mar '25

31 Mar '25

Hi, I've quickly discussed with Shean on IRC, and he told me the new virtio-fs driver for Manila was part of Epoxy. This is very exciting. Thanks to everyone who worked on it. I'd like to deploy it, however, I have no clue how. Note that I already implemented the generic driver using (puppet-manila). But I haven't been able to read any doc about it. Is there anything I should know? Also, is there any pending patches that should get on top of Epoxy? Shean already told me about these 2: https://review.opendev.org/c/openstack/python-openstackclient/+/881540 https://review.opendev.org/c/openstack/openstacksdk/+/880056 It'd be IMO super nice if we could them in Epoxy proper (even though I could manage to sneak them as Debian specific patches into my Debian packages). Cheers, Thomas Goirand (zigo)

2 1

[openstack][magnum][keystone] Fail to create clusters with Openstack 2025.1
by Nguyễn Hữu Khôi 29 Mar '25

29 Mar '25

Hello. I am testing magnum_cluster_api v0.29.3 with OPS 2025.1.but I encounter this error:keystoneauth1.exceptions.http.BadRequest: Invalid input for field/attribute trust. Value: {'roles': [{'id': '00c3da32a3384e298256b4293d7d0b9a', 'name': 'load-balancer_member', 'domain_id': None, 'description': None, 'options': {}, 'links': {'self': ' https://k.com:5000/v3/roles/00c3da32a3384e298256b4293d7d0b9a'}}, {'id': '32e8b1f999ae4d2f8d50ffd5a7065e38', 'name': 'manager', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/32e8b1f999ae4d2f8d50ffd5a7065e38'}}, {'id': '4dc61b50010540c4a0e614a1fb23d1ef', 'name': 'admin', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/4dc61b50010540c4a0e614a1fb23d1ef'}}, {'id': '2d722357d74f4c39aab4bc18b5cbe391', 'name': 'member', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/2d722357d74f4c39aab4bc18b5cbe391'}}, {'id': 'efa3d956f74e41b6aa999262d456063b', 'name': 'heat_stack_owner', 'domain_id': None, 'description': None, 'options': {}, 'links': {'self': ' https://k.com:5000/v3/roles/efa3d956f74e41b6aa999262d456063b'}}, {'id': '30b6b07e181e414099a79d0d83cec4a1', 'name': 'reader', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/30b6b07e181e414099a79d0d83cec4a1'}}], 'delegation_depth': 0, 'id': '65fc7dbe686c4efca6f8501ca2b0f4c9', 'trustor_user_id': '36e0dee5ff45410e89ee85c403131b92', 'trustee_user_id': 'b3a05e45b78b4ad1bfd537c84f2ebfa2', 'project_id': '16d98639e9154413843795fd1a4a9bcb', 'impersonation': True, 'expires_at': None, 'remaining_uses': None, 'deleted_at': None, 'redelegated_trust_id': None, 'redelegation_count': 0, 'roles_links': {'self': ' https://k.com:5000/v3/65fc7dbe686c4efca6f8501ca2b0f4c9/roles', 'next': None, 'previous': None}, 'links': {'self': ' https://k.com:5000/v3/OS-TRUST/trusts/65fc7dbe686c4efca6f8501ca2b0f4c9'}}. Additional properties are not allowed ('delegation_depth' was unexpected) (HTTP 400) (Request-ID: req-7520e8ee-8073-4164-b023-4f353721a6c5) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/common/trust_manager.py", line 34, in create_trustee_and_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server trust = osc.keystone().create_trust( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/common/keystone.py", line 218, in create_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server raise exception.TrustCreateFailed( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server magnum.common.exception.TrustCreateFailed: Failed to create trust for trustee b3a05e45b78b4ad1bfd537c84f2ebfa2. 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/server.py", line 174, in _process_incoming 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/osprofiler/profiler.py", line 159, in wrapper 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/cluster_conductor.py", line 66, in cluster_create 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server trust_manager.create_trustee_and_trust(osc, cluster) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/common/trust_manager.py", line 42, in create_trustee_and_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server raise exception.TrusteeOrTrustToClusterFailed( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server magnum.common.exception.TrusteeOrTrustToClusterFailed: Failed to create trustee or trust for Cluster: 65eec76d-a811-420a-8d9f-7cefdd050f35 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.serverCould I have some ideas for this? Thank you. [image: white_check_mark][image: eyes][image: raised_hands] NEW Nguyen Huu Khoi

2 1

[openstack-ansible]: openstack-ansible upgrade from Yoga to Zed
by Rambo Rambo 28 Mar '25

28 Mar '25

Hi Team We are planning openstack-ansible upgrade from Yoga to Zed. Distribution:openstack-ansible Release: Yoga OS - Ubuntu 20.04 I was checking the release notes and can see below point related to neutron linux bridge. We are having linux bridge at the moment. https://docs.openstack.org/releasenotes/openstack-ansible/zed.html =========================================================== - With marking ML2/LinuxBridge driver as ‘Experimental’ in the upstream Neutron project OpenStack-Ansible has switched a default mechanism driver to ML2/OVN. In order to upgrade any existing deployment that was relying on defaults to the new OpenStack-Ansible version you must ensure that following variables are defined explicitly to ensure parity with existing functionality: neutron_plugin_type: ml2.lxbneutron_ml2_drivers_type: "flat,vlan,vxlan,local"neutron_plugin_base: - router - metering Failure to define any of these variables will result in playbook failures and neutron misconfiguration. We have covered this step with upgrade script that will create a user_neutron_migration.yml file with assumed defaults. =================================================== As per above point we need to add new parameters into user_variables file . also it is written "We have covered this step with upgrade script" *Current Configuration:* /etc/neutron/plugins/ml2# *cat ml2_conf.ini* [ml2] type_drivers = flat,vlan,vxlan,local tenant_network_types = vxlan,flat *mechanism_drivers = linuxbridge,l2population* # ML2 flat networks extension_drivers = port_security,subnet_dns_publish_fixed_ip *user_variable file* only has below related parameters : neutron_l2_population: true neutron_plugin_base: - router - neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin neutron_ml2_conf_ini_overrides: ml2: extension_drivers: - port_security - subnet_dns_publish_fixed_ip Can someone please confirm what should be done to take care of above point of the release notes? Regards

2 1

[neutron] Next two weeks CI meeting cancelled
by Yatin Karel 28 Mar '25

28 Mar '25

Hello Neutron Team !! As communicated in last week's CI meeting i will not be around upcoming Monday, so cancelling the meeting. Also proposing to cancel the follow up week as that's PTG week. So we will have our next CI meeting on 14th April. Thanks and Regards Yatin Karel

1 0

[release] Release countdown for week R+0
by Thierry Carrez 28 Mar '25

28 Mar '25

Development Focus ----------------- We will be releasing the coordinated OpenStack 2025.1 Epoxy release next week, on April 2nd, 2025. Thanks to everyone involved in the 2025.1 Epoxy cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: https://ptg.opendev.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed soon. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on Wednesday, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 -- Thierry Carrez (ttx)

1 0

Fwd: PCI passthrough - flavor not found
by Francesco Di Nucci 28 Mar '25

28 Mar '25

Thanks, forwarding to the list as information; tried it and still got the same error -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it -------- Forwarded Message -------- Subject: Re: PCI passthrough - flavor not found Date: Fri, 28 Mar 2025 11:10:25 +0200 From: Mike Currin <mike(a)idia.ac.za> To: Francesco Di Nucci <francesco.dinucci(a)na.infn.it> Hi, Forgot to reply to the list as well so ignore the one specifically to you, it's the same content though Regards Mike On Fri, Mar 28, 2025 at 11:08 AM Mike Currin <mike(a)idia.ac.za> wrote: Hi Francesco, We had something similar for our A100 GPUs, we had to add "device_type":"type-PF" vs PCI and then it worked. Maybe give that a go. I've seen it mentioned on the list before. Regards Mike On Fri, Mar 28, 2025 at 11:00 AM Francesco Di Nucci <francesco.dinucci(a)na.infn.it> wrote: Hi all, I am trying to setup PCI passthrough with Nova, following guides such as this <https://superuser.openinfra.org/articles/a-comprehensive-guide-to-configuri…> and this <https://medium.com/@thomasal14/gpu-passthrough-in-openstack-da2a98a16f7b>: * installed a GPU on a compute node, configured kernel etc and now it is using the vfio-pci driver * set [pci]/device_spec = { "vendor_id": "10de", "product_id": "1ff2" } on compute node (formerly [pci]/passthrough_whitelist) and restarted openstack-nova-* * On the controller node set [pci]/alias: { "vendor_id":"10de", "product_id":"1ff2", "device_type":"type-PCI", "name":"nvidia-t400" }, [filter_scheduler]/enabled_filters = PciPassthroughFilter, [filter_scheduler]/available_filters = nova.scheduler.filters.all_filters and restarted openstack-nova-* * Created a flavor with openstack flavor create --vcpus 4 --ram 8192 --disk 40 --property "pci_passthrough:alias"="nvidia-t400:1" gpu_flavor, it is shown with openstack flavor list * Created an image with --property img_hide_hypervisor_id=true * Tried to create an instance with openstack server create --flavor gpu_flavor --image Almalinux_GPU --key-name "My Key" --network my_network test-gpu (also with --availability-zone nova:my-gpu-node.example.com <http://my-gpu-node.example.com>) * VM creation fails with this errors on the controller node /nova-api.log/ HTTP exception thrown: Flavor gpu_flavor could not be found. /nova-scheduler.log/ Filter PciPassthroughFilter returned 0 hosts Filtering removed all hosts for the request with instance ID '131d5c1c-1927-42c0-bb48-618c05d31c2a'. Filter results: ['PciPassthroughFilter: (start: 19, end: 0)'] /nova-conductor.log/ Failed to schedule instances: nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. If I understand correctly it's a cascading error generating from the flavor not found, even though it exists... Anyone has encountered something like this/has suggestions? Am I missing some config? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it -- Mike Currin email: mike(a)idia.ac.za Cloud Computing System Support Inter-University Institute for Data Intensive Astronomy (IDIA) University of Cape Town

1 0

[all][qa] QA tools (devstack/grenade/tempest) setup for new stable/2025.1 and current master
by Ghanshyam Mann 27 Mar '25

27 Mar '25

Hi All, The QA tools setup[1] for the new stable/2015.1 and the current master is completed. I would like to highlight a couple of things: * Recheck if devstack/gernade jobs on master or any backport were not running/testing correctly. * By default, grenade-skip-level-always is added in integrated gate templates as voting. As the current master is non-SLURP, Testing N-2 -> N upgrade is not mandatory, so the project can opt to make it non-voting or remove it from their integrated template[2]. [1] https://review.opendev.org/q/topic:%22qa-2025-1-release%22 [2] https://github.com/openstack/tempest/blob/f4a8698b97a5433b8e64df408aace2fb1… -gmann

1 0

[openstack-helm] health-probes timeout for neutron agents (l3 and dhcp) and nova compute
by Alberto Molina Coballes 27 Mar '25

27 Mar '25

Hi, We’re facing an issue when deploying OpenStack 2024.1 with OpenStack Helm and OVS, the health probes fail for neutron-l3-agent, neutron-dhcp-agent and nova-compute while the internal RPC communication between the nova and neutron components look fine: Neutron: openstack network agent list +--------------------------------------+--------------------+--------------------------------+-------------------+-------+-------+---------------------------+ | ID | Agent Type | Host | Availability Zone | Alive | State | Binary | +--------------------------------------+--------------------+--------------------------------+-------------------+-------+-------+---------------------------+ | 433c2b07-5c82-4545-991d-6d0de6044ae9 | DHCP agent | fig-virt-intdev-alberto-node-0 | nova | :-) | UP | neutron-dhcp-agent | | 56c050fa-e58e-46a6-8191-0d0d481de246 | Open vSwitch agent | fig-virt-intdev-alberto-node-0 | None | :-) | UP | neutron-openvswitch-agent | | 5ea28388-3fac-4ebb-bce4-6b210f8a3766 | Metadata agent | fig-virt-intdev-alberto-node-0 | None | :-) | UP | neutron-metadata-agent | | 6a4506ca-6fe4-489a-b370-6e426db40d50 | DHCP agent | fig-virt-intdev-alberto-node-1 | nova | :-) | UP | neutron-dhcp-agent | | 772a1d3a-b432-4ac3-8dfe-d3affc6f226d | Metadata agent | fig-virt-intdev-alberto-node-1 | None | :-) | UP | neutron-metadata-agent | | 7bd8360c-468a-4473-a470-abfb1ab435da | Open vSwitch agent | fig-virt-intdev-alberto-node-1 | None | :-) | UP | neutron-openvswitch-agent | | 9d362a63-5740-44ed-ac77-4548eee59205 | L3 agent | fig-virt-intdev-alberto-node-0 | nova | :-) | UP | neutron-l3-agent | | a2cc9dc4-1600-4c5d-a250-2e43cf062cf3 | L3 agent | fig-virt-intdev-alberto-node-1 | nova | :-) | UP | neutron-l3-agent | +--------------------------------------+--------------------+--------------------------------+-------------------+-------+-------+---------------------------+ The neutron-l3 and neutron-dhcp pods are not ready: k -n openstack get pods -l application=neutron |grep 'l3\|dhcp' neutron-dhcp-agent-default-fw5rm 0/1 Running 0 127m neutron-dhcp-agent-default-vh7c4 0/1 Running 0 127m neutron-l3-agent-default-4h5tp 0/1 Running 0 24m neutron-l3-agent-default-bdngv 0/1 Running 0 24m Because the health probes fail: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 4m38s (x119 over 127m) kubelet Readiness probe failed: Health probe timed out. Agent is down or response timed out When trying to execute the health probe manually from the container, the probe fails with a timeout after 60 seconds (RPC_PROBE_TIMEOUT=60) neutron@fig-virt-intdev-alberto-node-1:/$ python /tmp/health-probe.py --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/dhcp_agent.ini --agent-queue-name dhcp_agent --use-fqdn Health probe timed out. Agent is down or response timed out The situation for nova is quite similar: openstack compute service list +--------------------------------------+----------------+---------------------------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +--------------------------------------+----------------+---------------------------------+----------+---------+-------+----------------------------+ | eaf4684c-88a4-47dd-b340-b7dbebf148ba | nova-conductor | nova-conductor-679d57f977-zbq92 | internal | enabled | up | 2025-03-27T13:11:33.000000 | | 9164d63f-608c-44cc-8a92-2f2bac07c622 | nova-scheduler | nova-scheduler-845f87b9b5-vq9p5 | internal | enabled | up | 2025-03-27T13:11:36.000000 | | 464cd394-8b26-49ad-8c82-f014ca00ec7e | nova-compute | fig-virt-intdev-alberto-node-1 | nova | enabled | up | 2025-03-27T13:11:33.000000 | | aa7e5f6d-2533-4953-bb8d-9f9bfb7fc6bd | nova-compute | fig-virt-intdev-alberto-node-0 | nova | enabled | up | 2025-03-27T13:11:33.000000 | +--------------------------------------+----------------+---------------------------------+----------+---------+-------+----------------------------+ And the nova-compute pods are not ready because the health probes fail: k -n openstack get pods -l component=compute NAME READY STATUS RESTARTS AGE nova-compute-default-t8w7x 1/2 Running 1 (70m ago) 3h31m nova-compute-default-vz7nf 1/2 Running 1 (70m ago) 3h31m To be sure that the OpenStack RPC is working fine, the health probes have been deleted for nova-compute, then nova-cell-setup is executed and the hypervisors are ready. Some VMs have been launched in this environment successfully (nova-compute), getting IP from the DHCP agent or adding floating IPs (l3-agent) and the OpenStack behaviour is normal. So I’m confused about the health-probes failing. Any idea on what can be wrong or what to check is welcome. Thanks! Alberto Note: This is a Kubernetes cluster running on two VMs (OpenStack). This virtual environment has been redeployed several times with some modifications and the issue is fully reproducible: the probes for nova-compute, neutron-l3-agent and neutron-dhcp-agent always fail.

1 0

[Glance]Cancelling Weekly Meeting (March 27)
by Mridula Joshi 27 Mar '25

27 Mar '25

Hello, Cancelling today's weekly meeting, As most of the members are not around. Apologies for the last min update. Thanks, Mridula Joshi

1 0

[designate] multiple zone catalogs with multiple zones
by Benedikt Trefzer 26 Mar '25

26 Mar '25

Hi List I'm trying to create an additional pool with a separate catalog zone. For the default pool, I can do an AXFR to the catalog domain, this works (either without tsig key or with a tsig). For the catalog of the second pool cannot be queried (Log sais Zone not found). In the DB I can see the zone. Questions: - Is it possible to have multiple pools with separate catalogs, does anyone have a running setup ? - Reading this [1] line in the code, I assume It's not possible having multiple zones without using tsig, correct ? Thanks a lot. Benedikt [1] https://opendev.org/openstack/designate/src/branch/master/designate/mdns/ha…

1 1

Nova features
by engineer2024 26 Mar '25

26 Mar '25

Where can I find the nova feature requests which are yet to be developed ? I am thinking of contributing to adding new features.

3 3

[largescale-sig] Next meeting: March 26, 16utc
by Thierry Carrez 26 Mar '25

26 Mar '25

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 16UTC to facilitate America timezones participation. In these troubled DST times, you should doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250326T16 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

2 1

#eventlet-removal Flamingo PTG
by Herve Beraud 26 Mar '25

26 Mar '25

Hello folks, We’re meeting again on the Project Teams Gathering in April (7-11th). The slot for the Eventlet Removal Initiative PTG is: Tuesday (Apr 8) 1400-1600 UTC The etherpad is: https://etherpad.opendev.org/p/apr2025-ptg-eventlet Please feel free to insert your topic proposals. Additional details can be found at https://ptg.opendev.org/ Regards, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[release][ptl][tc] OpenInfra Live for OpenStack 2025.1 ‘Epoxy’
by helena＠openinfra.dev 26 Mar '25

26 Mar '25

Hi everyone, Following the release of OpenStack 2025.1 ‘Epoxy’ next Wednesday, we'd like to go ahead and schedule the OpenInfra Live for Thursday, April 3 at 1400 UTC. If you would like to represent your project team’s updates in the Epoxy release as well as their plans for Flamingo, please let me know. If you are not familiar, you can find reference examples like 2024.2 Dalmation [1] and 2024.1 Caracal [2]. [1] https://www.youtube.com/watch?v=6igJNIJ9yFE [2] https://www.youtube.com/watch?v=3BgAXbFaVqw&t=1707s Thanks! Helena helena(a)openinfra.dev Community Programs Manager The OpenInfra Foundation [openinfraLogo-sm.png]

3 2

[neutron][ops][upgrade] l3-agent failure during upgrade to Zed
by Eugen Block 25 Mar '25

25 Mar '25

Hi *, maybe I missed some announcement or something, but usually, I read the release notes [0] before upgrading our OpenStack cloud. I didn't notice anything regarding DB schema upgrades. And after the upgrade from Yoga to Zed in a test environment went well, I tried the same in our production today. Note that I didn't have a router in my test cloud, so that's probably why I didn't notice anything. Unfortunately, there has been a schema change, that's why the l3-agent failed to start properly with this error: 2025-03-21 12:29:14.527 846393 CRITICAL neutron [None req-e225ff0a-82e1-473b-9eba-9a11caa7ace7 - - - - - -] Unhandled error: oslo_messaging.rpc.client.RemoteError: Remote error: OperationalError (pymysql.err.OperationalError) (1054, "Unknown column 'portforwardings.external_port' in 'SELECT'") Indeed, the upgraded control node didn't have "external_port" anymore in /usr/lib/python3/dist-packages/neutron/db/models/port_forwarding.py, while the not yet upgraded control node did. So the situation could only be resolved by proceeding with the upgrade. But that meant an interruption for our virtual routers, causing floating IPs to be unreachable for a couple of minutes. Note that we're using highly-available routers. I thought about setting "no-ha" for each router, but that can only be done for disabled routers, which is not an option, of course. And it doesn't really fit into the "rolling upgrade" concept, which has worked great so far. Since we moved to Ubuntu last September (while still on Victoria), we've been able to upgrade to Yoga without any issues. And while the interruption today was not too critical, I was still surprised that such an important change didn't even make it into the Zed release notes. Was that a mistake or did I miss something? Are there other places I need to check before attempting an upgrade? Thanks, Eugen [0] https://docs.openstack.org/releasenotes/neutron/zed.html

3 9

[dev] New contributing organization help
by Dominik Danelski 25 Mar '25

25 Mar '25

Hello community, I work at a silver member of OpenInfra and will make code contributions on behalf of my employer. I am aware about the requirement to sign Contributor License Agreement listing me as the responsible person. Other than that, are there any additional requirements on identifying me as a corporate developer? For example contributor guide lists creating INDIVIDUAL Member account as one of the setup steps and it got me a bit worried. Kind regards Dominik Danelski @ CloudFerro

4 3

[kolla] Flamingo PTG
by Michał Nasiadka 25 Mar '25

25 Mar '25

Hello Koalas, We’re meeting again on the Project Teams Gathering in April (7-11th). The slots for Kolla/Kolla-Ansible/Kayobe PTG are: Tuesday - 07:00-08:00 UTC (general, Kolla and Kolla-Ansible) Wednesday - 07:00-08:00 UTC (general, Kolla and Kolla-Ansible) Friday - 14:00-15:00 UTC (Kayobe) If there’s a need of an additional afternoon (UTC) slot - please let us know. The ether pad is at the usual location: https://etherpad.opendev.org/p/kolla-flamingo-ptg Please insert your topic proposals and see you on the PTG. Additional details can be found at https://ptg.opendev.org/ Cheers, Michal

1 0

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

25 Mar '25

Hi everyone, This upcoming Wednesday (March 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 I'll not be around but Artem (gtema) will be hosting the call. Thanks Artem! cheers 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

[openstack][rabbitmq]computes cannot register to nova 2025.0master
by Nguyễn Hữu Khôi 24 Mar '25

24 Mar '25

Hello. I deployed OpenStack 2025.1 Master with Kolla-Ansible, but the compute nodes cannot register with Nova. Error: Cannot update service status on host "compute05" due to an unexpected exception.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 3dad7dbe8ea9429c83958b98bccc7094 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver Traceback (most recent call last): 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/virt/libvirt/driver.py", line 5687, in _set_host_enabled 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver service = objects.Service.get_by_compute_host(ctx, CONF.host) 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_versionedobjects/base.py", line 175, in wrapper 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver result = cls.indirection_api.object_class_action_versions( 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/conductor/rpcapi.py", line 240, in object_class_action_versions 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver return cctxt.call(context, 'object_class_action_versions', 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/client.py", line 190, in call 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver result = self.transport._send( 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/transport.py", line 123, in _send 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver return self._driver.send(target, ctxt, message, 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 800, in send 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver return self._send(target, ctxt, message, wait_for_reply, timeout, 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 789, in _send 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver result = self._waiter.wait(msg_id, timeout, 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 654, in wait 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver message = self.waiters.get(msg_id, timeout=timeout) 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 520, in get 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver raise oslo_messaging.MessagingTimeout( 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 3dad7dbe8ea9429c83958b98bccc7094 2025-03-23 10:31:26.974 7 ERROR nova.virt.libvirt.driver All services are in a "down" state, but this issue only occurs when using a three-controller cluster. When I use a single controller, everything works fine. My Env: OS: Ubuntu 22.04 OpenStack Version: 2025.1 Master Deployment Tool: Kolla-Ansible 19 Thank you. Nguyen Huu Khoi

3 7

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

24 Mar '25

Hello Stackers, We're one week away from the coordinated release of OpenStack 2025.1 ("Epoxy") [1]. Project teams shipped release candidates over the past week and will keep these updated if any release-critical bugs are identified. Teams are also preparing for the virtual OpenInfra Project Teams Gathering (PTG) [2], which begins on April 7. OpenStack project teams are encouraged to schedule cross-project meetings during the first two days. The OpenStack Technical Committee will meet with contributors to chart out our tasks to aid the next release, 2025.2 "Flamingo." The TC sessions are scheduled at the beginning and end of the PTG. We hope to discuss governance, community goals, and other work affecting the entire community. Please find the etherpad of the OpenStack TC's discussions [3], and feel free to propose new topics! In the past week, the TC appointed its chair (me!) and vice-chair (Dmitriy Rabotyagov / noonedeadpunk). We thank the members of the TC and the community for their continued faith in our work. Additionally, a proposal has been made to change the Vulnerability Management Team's (VMT) work, which will affect all project teams [4]. The proposal aims to place all project teams under VMT's oversight. Your feedback on this proposal is welcome! === Weekly Meeting === The OpenStack TC met on OFTC's #openstack-tc channel for its weekly meeting on 2025-03-18 [5]. We began with a discussion around the former openstack-operators mailing list. This mailing list was merged with the openstack-discuss mailing list after extensive prior discussion. The TC received some feedback in recent months from operators who wished to revive a dedicated list for operator discussions. Some operators feel project maintainers don’t engage with their problems, and discussions now occur on other platforms. Mailing list engagement among operators is still present but could be improved. There will be an Operators Discussion at the PTG, and the TC will raise this concern to better understand operator feedback. The TC appreciated the work project teams did in conjunction with the release team to get release candidates posted across the board. We reviewed the state of the CI and welcomed the donation of cloud resources that aided in Zuul's scalability around this critical time of the release. The next meeting of the OpenStack Technical Committee is today, 2025-03-25. It will be held at 18:00 UTC in the #openstack-tc channel on OFTC. Please find the agenda on the meeting's wiki page [6]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Add 2025.2 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/944174 - Add separate freezer-api deliverable | https://review.opendev.org/c/openstack/governance/+/944781 ==== Open for Review ==== - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 - Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 === Upcoming Events === - 2025-04-01 - 2025-04-04: KubeCon+CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2025-04-02: OpenStack 2025.1 ("Epoxy") Release - 2025-04-03: OpenInfra LIVE - Epoxy release - 2025-04-08: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-04-07 - 2025-04-12: 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] 2025.2 "Flamingo" PTG: https://openinfra.org/ptg/ [3] TC PTG Etherpad: https://etherpad.opendev.org/p/apr2025-ptg-os-tc [4] VMT proposal: https://review.opendev.org/c/openstack/governance/+/944817 [5] TC Meeting IRC Log 2025-03-18: https://meetings.opendev.org/meetings/tc/2025/tc.2025-03-18-18.00.log.html [6] TC Meeting Agenda, 2025-03-25: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Fwd: [Bug 2103448] Re: Extending `hosts` to also accept new `target_hosts` variable
by Dominic Dumrauf 24 Mar '25

24 Mar '25

Hi all, Could I interest someone in reviewing the *bifrost* - *bug* https://bugs.launchpad.net/bifrost/+bug/2103448 and its - *proposed solution* https://review.opendev.org/c/openstack/bifrost/+/944810 ? Many thanks and feel free to let me know how I can help. Cheers, Dominic ---------- Forwarded message --------- From: Afonne-CID <2103448(a)bugs.launchpad.net> Date: Wed, Mar 19, 2025 at 4:30 PM Subject: [Bug 2103448] Re: Extending `hosts` to also accept new `target_hosts` variable To: <dominic.dumrauf.git(a)gmail.com> Thanks for the bug and also proposing a change. You can get some eyes on your proposed change by asking about it in the #openstack-bifrost channel on IRC (if you haven't already). I personally think it LGTM. On the change, instead of "Bug #2103448: ", use 'Closes-Bug: #2103448' so that it directly references this report and gets automatically tracked and closed by the bot once resolved. ** Changed in: bifrost Status: New => Triaged ** Changed in: bifrost Importance: Undecided => Medium ** Changed in: bifrost Assignee: (unassigned) => Dominic Dumrauf (dumrauf) -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/2103448 Title: Extending `hosts` to also accept new `target_hosts` variable Status in Bifrost: Triaged Bug description: Many thanks for providing a single `install.yaml` playbook which installs `bifrost` in one go. Great work! It seems the hosts are fixed to target in the playbook. Would it be possible to make the playbook work with other inventories by introducing a new variable `target_hosts` as in PR https://review.opendev.org/c/openstack/bifrost/+/944810 ? The proposed change should be backwards compatible. To manage notifications about this bug go to: https://bugs.launchpad.net/bifrost/+bug/2103448/+subscriptions

1 0

[neutron] Bug deputy report for week 12 of 2025
by Jakub Libosvar 24 Mar '25

24 Mar '25

Hi all, I was the deputy for the last week. There are two bugs I left in “Undecided" that might not be in Neutron and need deeper understanding of what is going on. Undecided --------- - Race condition - Error creating instance if network is deleted by different process https://bugs.launchpad.net/neutron/+bug/2103500 It needs further investigation as it is unknown if the problem is with Neutron or Nova - Open vSwitch (Version 3.3.0) goes into deadlocked state https://bugs.launchpad.net/neutron/+bug/2103641 Based on the description of the bug it sounds like a problem with OVS rather than Neutron. High ---- - [FT] Random error in ``test_ovn_sb_sync_host_with_other_agent_type_not_deleted`` https://bugs.launchpad.net/neutron/+bug/2103424 Needs an assignee Wishlist -------- - [RFE][OVN] A L3 router tool https://bugs.launchpad.net/neutron/+bug/2103521

1 0

[heat][ptg] Topics for PTG April 2025
by Takashi Kajinami 24 Mar '25

24 Mar '25

Hi, I started updating the etherpard[1] for the heat sessions in upcoming PTG. If you are interested in joining the sessions then please add your name and your time zone. Also, please add any topics you want to discuss during these sessions. I'll reserve the slots based on these inputs, likely next week. [1] https://etherpad.opendev.org/p/apr2025-ptg-heat -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[openstack][rabbitmq]rabbitmq is broken
by Nguyễn Hữu Khôi 22 Mar '25

22 Mar '25

Hello. I am using rabbitmq quorum queue in my system. After I reboot the controllers, Now it has this debug message and my system runs under error. "repairing leader record" Nguyen Huu Khoi

2 3

[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

[openstack-ansible] Weird install failure
by Sarah Thompson 21 Mar '25

21 Mar '25

Hi all, I think I'm close to getting things working at this point, but I'm seeing a weird install failure during openstack.osa.setup_openstack: FAILED - RETRYING: [ostk-controller-heat-api-container-7d1e8599 -> ostk-controller-utility-container-db5068d8]: Add service users to roles (1 retries left).Result was: attempts: 5 censored: 'the output has been hidden due to the fact that ''no_log: true'' was specified for this result' changed: false retries: 6 Using module file /etc/ansible/ansible_collections/openstack/cloud/plugins/modules/role_assignment.py Pipelining is enabled. <ostk-controller> ESTABLISH SSH CONNECTION FOR USER: root <ostk-controller> SSH: ansible.cfg set ssh_args: (-C)(-o)(ControlMaster=auto)(-o)(ControlPersist=300) <ostk-controller> SSH: ANSIBLE_HOST_KEY_CHECKING/host_key_checking disabled: (-o)(StrictHostKeyChecking=no) <ostk-controller> SSH: ANSIBLE_REMOTE_PORT/remote_port/ansible_port set: (-o)(Port=22) <ostk-controller> SSH: ansible_password/ansible_ssh_password not set: (-o)(KbdInteractiveAuthentication=no)(-o)(PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey)(-o)(PasswordAuthentication=no) <ostk-controller> SSH: ANSIBLE_REMOTE_USER/remote_user/ansible_user/user/-u set: (-o)(User="root") <ostk-controller> SSH: ANSIBLE_TIMEOUT/timeout set: (-o)(ConnectTimeout=5) <ostk-controller> SSH: Set ssh_extra_args: (-o)(UserKnownHostsFile=/dev/null)(-o)(StrictHostKeyChecking=no)(-o)(ServerAliveInterval=64)(-o)(ServerAliveCountMax=1024)(-o)(Compression=no)(-o)(TCPKeepAlive=yes)(-o)(VerifyHostKeyDNS=no)(-o)(ForwardX11=no)(-o)(ForwardAgent=yes)(-T) <ostk-controller> SSH: found only ControlPersist; added ControlPath: (-o)(ControlPath="/root/.ansible/cp/d3dfd6cdfc") <ostk-controller> SSH: EXEC ssh -vvvvv -C -o ControlMaster=auto -o ControlPersist=300 -o StrictHostKeyChecking=no -o Port=22 -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="root"' -o ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ServerAliveInterval=64 -o ServerAliveCountMax=1024 -o Compression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no -o ForwardAgent=yes -T -o 'ControlPath="/root/.ansible/cp/d3dfd6cdfc"' ostk-controller 'sudo lxc-attach --clear-env --name ostk-controller-utility-container-db5068d8 -- su - root -c '"'"'/bin/sh -c '"'"'"'"'"'"'"'"'/openstack/venvs/utility-30.1.0.dev46/bin/python && sleep 0'"'"'"'"'"'"'"'"''"'"'' <ostk-controller> rc=1, stdout and stderr censored due to no log <ostk-controller> Failed to connect to the host via ssh: <error censored due to no log> failed: [ostk-controller-heat-api-container-7d1e8599 -> ostk-controller-utility-container-db5068d8(192.168.100.117)] (item=None) => attempts: 5 censored: 'the output has been hidden due to the fact that ''no_log: true'' was specified for this result' changed: false fatal: [ostk-controller-heat-api-container-7d1e8599 -> {{ _service_setup_host }}]: FAILED! => censored: 'the output has been hidden due to the fact that ''no_log: true'' was specified for this result' changed: false These logs came from running ansible with -vvvvv as a parameter. Looking at the failed ssh, this root causes pretty straightforwardly: ssh -vvvvv -C -o ControlMaster=auto -o ControlPersist=300 -o StrictHostKeyChecking=no -o Port=22 -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="root"' -o ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ServerAliveInterval=64 -o ServerAliveCountMax=1024 -o Compression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no -o ForwardAgent=yes -T -o 'ControlPath="/root/.ansible/cp/d3dfd6cdfc"' ostk-controller 'sudo lxc-attach --clear-env --name ostk-controller-utility-container-db5068d8 -- su - root -c '"'"'/bin/sh -c '"'"'"'"'"'"'"'"'/openstack/venvs/utility-30.1.0.dev46/bin/python && sleep 0'"'"'"'"'"'"'"'"''"'"'' If I manually ssh to ostk-controller and lxc-attach -n ostk-controller-utility-container-db5068d8, then run the command explicitly: root@ostk-controller-utility-container-db5068d8:~# /openstack/venvs/utility-30.1.0.dev46/bin/python && sleep 0 Python 3.10.12 (main, Feb 4 2025, 14:57:36) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> KeyboardInterrupt >>> exit() So basically it's invoking an interactive python session, which of course times out, and after 5 retries the installation aborts. Something is obviously missing somewhere, most likely a parameter after the python command which specifies a python script to be run. Any ideas? Thanks all, Sarah

2 1

[cinder][nova] force detach volume
by Arnaud Morin 21 Mar '25

21 Mar '25

Hey team, Is there any way to force detach a volume when the nova compute service is down? Like when the hypervisor is off, we want to detach the volume and attach it to another instance. Maybe I'm missing the way to do it, but detach action on nova side seems a synchronous task that I can't force without admin creds. Thanks for any help, Regards, Arnaud

4 6

[release] Release countdown for week R-1, Mar 24 - 28
by Elõd Illés 21 Mar '25

21 Mar '25

(re-sent this mail with the right week number in subject, sry :S) Development Focus ----------------- We are on the final mile of the 2025.1 Epoxy development cycle! Remember that the 2025.1 Epoxy final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. March 28th, 2025 is the deadline for final 2025.1 Epoxy release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on April 2nd, 2025. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2025.2 Flamingo development cycle, including discussing Forum and PTG sessions content, in preparation of Project Teams Gathering (virtual), April 7th-11th, 2025. Actions ------- Watch for any translation patches coming through on the stable/2025.1 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2025.1 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

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

21 Mar '25

Development Focus ----------------- We are on the final mile of the 2025.1 Epoxy development cycle! Remember that the 2025.1 Epoxy final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. March 28th, 2025 is the deadline for final 2025.1 Epoxy release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on April 2nd, 2025. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2025.2 Flamingo development cycle, including discussing Forum and PTG sessions content, in preparation of Project Teams Gathering (virtual), April 7th-11th, 2025. Actions ------- Watch for any translation patches coming through on the stable/2025.1 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2025.1 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0