- openstack-discuss - lists.openstack.org

[release] Release countdown for week R-3
by Thierry Carrez 07 Mar '25

07 Mar '25

Development Focus ----------------- The Release Candidate (RC) deadline is next Friday, March 14th, 2025. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2025.1 branch will be cut. This branch will track the 2025.1 Epoxy release. Once stable/2025.1 has been created, the master branch will be ready to switch to 2025.2 Flamingo development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2025.1 Epoxy plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2025.1 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2025.1 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be Flamingo development) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2025.1 Epoxy release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 14th, 2025 (R-3 week) Final RC deadline: March 28th, 2025 (R-1 week) Final 2025.1 Epoxy release: April 2nd, 2025 Project Teams Gathering (virtual): April 7th-11th, 2025 -- Thierry Carrez (ttx)

1 0

[openstack-helm] Inquiry: OpenStack-Helm Deployment in Production Environments
by Thamanna Farhath 07 Mar '25

07 Mar '25

Hello OpenStack Community, I hope this email finds you well. I am currently exploring OpenStack-Helm for deploying OpenStack and would like to understand its adoption in live production environments. Specifically, I am interested in knowing if any cloud providers have successfully deployed and are operating OpenStack using OpenStack-Helm in production. If there are any case studies, references, or experiences shared by operators who have implemented this deployment method, I would greatly appreciate any insights or guidance. Looking forward to your valuable input. Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 5

SRIOV on 2024.1 caracal
by Manohar Kundapura (makundap) 07 Mar '25

07 Mar '25

Hi Everyone, I have the 2024.1 Caracal multi node setup working. Now I am trying to enable SRIOV on this setup by following the below link, https://docs.openstack.org/neutron/2024.1/admin/config-sriov.html Observing the below issue while running the “neutron-sriov-agent” service on compute node and it is restarting on every 2 seconds. Kindly let me know if I need to enable any configs specific to “neutron-sriov-agent” service. # tail -f /var/log/neutron/neutron-sriov-agent.log 2025-03-06 15:02:42.968 9311 INFO neutron.common.config [-] Logging enabled! 2025-03-06 15:02:42.969 9311 INFO neutron.common.config [-] /usr/bin/neutron-sriov-nic-agent version 24.0.0 2025-03-06 15:02:42.969 9311 DEBUG neutron.common.config [-] command line: /usr/bin/neutron-sriov-nic-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/sriov_agent.ini --log-file=/var/log/neutron/neutron-sriov-agent.log setup_logging /usr/lib/python3/dist-packages/neutron/common/config.py:123 2025-03-06 15:02:42.970 9311 DEBUG neutron.agent.common.utils [-] Std library socket module is patched by eventlet. Requesting std library socket module from eventlet. __init__ /usr/lib/python3/dist-packages/neutron/agent/common/utils.py:91 2025-03-06 15:02:42.971 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [-] Physical Devices mappings: {'vf_inside': ['enp216s0f0'], 'vf_outside': ['enp216s0f1']} 2025-03-06 15:02:42.971 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [-] Exclude Devices: {} 2025-03-06 15:02:42.972 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [-] Resource provider bandwidths: {} 2025-03-06 15:02:42.972 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [-] Resource provider inventory defaults: {'allocation_ratio': 1.0, 'min_unit': 1, 'step_size': 1, 'reserved': 0} 2025-03-06 15:02:42.972 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [-] Resource provider hypervisors: {'enp216s0f1': 'u36c01p06-ostest-cmp2.openstack.local', 'enp216s0f0': 'u36c01p06-ostest-cmp2.openstack.local'} 2025-03-06 15:02:42.973 9311 DEBUG neutron.plugins.ml2.drivers.mech_sriov.agent.eswitch_manager [-] Number of VFs configured on device enp216s0f0: 8 get_numvfs /usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/mech_sriov/agent/eswitch_manager.py:134 2025-03-06 15:02:42.973 9311 DEBUG neutron.plugins.ml2.drivers.mech_sriov.agent.eswitch_manager [-] Number of VFs configured on device enp216s0f1: 8 get_numvfs /usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/mech_sriov/agent/eswitch_manager.py:134 2025-03-06 15:02:42.976 9311 DEBUG neutron.agent.securitygroups_rpc [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Init firewall settings (driver=noop) init_firewall /usr/lib/python3/dist-packages/neutron/agent/securitygroups_rpc.py:124 2025-03-06 15:02:42.976 9311 INFO neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] RPC agent_id: nic-switch-agent.u36c01p06-ostest-cmp2 2025-03-06 15:02:42.981 9311 INFO neutron.agent.agent_extensions_manager [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Loaded agent extensions: [] 2025-03-06 15:02:43.037 9311 WARNING oslo.messaging._drivers.impl_rabbit [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true': amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.038 9311 INFO oslo.messaging._drivers.impl_rabbit [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] [7d2d8221-cd72-4203-b717-46c9d4fac7a9] Retrying to declare the exchange (q-agent-notifier-port-update_fanout) as non durable 2025-03-06 15:02:43.041 9311 ERROR oslo.messaging._drivers.impl_rabbit [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Failed to declare consumer for topic 'q-agent-notifier-port-update': Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true': amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.046 9311 ERROR oslo.messaging._drivers.impl_rabbit [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Unable to connect to AMQP server on 10.10.4.19:5671 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true': amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.047 9311 CRITICAL neutron [None req-617911dd-c075-4154-967b-a8ad1c334d34 - - - - - -] Unhandled error: oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 10.10.4.19:5671 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.047 9311 ERROR neutron Traceback (most recent call last): 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 421, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron self.queue.declare() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 605, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron self._create_exchange(nowait=nowait, channel=channel) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 612, in _create_exchange 2025-03-06 15:02:43.047 9311 ERROR neutron self.exchange.declare(nowait=nowait, channel=channel) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 180, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron return (channel or self.channel).exchange_declare( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/channel.py", line 612, in exchange_declare 2025-03-06 15:02:43.047 9311 ERROR neutron self.send_method( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 66, in send_method 2025-03-06 15:02:43.047 9311 ERROR neutron return self.wait(wait, returns_tuple=returns_tuple) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 86, in wait 2025-03-06 15:02:43.047 9311 ERROR neutron self.connection.drain_events(timeout=timeout) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 522, in drain_events 2025-03-06 15:02:43.047 9311 ERROR neutron while not self.blocking_read(timeout): 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 528, in blocking_read 2025-03-06 15:02:43.047 9311 ERROR neutron return self.on_inbound_frame(frame) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/method_framing.py", line 53, in on_frame 2025-03-06 15:02:43.047 9311 ERROR neutron callback(channel, method_sig, buf, None) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 534, in on_inbound_method 2025-03-06 15:02:43.047 9311 ERROR neutron return self.channels[channel_id].dispatch_method( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 143, in dispatch_method 2025-03-06 15:02:43.047 9311 ERROR neutron listener(*args) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/channel.py", line 281, in _on_close 2025-03-06 15:02:43.047 9311 ERROR neutron raise error_for_code( 2025-03-06 15:02:43.047 9311 ERROR neutron amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.047 9311 ERROR neutron 2025-03-06 15:02:43.047 9311 ERROR neutron During handling of the above exception, another exception occurred: 2025-03-06 15:02:43.047 9311 ERROR neutron 2025-03-06 15:02:43.047 9311 ERROR neutron Traceback (most recent call last): 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1036, in ensure 2025-03-06 15:02:43.047 9311 ERROR neutron ret, channel = autoretry_method() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/connection.py", line 524, in _ensured 2025-03-06 15:02:43.047 9311 ERROR neutron return fun(*args, **kwargs) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/connection.py", line 600, in __call__ 2025-03-06 15:02:43.047 9311 ERROR neutron return fun(*args, channel=channels[0], **kwargs), channels[0] 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1025, in execute_method 2025-03-06 15:02:43.047 9311 ERROR neutron method() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1262, in _declare_consumer 2025-03-06 15:02:43.047 9311 ERROR neutron consumer.declare(self) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 431, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron self._declare_fallback(err, conn, consumer_arguments) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 396, in _declare_fallback 2025-03-06 15:02:43.047 9311 ERROR neutron self.queue.declare() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 605, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron self._create_exchange(nowait=nowait, channel=channel) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 612, in _create_exchange 2025-03-06 15:02:43.047 9311 ERROR neutron self.exchange.declare(nowait=nowait, channel=channel) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/kombu/entity.py", line 180, in declare 2025-03-06 15:02:43.047 9311 ERROR neutron return (channel or self.channel).exchange_declare( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/channel.py", line 612, in exchange_declare 2025-03-06 15:02:43.047 9311 ERROR neutron self.send_method( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 66, in send_method 2025-03-06 15:02:43.047 9311 ERROR neutron return self.wait(wait, returns_tuple=returns_tuple) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 86, in wait 2025-03-06 15:02:43.047 9311 ERROR neutron self.connection.drain_events(timeout=timeout) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 522, in drain_events 2025-03-06 15:02:43.047 9311 ERROR neutron while not self.blocking_read(timeout): 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 528, in blocking_read 2025-03-06 15:02:43.047 9311 ERROR neutron return self.on_inbound_frame(frame) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/method_framing.py", line 53, in on_frame 2025-03-06 15:02:43.047 9311 ERROR neutron callback(channel, method_sig, buf, None) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/connection.py", line 534, in on_inbound_method 2025-03-06 15:02:43.047 9311 ERROR neutron return self.channels[channel_id].dispatch_method( 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/abstract_channel.py", line 143, in dispatch_method 2025-03-06 15:02:43.047 9311 ERROR neutron listener(*args) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/amqp/channel.py", line 281, in _on_close 2025-03-06 15:02:43.047 9311 ERROR neutron raise error_for_code( 2025-03-06 15:02:43.047 9311 ERROR neutron amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.047 9311 ERROR neutron 2025-03-06 15:02:43.047 9311 ERROR neutron During handling of the above exception, another exception occurred: 2025-03-06 15:02:43.047 9311 ERROR neutron 2025-03-06 15:02:43.047 9311 ERROR neutron Traceback (most recent call last): 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/bin/neutron-sriov-nic-agent", line 10, in <module> 2025-03-06 15:02:43.047 9311 ERROR neutron sys.exit(main()) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/cmd/eventlet/plugins/sriov_nic_neutron_agent.py", line 27, in main 2025-03-06 15:02:43.047 9311 ERROR neutron agent_main.main() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py", line 568, in main 2025-03-06 15:02:43.047 9311 ERROR neutron agent = SriovNicSwitchAgent(device_mappings, 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py", line 181, in __init__ 2025-03-06 15:02:43.047 9311 ERROR neutron self.connection.consume_in_threads() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/neutron_lib/rpc.py", line 345, in consume_in_threads 2025-03-06 15:02:43.047 9311 ERROR neutron server.start() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/server.py", line 267, in wrapper 2025-03-06 15:02:43.047 9311 ERROR neutron states[state].run_once(lambda: fn(self, *args, **kwargs), 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/server.py", line 188, in run_once 2025-03-06 15:02:43.047 9311 ERROR neutron post_fn = fn() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/server.py", line 267, in <lambda> 2025-03-06 15:02:43.047 9311 ERROR neutron states[state].run_once(lambda: fn(self, *args, **kwargs), 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/server.py", line 413, in start 2025-03-06 15:02:43.047 9311 ERROR neutron self.listener = self._create_listener() 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py", line 150, in _create_listener 2025-03-06 15:02:43.047 9311 ERROR neutron return self.transport._listen(self._target, 1, None) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/transport.py", line 142, in _listen 2025-03-06 15:02:43.047 9311 ERROR neutron return self._driver.listen(target, batch_size, 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 709, in listen 2025-03-06 15:02:43.047 9311 ERROR neutron conn.declare_fanout_consumer(target.topic, listener) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1398, in declare_fanout_consumer 2025-03-06 15:02:43.047 9311 ERROR neutron self.declare_consumer(consumer) 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1273, in declare_consumer 2025-03-06 15:02:43.047 9311 ERROR neutron return self.ensure(_declare_consumer, 2025-03-06 15:02:43.047 9311 ERROR neutron File "/usr/lib/python3/dist-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1058, in ensure 2025-03-06 15:02:43.047 9311 ERROR neutron raise exceptions.MessageDeliveryFailure(msg) 2025-03-06 15:02:43.047 9311 ERROR neutron oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 10.10.4.19:5671 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'q-agent-notifier-port-update_fanout' in vhost 'neutron': received 'false' but current is 'true' 2025-03-06 15:02:43.047 9311 ERROR neutron Thanks, Manohar

3 2

[neutron] Drivers meeting canceled Friday, March 7th
by Brian Haley 06 Mar '25

06 Mar '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as discussed at this week's team meeting, since we are past feature freeze and should be focusing on getting in-flight things merged and bug fixes. Just a reminder there are still open specs that need review, list is at [0]. And just a reminder I am offline until next Tuesday. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

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

05 Mar '25

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

4 6

[nova][libvirt][qemu] Internal error: process exited while connecting to monitor
by Roby G 04 Mar '25

04 Mar '25

Hello everyone, After upgrading to Antelope i´m getting following errors when creating new volume-backed instance. Volumes are stored in a ceph pool. - nova: 27.4.0 - libvirt: 8.0.0 - qemu: 6.2.0 - Operating system: Ubuntu 22.04 ``` ERROR nova.virt.libvirt.driver [instance: f8fa30f3-3dc8-43bd-bc29-8ed23b15b1f2] Failed to start libvirt guest: libvirt.libvirtError: internal error: process exited while connecting to monitor: 2025-03-04T15:15:34.416946Z qemu-system-x86_64: -blockdev {"driver":"rbd","pool":"cinder","image":"volume-6dfe3084-ef9d-4107-8b69-b0036fefbed0","server":[{"host":"1.2.3.4","port":"1234"},{"host":"1.2.3.5","port":"1234"},{"host":"1.2.3.6","port":"1234"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-1-storage-auth-secret0","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: error connecting: Permission denied libvirtd[50229]: internal error: process exited while connecting to monitor: 2025-03-04T15:15:34.416946Z qemu-system-x86_64: -blockdev {"driver":"rbd","pool":"cinder","image":"volume-6dfe3084-ef9d-4107-8b69-b0036fefbed0","server":[{"host":"1.2.3.4","port":"1234"},{"host":"1.2.3.5","port":"1234"},{"host":"1.2.3.6","port":"1234"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-1-storage-auth-secret0","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: error connecting: Permission denied libvirtd[50229]: internal error: qemu unexpectedly closed the monitor: 2025-03-04T15:15:34.416946Z qemu-system-x86_64: -blockdev {"driver":"rbd","pool":"cinder","image":"volume-6dfe3084-ef9d-4107-8b69-b0036fefbed0","server":[{"host":"1.2.3.4","port":"1234"},{"host":"1.2.3.5","port":"1234"},{"host":"1.2.3.6","port":"1234"}],"user":"cinder","auth-client-required":["cephx","none"],"key-secret":"libvirt-1-storage-auth-secret0","node-name":"libvirt-1-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}: error connecting: Permission denied os-cmt7 libvirtd[50229]: Unable to read from monitor: Connection reset by peer ``` Any fixes/tips? From The compute node accessing the ceph pool using `rbd` client, there are no permission errors. Are this errors related to qemu monitor?

1 0

PTG April 2025 Teams List
by Kendall Nelson 04 Mar '25

04 Mar '25

Hello Everyone! The list of teams participating in the upcoming virtual PTG (April 7-11, 2025) is now official! Projects + Teams - OpenInfra Foundation Teams - - OpenInfra Diversity and Inclusion Working Group - Kata Containers - OpenStack - - Services - - Blazar - Cinder - CloudKitty - Designate - Glance - Heat - Horizon - Ironic - Keystone - Kolla - Manila - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack SDK/CLI - Sunbeam - Swift - Tacker - Watcher - Other OpenStack Teams - Eventlet Removal - i18n SIG - OpenStack for AI Working Group - OpenStack Security SIG - OpenStack Technical Committee - Public Cloud SIG - VMware Migration Working Group - StarlingX - Adjacent Open Source Communities - - OceanBase If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured for the teams that are signed up to attend the event. Etherpads for agenda planning and note taking will be automatically generated as a part of that configuration. Otherwise, please don't forget to register[2] — it's FREE! Also, it does help us with event coordination and communication, so please take a moment to register. As usual, feel free to let me know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://opendev.org/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: http://ptg.openinfra.org/

1 0

[neutron] LXB Removal and OVN migration
by Ricardo Cano 04 Mar '25

04 Mar '25

Hello openstack-discuss, With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN? I did come across this https://www.jimmdenton.com/migrating-lxb-to-ovn/ and that looks good as a one-shoit while biting the bullet and taking a full outage. However, I was wondering if it was possible to run lxb and ovn side-by-side and cut them over, say one network at a time. This particular deployment was stood up using openstack-ansible back in the rocky days (now running antelope) and it appears that openstack ansible's default was lxb up until Zed. Any suggestions or recommendations on the best path forward? Also, will the dynamic routing agent work with ovn?

7 8

Contributing to Openstack [Looking for Mentorship]
by jb03229422＠student.ku.edu.np 04 Mar '25

04 Mar '25

Dear Mentors, I have good experience in building openstack in multiple environments bare-metal, kolla-ansible and helm project for minimal deployment to good HA clusters. Now, I'm looking to get into code level and contribute to open-infra foundation. I'm not a someone beginner to coding, I have done programming in a good amount and hold a knowledge of paradigm and principles. Here's my github: https://github.com/jamesii-b I'm looking for mentor who can guide me what to do as a Contribution.. Even deploying first openstack is overwhelming on its own, Coding is more. Please have me. Trust me, I'll have utmost respect to your time and energy and get most of it. Knowledge I have: HPC, Openstack Deployment, Network & System, Parallel Programming, Python, Rust.

2 1

[tacker] Today's weekly meeting
by Yasufumi Ogawa 03 Mar '25

03 Mar '25

Hi tacker team, I might not be able to join today's meeting due to something urgent come up. Let me join the today's discussion by adding my comment on the etherpad later. Thanks, Yasufumi

1 0

[neutron] Bug deputy report for week of February 24th
by Brian Haley 03 Mar '25

03 Mar '25

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2100001 - [FT] Random errors in ``test_server.TestPluginWorker.test_start`` - https://review.opendev.org/c/openstack/neutron/+/942798 * https://bugs.launchpad.net/neutron/+bug/2100261 - [FT] Consistent errors in ``neutron-functional-with-pyroute2-master`` CI job - https://github.com/svinota/pyroute2/issues/1181 might be related - Rodolfo took ownership * https://bugs.launchpad.net/neutron/+bug/2100270 - [whitebox-neutron-tempest-plugin] Missing method ``configure_vlan_transparent`` imported from neutron-tempest-plugin - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/942776 * https://bugs.launchpad.net/neutron/+bug/2099981 - [ovn] Adding an IPv6 subnet to public network breaks all FIPs - Still trying to reproduce * https://bugs.launchpad.net/neutron/+bug/2099982 - [ovn] Removal of IPv6 subnet from the public network is not reflected in LRs - Might be related to above OVN bug 2099981 * https://bugs.launchpad.net/neutron/+bug/2100294 - [ovn] Changing gateway for IPv6 subnet updates wrong routes family - Might be related to above OVN bug 2099982 Medium ------ * https://bugs.launchpad.net/neutron/+bug/2099911 - Castellan as config source fails with "greenlet.error: cannot switch to a different thread" - https://review.opendev.org/c/openstack/neutron/+/942622 - But don't think that might be necessary with us removing eventlet * https://bugs.launchpad.net/neutron/+bug/2100505 - Neutron OVN external ports creation change HA chassis group master - FT reproducer patch confirms issue - Needs owner Low --- * https://bugs.launchpad.net/neutron/+bug/2100479 - Segments plugin: Not updating used IP addresses - https://review.opendev.org/c/openstack/neutron/+/935990 might fix? Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2099896 - [eventlet-removal] Remove the usage of eventlet in the Metadata agent - Needs owner * https://bugs.launchpad.net/neutron/+bug/2100268 - cleanup os-ken from the CLI part - Needs owner * https://bugs.launchpad.net/neutron/+bug/2100585 - [metadata] Unify metadata code - Eventlet follow-up

1 0

[manila] March 6th weekly meeting cancelled
by Carlos Silva 03 Mar '25

03 Mar '25

Hello zorillas, As a big part of our audience will not be able to join this week's weekly meeting, we are cancelling it. In case you have something to bring up, please ping on IRC. We will resume our upstream weekly meetings on March 13th. Thank you, carloss

1 0

Installation guide: service_user_token clarification
by Eugen Block 03 Mar '25

03 Mar '25

Hi *, to me it's still a bit unclear, what exactly is required to properly set up service user tokens. The Yoga release notes point to the nova configuration guide [0], which only briefly describes the concept. But looking at the latest installation guide [1], there's also only a very short section with a link to the config page. But there's no mention of a service role that has to be created. If this is the default since Yoga, shouldn't the installation guides cover the entire process, including creating all necessary roles or the [keystone_authtoken] section that should probably contain "service_token_roles = service"? I currently find it quite confusing. Thanks! Eugen [0] https://docs.openstack.org/nova/latest/admin/configuration/service-user-tok… [1] https://docs.openstack.org/nova/2024.2/install/controller-install-ubuntu.ht…

1 0

[release][PTLs] Reminder to 2025.1 Epoxy Cycle highlights
by Elõd Illés 03 Mar '25

03 Mar '25

Hi, This is a gentle reminder that this week is the week when 2025.1 Epoxy's Cycle highlights should be finalized (now that the Feature Freeze deadline has passed) so that they can be included in release marketing preparations. Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

Problems with Cinder and iSCSI
by Alexander Luedtke 02 Mar '25

02 Mar '25

Hello Everyone, I have a really strange problem with iSCSI, Cinder, Kolla setup. 1. What I want to do: I did setup with kolla 1 Controller, 4 Compute nodes and 2 storage nodes (iSCSI, Cinder, LVM). Kolla Deploying works fine, all Machines can find all others. 2. Problem: happens when I try to create an instance * Im creating an new instance what fails because the cinder volume couldn't be "mounted" on the compute node * What I checked then: o storage2 (the 2. cinder iscsi storage node) is available (by ping ) from the compute node o Port 3260 on storage2 is not reachable from compute node o so checking storage2 + the volume was created on LVM (checked with lvs) + Port 3260 is not available local too + it looks like that cinder creates an iSCSI target and deletes it after some seconds ... no reason shown (I activated debug mode in Kolla in the hope to see more but no ...) Did anyone have some similar behavior or can give me a hint where else to look ? Thanks a lot for your help ! best Alex Logfile of the storage2 node /var/log/kolla/cinder/cinder-volume.log: the following lines came 5-6 times and then nothing more. 2025-03-03 08:17:02.625 42 DEBUG cinder.volume.drivers.lvm [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Updating volume stats _update_volume_stats /var/lib/kolla/venv/lib/python3.12/site-packages/cinder/volume/drivers/lvm.py:227 2025-03-03 08:17:02.626 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --noheadings --unit=g -o name,size,free,lv_count,uuid --separator : --nosuffix cinder-volumes execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 2025-03-03 08:17:03.057 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C vgs --noheadings --unit=g -o name,size,free,lv_count,uuid --separator : --nosuffix cinder-vo lumes" returned: 0 in 0.432s execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 2025-03-03 08:17:03.059 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o vg_name,name,size --nosuffix --readonly ci nder-volumes execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 2025-03-03 08:17:03.483 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o vg_name,name,size --nosuffix --readonly cinder-volumes" returne d: 0 in 0.425s execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 2025-03-03 08:17:03.485 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o size,data_percent --separator : --nosuffix /dev/cinder-volumes/cinder-volumes-pool execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 2025-03-03 08:17:03.899 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o size,data_percent --separator : --nosuffix /dev/cinder-volumes/ cinder-volumes-pool" returned: 0 in 0.414s execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 2025-03-03 08:17:03.900 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Running cmd (subprocess): sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o vg_name,name,size --nosuffix --readonly ci nder-volumes execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 2025-03-03 08:17:04.319 42 DEBUG oslo_concurrency.processutils [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] CMD "sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C lvs --noheadings --unit=g -o vg_name,name,size --nosuffix --readonly cinder-volumes" returne d: 0 in 0.418s execute /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 2025-03-03 08:17:04.320 42 DEBUG cinder.manager [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Notifying Schedulers of capabilities ... _publish_service_capabilities /var/lib/kolla/venv/lib/python3.12/site-packages/cinder/manager.py:202 2025-03-03 08:18:02.626 42 DEBUG oslo_service.periodic_task [None req-c3be57e8-eeac-4b14-99c7-f3f10474a3cf - - - - - -] Running periodic task VolumeManager.publish_service_capabilities run_periodic_tasks /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_service/periodic_task. py:210

1 0

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

02 Mar '25

Hello Stackers, Last week, we passed milestone-3 of the 2025.1 "Epoxy" release cycle [1]. With this, we're at the tail end of this release cycle. Next week, we'll be tagging release candidates across the board for all project deliverables following the "cycle-with-rc" release model. By the end of this week, Project Team Leads and liaisons are expected to submit release cycle highlights, capturing important updates that operators and users can expect from each project in the Epoxy release. In the past week, election officials finalized the results of the PTL and TC elections for the next release cycle: 2025.2 "Flamingo" [2][3]. Please join me in congratulating these individuals. I'm especially excited to see a long lineup of first-time PTLs: Matt Crees (mattcrees) leading Blazar, Omer Schwartz (oschwart) leading Designate, Cyril Roelandt (croelandt) leading Glance, Artem Goncharov (gtema) leading Keystone, Dale Smith (dalees) leading Magnum, René Ribaud (uggla) leading Nova, Juan Larriba leading Telemetry, and Jiasirui leading Venus. The community is grateful to past PTLs, many of whom have mentored these new leaders. Additionally, Michal Nasiadka (mnasiadka) has joined the OpenStack TC, replacing Slawek Kaplonski (slaweq), who has served on the TC since the Zed cycle. Thank you for your service, and congratulations! I'd also like to thank Slawek and Ian Y Choi (ianychoi) for their service as the election officials. Later this week, the North American section of the OpenInfra Community will gather in Pasadena, CA, alongside SCALE 2025 [4]. I invite you to join community leaders at the OpenInfra Leadership meet-and-greet event if you're attending. Helena Spease (hspease) tells me there'll be cake to celebrate OpenStack's 15th birthday! [5] === Weekly Meeting === The OpenStack TC met on 2025-02-25 over IRC [6]. The election results were discussed, and we paid special attention to "leaderless" project teams—i.e., teams where no PTL nominations were accepted before the deadline: Oslo, Barbican, Masakari, OpenStack Charms, and Zaqar. Of these, the Oslo team decided to continue following a Distributed Project Leadership model, while the remaining teams are pending PTL appointments. The TC is in discussions with potential candidates. We also shared the TC's PTG Planning Etherpad [7] during the meeting. The TC and the community are encouraged to add topics to this etherpad. The next meeting of the OpenStack TC will be held simultaneously on video (Zoom) and IRC (#openstack-tc on OFTC) tomorrow, 2025-03-04. Please find the agenda for this meeting on the meeting wiki [8]. I hope you'll be able to join us. Remember that you can propose topics for the weekly TC meetings by editing this wiki page. Please leave your IRC nick next to the topic proposed so we can call on you during the meeting. === Governance Proposals === ==== Merged ==== Add TC/PTL results from 2025.2 election | https://review.opendev.org/c/openstack/governance/+/942507 Add Extra-ACs to the tech committee repos | https://review.opendev.org/c/openstack/governance/+/942296 ==== Open for Review ==== Appoint Mauricio Harley as PTL for Barbican | https://review.opendev.org/c/openstack/governance/+/942907 Switch back Oslo to DPL model | https://review.opendev.org/c/openstack/governance/+/942793 Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === - 2025-03-06: SCALE 2025 + OpenInfra Days NA (Link) - 2025-03-11: OpenInfra Board Meeting (Link) - 2025-04-02: OpenStack 2025.1 ("Epoxy") Release - 2025-04-07 - 2025-04-11: OpenInfra PTG === How to Contact the TC === You can reach the TC in several ways: - Email: Send an email with the tag [tc] on this mailing list. - IRC: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Meetings: Join us at our weekly meeting. The Technical Committee meets every Tuesday at 1800 UTC [8]. 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 TC Election Results: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] 2025.2 PTL Election Results: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] OpenInfraDays @ SCALE 2025: https://www.socallinuxexpo.org/scale/22x/events/open-infra-days [5] Celebrating 15 years of OpenStack: https://www.openstack.org/blog/celebrating-15-years-of-openstack/ [6] TC Meeting IRC Log 2025-02-25: https://meetings.opendev.org/meetings/tc/2025/tc.2025-02-25-18.00.log.html [7] TC 2025.2 PTG Planning Etherpad: https://etherpad.opendev.org/p/apr2025-ptg-os-tc [8] TC Meeting Agenda, 2025-03-04: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

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

02 Mar '25

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

4 7

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

28 Feb '25

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

3 2

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

28 Feb '25

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

1 1

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

28 Feb '25

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

1 0

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

28 Feb '25

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

3 3

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

27 Feb '25

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

2 1

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

27 Feb '25

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

1 0

Problem to delete volume backup
by franck 27 Feb '25

27 Feb '25

2 1

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

27 Feb '25

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

4 3

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

26 Feb '25

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

1 0

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

26 Feb '25

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

2 6

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

26 Feb '25

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

3 2

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

26 Feb '25

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

1 0

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

26 Feb '25

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

2 1

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

26 Feb '25

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

1 0

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

26 Feb '25

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

1 0

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

26 Feb '25

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

2 1

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

25 Feb '25

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

3 2

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

25 Feb '25

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

1 0

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

24 Feb '25

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

1 0

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

24 Feb '25

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

5 9

Keystone Tokenless
by Ryan Belgrave 24 Feb '25

24 Feb '25

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

1 0

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

24 Feb '25

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

2 2

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

24 Feb '25

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

5 6

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

24 Feb '25

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

1 0

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

24 Feb '25

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

3 3

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

24 Feb '25

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

2 2

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

24 Feb '25

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

1 0

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

22 Feb '25

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

1 0

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

22 Feb '25

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

2 1

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

21 Feb '25

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

1 0

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

20 Feb '25

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

1 0

OVN in latest OpenStack
by Jani Heikkinen 20 Feb '25

20 Feb '25

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

5 10

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

20 Feb '25

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

2 1