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

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

22 Mar '25

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

4 6

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

21 Mar '25

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

1 0

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

21 Mar '25

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

1 0

[neutron] Drivers meeting canceled Friday, March 21st
by Brian Haley 21 Mar '25

21 Mar '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as I have a conflict and cannot attend. Let's just add any new RFE items to the agenda for the upcoming PTG [0] - I'll try and group them all together in our Thursday meeting slots if possible. Just a reminder there are still open specs that need review, list is at [1], would be good to get them merged. Have a nice weekend! -Brian [0] https://etherpad.opendev.org/p/apr2025-ptg-neutron [1] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[ironic] [operators] Inspector service deprecated; scope assumed by Ironic
by Jay Faulkner 19 Mar '25

19 Mar '25

OpenStack developers and deployers, In 2014, Dmitry Tantsur created a project to allow deployers of Ironic to inspect nodes and discover and enroll new nodes -- ironic-inspector. This project has become a staple, deployed alongside other Ironic services in most common deployments. Over the last couple of years, we've worked on -- and now completed -- a migration all existing ironic-inspector functionality into the primary Ironic service. As a result of that, the service/project at openstack/ironic-inspector and it's client at openstack/python-ironic-inspector-client have both been in maintenance mode since 2024. Users of Ironic should not expect future releases of ironic-inspector past this SLURP release of OpenStack 2025.1. If you have any issues migrating to the in-tree inspection functionality in Ironic, please reach out to the Ironic team on the mailing list, in IRC, or wherever else you may find us. Thanks, Jay Faulkner Ironic Security Liason

1 0

[neutron][l3 agent] pymysql.err.IntegrityError (Duplicate entry) while updating router information
by Viacheslav Klenov 19 Mar '25

19 Mar '25

Hello, We ran into a strange issue with neutron l3_agent after failed live-migration, which failed due to pyroute2/iproute2 version incompatibility issue During live-migration l3 agent starts to update router information but then logs a lot of errors 2025-03-13 12:28:18.041 43002 ERROR neutron.agent.l3.agent [-] Failed to fetch router information for '4b89508c-beaf-43cf-92a6-9e080c03554d': oslo_messaging.rpc.client.RemoteError: Remote error: PendingRollbackError This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (pymysql.err.IntegrityError) (1062, "Duplicate entry '506ac36d-4e5c-47a1-96ca-36f739018dfe-hv-017' for key 'PRIMARY'") [SQL: INSERT INTO ml2_distributed_port_bindings (port_id, host, router_id, vif_type, vif_details, vnic_type, profile, status) VALUES (%(port_id)s, %(host)s, %(router_id)s, %(vif_type)s, %(vif_details)s, %(vnic_type)s, %(profile)s, %(status)s)] [parameters: {'port_id': '506ac36d-4e5c-47a1-96ca-36f739018dfe', 'host': 'hv-017', 'router_id': '4b89508c-beaf-43cf-92a6-9e080c03554d', 'vif_type': 'unbound', 'vif_details': '', 'vnic_type': 'normal', 'profile': '', 'status': 'DOWN'}] (log attached) Before the migration there is no records in neutron ml2_distributed_port_bindings table with a hostname from the error after the errors the migrated VM is seemingly functional The error reproduces every time on live-migration even after pyroute2/iproute2 incompatibility was fixed Any insight into why is this happening or a way to fix it would be greatly appreciated -- Viacheslav ----------------- Viacheslav Klenov vklenov(a)sardinasystems.com | www.sardinasystems.com | @sardinasystems | https://www.linkedin.com/company/sardina-systems "We build technology so that others can build more technology.”

2 2

Guidance on Deploying Octavia with VXLAN in Nested OpenStack Setup
by Thamanna Farhath 19 Mar '25

19 Mar '25

Dear OpenStack Community, I am currently using OpenStack 2023.1 and looking to deploy Octavia using VXLAN networking. My setup consists one parent openstack environment, and within this, I have an nested OpenStack deployment in which I want to configure Octavia with VXLAN. I would appreciate any guidance on the following: Network Configuration: Best practices for setting up VXLAN tunnels in a nested OpenStack environment. Octavia Deployment: Steps or references for installing Octavia with VXLAN networking. Integration with Neutron: Any specific settings required to ensure proper communication between the parent network and the nested OpenStack deployment. Reference Documentation: Any official or community-driven guides that can help with this setup. If anyone has experience with a similar deployment or has documentation to refer to, I would be grateful for your insights. Thank you in advance for your help! 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

Spice, NoVNC and TLS
by Jani Heikkinen 19 Mar '25

19 Mar '25

Dear Openstack community, I would be happy to hear if anybody has configured Spice or noVNC console with TLS. Is this possible with using spicehtml5proxy? As far I know, it is easy to set up the TLS until the server running spiche5html(or noVNC). And according to Websockets documentation, it will only establish itself over existing http connection. How the proxy actually forms this connection? Is it possible to pass TLS certificates to it? My requirement would also be, that self-signed certificates are no-go. Best, and thanks, Jani -- 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

4 5

MAC address associated with the FIP (Floating IP) appears as "INCOMPLETE"
by ussefelboukhari＠gmail.com 18 Mar '25

18 Mar '25

Hello ! I hope this message finds you well. I am reaching out to share a problem I’m currently facing, and I would greatly appreciate your assistance or any suggestions you might have. I deployed a bare metal EC2 instance on AWS to set up an all-in-one deployment using Kolla Ansible, but I’ve encountered some issues, which are as follows: Initially, we noticed that our instances were unable to access the metadata stored on nova-compute to retrieve essential information such as the private IP address and SSH keys. For example, when running the `ip a` command on an instance, the private IP address did not appear. After some research, we discovered that this bug was already known. The solution we implemented was to use OVN instead of OVS. This change allowed our instances to access the metadata on nova-compute and retrieve the private IP addresses. However, there is still an anomaly: when we run the `arp -n` command on the host machine, the MAC address associated with the FIP (Floating IP) appears as "INCOMPLETE". I would be grateful if you could provide any insights or suggestions to help resolve this issue. Thank you in advance for your support!

1 0

[cinder]Need some help for merging the bug fixing commits
by hao wang 18 Mar '25

18 Mar '25

Hi, guys It is possible that get your help reviewing and merging those two bug-fixing commits? They have been there for a long time and have discussed for many rounds. If there are no further concerns, could we merge it in the new cycle? Thanks a lot. [1]https://review.opendev.org/c/openstack/cinder/+/740146 [2]https://review.opendev.org/c/openstack/cinder/+/734415 Regards, Hao Wang -- Best Wishes To You!

1 0

[administrivia] Recent change in moderation for new subscribers
by Jeremy Stanley 18 Mar '25

18 Mar '25

Due to a spate of spammers subscribing to openstack-discuss over the last several days in order to send off-topic messages to the list, I've altered the default behavior for posts from new subscribers. For now, if someone subscribes, their initial post to the list will be held for moderation in order for our moderators to make sure it's a legitimate post, before setting their subscription to bypass moderation for any subsequent posts they make. Note that this only affects new subscriptions as of now, anyone who has already subscribed to the list before now should see no change in how things work for them. As for the spam to the list for the past few days, I've blocked those subscribers from sending any new messages and deleted their off-topic posts from the public archive. Please let me know if you have any questions. -- Jeremy Stanley

1 0

[nova][cinder][glance] Support for rbd namespaces
by Eugen Block 18 Mar '25

18 Mar '25

Hi, I've been searching and testing for a while, but I haven't found anything helpful yet. Someone in the Ceph community brought up the question about rbd namespaces for nova, cinder and glance. It would make sense to use only one pool for those services with regards to PG numbers. Having multiple pools means to manage their pg_num individually, and scaling can be limited due to the max number of PGs per OSD. Having only one pool would make that easier. I mean, we've been using a single pool for those three services from the beginning, but without a permission segregation. Is there anything on the road map to support rbd namespaces? Or has there been something and it was decided not to go down that road? I'd appreciate any insights! Thanks! Eugen

1 0

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

18 Mar '25

Hello Stackers, We're two weeks away from the release date for the 2025.1 ("Epoxy") coordinated release [1]. OpenStack project teams worked with the release team to make the first release candidate (RC) available for wider testing. Over the next couple of weeks, any release-critical bugs may require revised RCs. Now's a good time to review release highlights [2] that project teams have added to reflect major changes made during this release. Development focus has shifted to the next release, 2025.2 "Flamingo" [3]. Last week was eventful. The OpenInfra Foundation board unanimously approved resolutions that further its move to become a sub-foundation of the Linux Foundation [4]. For many of you who are members of the foundation, you will have an opportunity to ratify the board's decisions through a vote next month. In the past week, the OpenStack Technical Committee didn't merge any new governance updates; however, several are open for community review. === Weekly Meeting === The TC's weekly meeting in OFTC's #openstack-tc channel on 2025-03-11 was well attended [5]. We were joined by several attendees of the OpenInfra Days North America event to discuss key takeaways and gather action items for the TC. There was broad acknowledgment that many presentations and discussions at the event revolved around Running AI workloads on OpenStack and aiding the migration of enterprises that are transitioning to OpenStack from existing commercial/proprietary solutions We expressed interest in participating in working group discussions at the upcoming PTG on both these topics. Additionally, we revisited community pain points that were brainstormed at the event. Two notable issues were: - The need for an official presence on communication platforms beyond OFTC/IRC - The lack of sufficient engagement from operators on the openstack-discuss mailing list No immediate actions were taken on these issues during the meeting, but both topics generated significant discussion. We expect to gather input from the wider community during the upcoming PTG. The next OpenStack TC meeting is today, 2025-03-18, at 1800 UTC on OFTC's #openstack-tc channel. Please find the agenda on the meeting’s wiki page [6]. I hope you'll be able to join us. I'd encourage the community to bring any topics of interest to this meeting. The synchronous attention of the TC and the lively discussions that follow are a great way to demonstrate our commitment to OpenStack’s "Open Community" values. === Governance Proposals === ==== Open for Review ==== - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 - Add separate freezer-api deliverable | https://review.opendev.org/c/openstack/governance/+/944781 - Fix links to chair responsibilities in TC Guide | https://review.opendev.org/c/openstack/governance/+/944802 - Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 - Resolve to adhere to non-biased language | https://review.opendev.org/c/openstack/governance/+/934907 === Upcoming Events === 2025-04-01 – 2025-04-04: KubeCon+CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ 2025-04-02: OpenStack 2025.1 ("Epoxy") Release 2025-04-08: OpenInfra Board Meeting: https://board.openinfra.org/ 2025-04-07 – 2025-04-12: OpenInfra PTG === How to Contact the TC === You can reach the TC in several ways: - Email: Send an email with the [tc] tag on this mailing list. - IRC: Ping us using the tc-members keyword in the #openstack-tc IRC channel on OFTC. - Weekly Meetings: The Technical Committee meets every Tuesday at 1800 UTC [6]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] 2025.1 "Epoxy" Release Highlights: https://releases.openstack.org/epoxy/highlights.html [3] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [4] OIF Board March '25 Meeting Recap: https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th… [5] TC Meeting IRC Log 2025-03-11: https://meetings.opendev.org/meetings/tc/2025/tc.2025-03-11-18.00.log.html [6] TC Meeting Agenda, 2025-03-18: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ovs] [neutron] Egress traffic is not reaching table 71
by yardalgedal＠gmail.com 17 Mar '25

17 Mar '25

Hi, all! We are experimenting with bluefield-2 and neutron-openvswith-agent on it and have a big problem – all our egress traffic (from stateless point of view) are not leaving the bluefield. Symptoms are the next: the baremetal to which bluefield-2 is connected successfully responds on ping, but does not return any response for TCP traffic and can not send anything from inside. We have some security group with fully allowed egress rules. +--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+ | ID | IP Protocol | Ethertype | IP Range | Port Range | Direction | Remote Security Group | Remote Address Group | +--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+ | 14604165-e0c1-4bce-ae21-d20bf4165fa2 | None | IPv6 | ::/0 | | ingress | None | None | | 16f3f44f-1c9a-48f1-bcd0-7ff8df0cd30a | None | IPv4 | 0.0.0.0/0 | | ingress | None | None | | c7054cde-72ce-4dc8-a4e0-361df199204e | None | IPv6 | ::/0 | | egress | None | None | | d8bc8f82-f181-443d-a0ca-67cbae78b47f | None | IPv4 | 0.0.0.0/0 | | egress | None | None | +--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+ and port to which it is assigned has port_security_enabled: True (if we are disabling port security, there is no problem anymore, it is actual only for enabled port security) we have disabled DVR and VxLAN tunnel here, we have native openvswitch firewall also [agent] tunnel_types = l2_population = true arp_responder = true extensions = qos baremetal_smartnic = True [securitygroup] firewall_driver = openvswitch [ovs] bridge_mappings = br-ex:br-int datapath_type = system ovsdb_connection = tcp:127.0.0.1:6640 #local_ip = tunnel_bridge = of_inactivity_probe = 60 ovsdb_timeout = 60 when we're sending some traffic, all flows in table 71 (BASE_EGRESS_TABLE) has n_packets = 0, so they are not reaching it. in table 60 (TRANSIENT_TABLE), which should send traffic to the table 71, on flow which should do it we can see n_packets=0 as well cookie=0x6cc97f12f173f538, duration=2086.129s, table=60, n_packets=0, n_bytes=0, priority=100,in_port=pf0hpf actions=load:0x2b->NXM_NX_REG5[],load:0x1->NXM_NX_REG6[],resubmit(,71) at the same time, the counter for NORMAL flow is growing, so packets are probably going to here (not sure cookie=0x6cc97f12f173f538, duration=2126.547s, table=60, n_packets=139340, n_bytes=6817502, priority=3 actions=NORMAL on trace we can see that the packet was directly sent to port 1 instead of going via the table ovs-appctl ofproto/trace br-int 'dl_src=a0:88:c2:eb:15:4e,dl_dst=00:1c:73:00:57:ff,ip,nw_dst=DST_IP,nw_src=SRC_IP,in_port=43,nw_ttl=64,nw_proto=6,tp_dst=80' Flow: tcp,in_port=43,vlan_tci=0x0000,dl_src=a0:88:c2:eb:15:4e,dl_dst=00:1c:73:00:57:ff,nw_src=SRC_IP,nw_dst=DST_IP,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=80,tcp_flags=0 bridge("br-int") ---------------- 0. priority 0, cookie 0x699a137a0a73d6a8 NORMAL -> forwarding to learned port bridge("br-int") ---------------- 0. in_port=5,dl_vlan=1, priority 4, cookie 0x699a137a0a73d6a8 set_field:4297->vlan_vid NORMAL -> forwarding to learned port Final flow: unchanged Megaflow: recirc_id=0,eth,ip,in_port=43,dl_src=a0:88:c2:eb:15:4e,dl_dst=00:1c:73:00:57:ff,nw_frag=no Datapath actions: push_vlan(vid=201,pcp=0),1 any ideas why it happens or any proposals for future debugging? Thank you in advance!

1 0

Controller node openstack LXC containers clashing on IP subnets
by Sarah Thompson 17 Mar '25

17 Mar '25

Hi all, I've got much further now, and am now tracking down networking issues. I'm pretty sure everything is now installing, but I'm seeing a systematic issue. My test network that I'm running the openstack instances on is 10.0.1.x -- the VMs all have fixed IP addresses, can talk to each other, etc, nothing weird going on. haproxy is installing and running, but throwing 503 errors. Digging into this, it seems that there are some issues with the network configs of at least some of the LXC containers. The one I'm seeing that's preventing Ansible from completing the infrastructure setup is the repo server container. If I attach to the container, the keepalive comes back correctly. Externally to the container, the HTTP connection is rejected. Looking into the reasons, it looks like there are 3 networks visible from inside the container: ens18: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.1.38 netmask 255.255.255.0 broadcast 10.0.1.255 inet6 fe80::216:3eff:feab:ab45 prefixlen 64 scopeid 0x20<link> ether 00:16:3e:ab:ab:45 txqueuelen 1000 (Ethernet) RX packets 96 bytes 6952 (6.9 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 16 bytes 1236 (1.2 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.3.113 netmask 255.255.255.0 broadcast 10.0.3.255 inet6 fe80::216:3eff:fe45:64d6 prefixlen 64 scopeid 0x20<link> ether 00:16:3e:45:64:d6 txqueuelen 1000 (Ethernet) RX packets 351 bytes 425285 (425.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 263 bytes 19114 (19.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 2939 bytes 208134 (208.1 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2939 bytes 208134 (208.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 The 10.0.1.38 address seems to be the problem. I think this is an internally routed subnet, not the actual physical subnet (note the lack of a gateway address, and 10.0.1.38 is definitely not being allocated via the DCHP server). Looking at some other containers, I'm seeing 10.0.2.x and 10.0.3.x there, so obviously this is being allocated on the fly either by lxc or the container(s). TL;DR: The internal 10.0.1.x is clashing with the physical 10.0.1.x network, which is almost certainly why the keepalive is failing. Does anyone have any idea how to fix the configuration to use some other CIDR block for this? I'd like to avoid the extreme pain of remapping my physical network (this is a way more complicated problem than a few test nodes unfortunotely!) Thank you in advance, Sarah Thompson -- [s]

3 4

PCI alias rtx is not defined
by Felipe Mogollon 17 Mar '25

17 Mar '25

Dear all, I am suffering a problem in my OpenStack servers. I have a 3 server configuration: - controller + compute - 2 x compute nodes The controller node has an Nvidia L4 configured in vGPU mode. One of the compute nodes has another Nvidia L4 in vGPU mode. Both servers are running fine, and I can deploy instances with vGPU capabilities. The problem comes with my 2nd compute node; that node has a Nvidia RTX4000 that can only work in passthrough mode. , I am pretty sure that in past times I managed to deploy this compute node with an Nvidia RTX 4000 in passthrough mode as a compute node of another OpenStack server configuration, but nowadays I am not able to use that GPU in passthrough mode and I don't know why: - I have configured IOMMU in compute node - I have configured nova.conf with pci alias and whitelist in compute node - I have configured nova.conf with pci alias and enabled filters in controller node - I have created a flavor and set up pci_passthrough:rtx:1 to it's configuration As far as I know, those are the steps to configure a GPU passthrough in a compute node in a Openstack multi-node configuration... But when I try to deploy a new instance I am always getting a "PCI alias rtx is not defined (HTTP 400)" error. Any ideas about what could be the problem? Is there any incompatibility with vGPU and passthrough working modes? Thanks in advance. Felipe -- [image: Vicomtech] <https://www.vicomtech.org> Industry Division Juan Felipe Mogollón Rodríguez Senior Researcher Digital Media and Communications fmogollon(a)vicomtech.org +(34) 943 30 92 30 The information contained in this electronic message is intended only for the personal and confidential use of the recipients. If you have received this e-mail by mistake, please, notify us and delete it. Avoid printing this message if it is not strictly necessary.

1 0

Routed provider networks
by Alvin Starr 17 Mar '25

17 Mar '25

I have a couple of small flat networks that I am using for a POC project. I am trying to use the routed provider networks features to create a single public net. I delete the old networks and try to install the following network and it looks like it works in that I see the 2 subnets as part of the single public-net. The trouble is that I cannot create a router with an interface in the public-net. Is there anything special that I need to do to create a router on the public-net? I changed the addresses so the subnets are likely wrong. I am installing with openstack-ansible using stable/2023.2 onto Centos-Stream. # Create the parent network with first physical segment PUBNET_ID=$(openstack network create --share \ --provider-physical-network pub204 \ --provider-network-type flat \ --external \ public-net \ -f value -c id ) FIRST_SEG=$(openstack network segment list --network ${PUBNET_ID} -f value -c ID) openstack network segment set --name segment-pub204 ${FIRST_SEG} # Add second physical segment to the network openstack network segment create \ --physical-network pub203 \ --network-type flat \ --network public-net \ segment-pub203 # Create subnet for pub203 segment openstack subnet create --network public-net \ --network-segment segment-pub203 \ --ip-version 4 \ --subnet-range 1.2.50.192/28 \ --allocation-pool start=1.2.50.196,end=1.2.50.206 \ --gateway 1.2.50.193 \ --dhcp \ public-subnet203 # Create subnet for pub204 segment openstack subnet create --network public-net \ --ip-version 4 \ --network-segment segment-pub204 \ --subnet-range 1.2.48.128/29 \ --allocation-pool start=1.2.48.132,end=1.2.48.134 \ --gateway 1.2.48.129 \ --dhcp \ public-subnet204 -- Alvin Starr || land: (647)478-6285 Netvel Inc. || home: (905)513-7688 alvin(a)netvel.net ||

1 0

[openstack-ansible]Playbooks failing after upgrading lxc containers from ubuntu18 to ubuntu20 due to python version mismatch.
by Danish Khan 17 Mar '25

17 Mar '25

Dear All, We are upgrading one of our openstack cluster from ussuri to wallaby and for this we are first upgrading OS of lxc container from ubuntu to 18 to 20(hosts OS is also upgraded to 20). We are destroying LXC containers(which don't form quorum like nova,neutron,heat,cinder,horizon) of one infra node and then creating it again. The new containers are getting created with Ubuntu 20 as the host OS is 20. Playbook for cinder, nova neutron were completed successfully for new containers of ubuntu 20. But Playbook is failing for heat, placement and memcached due to python version mismatch: fatal: [host5_heat_api_container-25f90e52]: FAILED! => {"attempts": 5, "changed": false, "cmd": ["/openstack/venvs/heat-21.2.5/bin/pip3", "install", "-U", "--constraint", "/openstack/venvs/heat-21.2.5/global-constraints.txt", "--constraint", "/openstack/venvs/heat-21.2.5/constraints.txt", "--pre", "--log", "/var/log/python_venv_build.log", "cryptography", "keystonemiddleware", "openstack-heat", "osprofiler", "pymemcache", "PyMySQL", "python-ceilometerclient", "python-glanceclient", "python-heatclient", "python-keystoneclient", "python-memcached", "python-neutronclient", "python-novaclient", "python-openstackclient", "python-swiftclient", "python-troveclient", "systemd-python"], "msg": "stdout: Ignoring python-saharaclient: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring python-saharaclient: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring python-saharaclient: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring oslo.limit: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring oslo.limit: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring oslo.limit: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring sphinxcontrib-actdiag: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring sphinxcontrib-actdiag: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring sphinxcontrib-actdiag: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring os-api-ref: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring os-api-ref: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring os-api-ref: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring oslo.concurrency: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring oslo.concurrency: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring oslo.concurrency: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring osprofiler: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring osprofiler: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring osprofiler: markers 'python_version == \"3.7\"' don't match your environment\nIgnoring os-resource-classes: markers 'python_version == \"2.7\"' don't match your environment\nIgnoring os-resource-classes: markers 'python_version == \"3.6\"' don't match your environment\nIgnoring os-resource-classes: markers I understand that 2.7 version is depricated but where should make changes to fix it? https://docs.openstack.org/releasenotes/python-heatclient/ussuri.html I tried updating few variable to fix python version like: /etc/ansible/roles/os_heat/defaults/main.yml #heat_venv_python_executable: "{{ openstack_venv_python_executable | default('python3') }}" updated it from python2 to python 3 Tried few more variables but that didn't work. Any idea how we can fix this version mismatch issue ? Regards, Danish

2 1

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

17 Mar '25

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

3 5

[neutron] Bug deputy report for week 11 of 2025
by Miguel Lavalle 16 Mar '25

16 Mar '25

I was the Neutron bug deputy last week. Following is a brief summary of the reported bugs: High bugs -------------- https://bugs.launchpad.net/neutron/+bug/2101839 [fullstack] Random errors during the execution of ``wait_until_true``. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/943942 https://bugs.launchpad.net/neutron/+bug/2101857 ``neutron-tempest-plugin-ovn-ubuntu-jammy`` job unstable. No owner. Jobs neutron-tempest-plugin-*-ubuntu-jammy`` were made no voting: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/944119 Medium bugs ------------------ https://bugs.launchpad.net/neutron/+bug/2101840 ovs jobs randomly failing with guest vms not getting ip from dhcp. Assignee Lajos Katona https://bugs.launchpad.net/neutron/+bug/2101998 [OVN][Placement] Deleting a configured resource provider does not remove the Placement entry. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944053 https://bugs.launchpad.net/neutron/+bug/2102083 ``SingletonDecorator`` class to allow destroying instances. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944099 https://bugs.launchpad.net/neutron/+bug/2101871 Use of revision_number for router update on 2023.2 Bobcat cause error 500. Waiting for reproducer info from submitter Low bugs ------------- https://bugs.launchpad.net/neutron/+bug/2102095 [OVN][Placement] Change the message level when a Placement exception happens. Assignee Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/944101 RFEs ----- https://bugs.launchpad.net/neutron/+bug/2102090 [RFE][OVN][Placement] With Neutron API WSGI module, the initial chassis configuration is not executed. https://bugs.launchpad.net/neutron/+bug/2102165 [RFE] Forbid usage of certain IP addresses in subnet pools https://bugs.launchpad.net/neutron/+bug/2102184 [RFE] Project-Specific QoS Controls for Granular Resource Management Incomplete --------------- https://bugs.launchpad.net/neutron/+bug/2102044 Nova-API problem - cannot list instances anymore

1 0

[ci][all] Migrating doc job back to ubuntu jammy
by Takashi Kajinami 16 Mar '25

16 Mar '25

Hi, I noticed that doc job in taskflow repo was broken recently. Example: https://review.opendev.org/c/openstack/taskflow/+/944495?tab=change-view-ta… Digging into the failure, it seems the failure is caused by api doc build, trying to parse a module importing asyncore, because asyncore is no longer available in Python 3.12. IIUC Doc job was recently migrated from Ubuntu Jammy to Ubuntu Noble, which means that the default python version was bumped to 3.12. We are aware of the deprecation/removal of asyncore and already deprecated the implementation in taskflow. However deprecation was merged during 2024.2 cycle so we can't remove it until 2025.2 cycle to follow SLURP policy. There might be a way to drop the asyncore-related implementations from docs to unblock the doc job, I'm not sure if that is the right approach given the fact the implementation is deprecated but is still valid in older python versions. Thus, I wonder if we can keep running doc job in Jammy for 2025.1, which still supports Ubuntu Jammy, and then migrate the job again during 2025.2 . An alternative approach is to remove the asyncore implementation during this cycle, breaking SLURP policy, but I'm not sure if this can be the preferred option. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 4

Deploiment in 2025
by Albert Shih 16 Mar '25

16 Mar '25

Hi everyone Long time ago I deploy a openstack mostly manually, then I integrated in our deployment tool (puppet). Now I need to re-install everything. I'm searching the «best» method to do that. My deployment would be on bare-metal, I don't need/want a deployment of CEPH (I already have my ceph cluster). Just need the cinder to use the ceph. The main focus is the easy way to upgrade. I don't have a lot of hardware so I can afford to have a «test» cluster for upgrading. I'm thinking of kolla, what do you think ? I see they are now openstack-helm project, which If I understand correctly use a k8s to manage the deployment of openstack. Is that correct ? With those tools is they are any limitation about the result ? Or can I got the most the main features of openstack ? What would you recommend ? Regards. -- Albert SHIH 🦫 🐸 Observatoire de Paris France Heure locale/Local time: mer. 05 mars 2025 17:13:54 CET

8 16

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

14 Mar '25

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

2 9

[release] Release countdown for week R-2
by Thierry Carrez 14 Mar '25

14 Mar '25

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2025.1 Epoxy deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2025.1 branch creation for all deliverables that have not branched yet, using the latest available 2025.1 Epoxy release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2025.1 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2025.1 branch before releasing out of the stable/2025.1 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2025.2 Flamingo development, though the focus should still be on finishing up 2025.1 Epoxy until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2025.1 Epoxy release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2025.1 Epoxy version of your project. Upcoming Deadlines & Dates -------------------------- 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

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

14 Mar '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is currently nothing listed in the agenda and we should be focusing on getting last-minute changes for RC1 merged. 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