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

[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 19 Mar '25

19 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 18 Mar '25

18 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