April 2025 - openstack-discuss - lists.openstack.org

[Neurton][OVN] Can Geneve tunnel be disabled ?
by keerthi vassan 21 Apr '25

21 Apr '25

Hello Team We are using ML2+OVN based on Provider Network with Vlan ( no tenant network ) , for hypervisor to hypervisor traffic we are using physical L2 network. We are not using geneve tunnel anymore. How to disable these tunnel in OVN deployment? Is this expected? Regards, Keerthivasan

2 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-23)
by Goutham Pacha Ravi 21 Apr '25

21 Apr '25

Hello Stackers, I hope you've been enjoying the PTG Summaries posted to this mailing list. As we embark on follow-ups, we have the next 23 weeks to build the 2025.2 "Flamingo" release of OpenStack [1]. Last week, the OpenStack TC didn't merge any significant governance changes. The update this week is short, as we are building up the TC's tracker for activities during this release cycle [2]. === Weekly Meeting === The last weekly meeting of the OpenStack TC was held over IRC on OFTC's #openstack-tc channel on 2025-04-15 [3]. We discussed several short-term follow-ups from the Project Teams Gathering from the prior week, including updates to community goals [4][5]. We noted that the 2025 OpenStack User Survey is live [6]. We may be revising some questions and adding new ones to seek feedback and reflect on the community's work over recent releases. We'll also be reflecting on the 2024 User Survey results when they are available. We briefly discussed the structure and organization of the Project Teams Gathering. The feedback collected [7] so far noted that some found the virtual PTG format exhausting due to constant room-switching without breaks. Some suggestions were made, including incorporating breaks between sessions, seeking agendas early, adding informal sessions like “happy hours,” and encouraging unconference-style meetings. Members generally supported using only 50 minutes of each hour to allow time for decompression. A discussion on i18n was deferred to the next meeting to allow more time to review the context and decide on actionable steps. The next weekly meeting of the OpenStack TC is today, 2025-04-22. It will be held over IRC in OFTC's #openstack-tc channel at 1700 UTC. Please note the change in timing — it is an hour earlier than our past meetings. Please find the agenda on the meeting's wiki page [8]. I hope you'll be able to join us there. Any community member can propose topics to this meeting by editing the wiki page. Please be sure to add your IRC nick so we can call upon you during the meeting. === Governance Proposals === ==== Merged ==== - Add aetos to telemetry project | https://review.opendev.org/c/openstack/governance/+/946744 - Fix Dan Smith's email | https://review.opendev.org/c/openstack/governance/+/946960 ==== Open for Review ==== - Retire openstack-helm-infra repo | https://review.opendev.org/c/openstack/governance/+/947611 - Deprecate openstack-ansible-tests repo | https://review.opendev.org/c/openstack/governance/+/947622 - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 === Upcoming Events === - 2025-04-29: StackConf https://stackconf.eu/ - 2025-04-29: SCS Hackathon / OpenStack Birthday: https://events.sovereigncloudstack.org/hackathon5-2025/ - 2025-05-13: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-05-22: OpenInfra UG Meetup, Sweden: https://www.meetup.com/openinfra-user-group-sweden/events/306139678/ === 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. - Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1700 UTC [8]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] OpenStack TC's 2025.2 Tracker: https://etherpad.opendev.org/p/tc-2025.2-tracker [3] TC Meeting IRC Log 2025-04-15: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-15-17.00.html [4] OpenStack TC's 2025.2 PTG Summary: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenStack TC's 2025.2 PTG recordings: https://www.youtube.com/playlist?list=PLhwOhbQKWT7XYzqrx21j1uizxNxnbDf5Q [6] OpenStack User Survey: https://www.openstack.org/user-survey [7] 2025.2 PTG Feedback: https://etherpad.opendev.org/p/apr2025_ptg_feedback [8] TC Meeting Agenda, 2025-04-22: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[oslo] python-consul2 is unmaintained
by Takashi Kajinami 21 Apr '25

21 Apr '25

Hello, I recently noticed that python-consul2 library[1], which is used by the consul coordination driver in tooz, hasn't been updated for 3+ years. Looking at issues in the project, there is an indication that the library is not compatible with ACL API in consul >= 1.11[2]. There is another fork created[3] and this includes fixes to support new API endpoints. Although the driver in tooz does not directly use the feature, I think it's better to discuss our plan to mitigate risks caused by the unmaintained library. As far as I can think of, there are three options now 1. Deprecate consul driver and remove it 2. Keep using python-consul2 now. At least basic functionality is proven to work by our functional tests (Note that the tests do not cover all configuration patterns) 3. Replace python-consul2 by py-consul Before we start the overall discussions I'd like to ask a few questions to the wider audience, as our inputs. - Is anyone using the consul coordination driver now ? - Does anyone have experience with python-consul2 and/or py-consul ? Note that this discussion affects the http messaging driver[4] currently proposed, because it also requires client library to communicate with Consul. Actually I noticed the situation when I noticed that the requirement check job is failing because the library is not part of global requirements list... Thank you, Takashi Kajinami [1] https://github.com/poppyred/python-consul2 [2] https://github.com/poppyred/python-consul2/issues/42 [3] https://github.com/criteo-forks/py-consul [4] https://review.opendev.org/c/openstack/oslo.messaging/+/912499 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 3

[ops][nova] How to modify the nova policy file for server reboot
by federica fanzago 19 Apr '25

19 Apr '25

Dear all, I'm running OpenStack Caracal on AlmaLinux 9.5 and I'm trying to modify the nova policy file to allow the reboot of a server only to the admin and to the owner of the VM (but not to all members of the same project). I have updated the policy (as I already dis for other actions like stop) as follows: "os_compute_api:servers:reboot": "rule:context_is_admin or user_id:%(user_id)s" But the owner is unable to perform the reboot. When I try to reboot one of my own instances I get the following error: >openstack server reboot 97a32e4c-2e56-4d75-b0c4-5ac4da278421 --debug Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/cliff/app.py", line 410, in run_subcommand result = cmd.run(parsed_args) File "/usr/lib/python3.9/site-packages/osc_lib/command/command.py", line 38, in run return super(Command, self).run(parsed_args) File "/usr/lib/python3.9/site-packages/cliff/command.py", line 181, in run return_code = self.take_action(parsed_args) or 0 File "/usr/lib/python3.9/site-packages/openstackclient/compute/v2/server.py", line 3279, in take_action compute_client.reboot_server(server_id, parsed_args.reboot_type) File "/usr/lib/python3.9/site-packages/openstack/compute/v2/_proxy.py", line 879, in reboot_server server.reboot(self, reboot_type) File "/usr/lib/python3.9/site-packages/openstack/compute/v2/server.py", line 353, in reboot self._action(session, body) File "/usr/lib/python3.9/site-packages/openstack/compute/v2/server.py", line 318, in _action exceptions.raise_from_response(response) File "/usr/lib/python3.9/site-packages/openstack/exceptions.py", line 247, in raise_from_response raise cls( openstack.exceptions.ForbiddenException: ForbiddenException: 403: Client Error for url: https://cloud-areapd-test.pd.infn.it:8774/v2.1/servers/97a32e4c-2e56-4d75-b…, Policy doesn't allow os_compute_api:servers:reboot to be performed. clean_up RebootServer: ForbiddenException: 403: Client Error for url: https://cloud-areapd-test.pd.infn.it:8774/v2.1/servers/97a32e4c-2e56-4d75-b…, Policy doesn't allow os_compute_api:servers:reboot to be performed. END return value: 1 Do you know what could be causing this? I’m able to start and stop this same VM without any issues, so I expected reboot to work with the same policy. Thanks, cheers Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

2 1

[Neurton][OVN] Help With Validation Of ML2/OVN
by keerthi vassan 18 Apr '25

18 Apr '25

Hello Stackers Deployed OVN with Provider network on minimal setup with 3 controllers & 3 compute nodes. We are not using tenant network (only one external network ) for each vlan 2 & Vlan 8 Below is the ping behaviour for vms spread across two hypervisor (different networks ) VM1: 172.168.2.20 (vlan 2 )- SRC-Hyp VM2: 172.168.3.21 (vlan 8 )- Dest-Hyp Source Hypervisor: root@SRC:~# ovs-tcpdump -i patch-br-int-to-provnet-c24e134d-1a3c-4733-941e-0de548325497 icmp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ovsmi688947, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:41:25.900113 IP 172.168.2.20 > 172.168.3.21: ICMP echo reply, id 18, seq 1, length 64 Dest Hyp: root@DEST:~# ovs-tcpdump -i patch-br-int-to-provnet-d33f01e8-6fe9-4597-998c-f6e339ba6386 icmp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ovsmi853421, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:41:25.899394 IP 172.168.3.21 > 172.168.2.20: ICMP echo request, id 18, seq 1, length 64 This is first time with OVS, trying to understand below behaviour why we are seeing echo reply on patch-br-int-to-provnet-c24e134d-1a3c-4733-941e-0de548325497 ? Ideally above will help in transfer traffic from br-int to br-ex via path ( as we have physical interface tagged in br-ex ). Is this expected behaviour ? Can some one please help on this ?

1 0

[neutron][OVN] Help With Validation Of ML2/OVN
by keerthivassan86＠gmail.com 18 Apr '25

18 Apr '25

Hello Stackers Deployed OVN with Provider network on minimal setup with 3 controllers & 3 compute nodes. We are not using tenant network (only one external network ) for each vlan 2 & Vlan 8 Below is the ping behaviour for vms spread across two hypervisor (different networks ) VM1: 172.168.2.20 (vlan 2 )- SRC-Hyp VM2: 172.168.3.21 (vlan 8 )- Dest-Hyp Source Hypervisor: root@SRC:~# ovs-tcpdump -i patch-br-int-to-provnet-c24e134d-1a3c-4733-941e-0de548325497 icmp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ovsmi688947, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:41:25.900113 IP 172.168.2.20 > 172.168.3.21: ICMP echo reply, id 18, seq 1, length 64 Dest Hyp: root@DEST:~# ovs-tcpdump -i patch-br-int-to-provnet-d33f01e8-6fe9-4597-998c-f6e339ba6386 icmp tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on ovsmi853421, link-type EN10MB (Ethernet), snapshot length 262144 bytes 15:41:25.899394 IP 172.168.3.21 > 172.168.2.20: ICMP echo request, id 18, seq 1, length 64 This is first time with OVS, trying to understand below behaviour why we are seeing echo reply on patch-br-int-to-provnet-c24e134d-1a3c-4733-941e-0de548325497 ? Ideally above will help in transfer traffic from br-int to br-ex via path ( as we have physical interface tagged in br-ex ). Is this expected behaviour ? Can some one please help on this ?

1 0

#eventlet-removal [ptg] 2025.2 Flamingo PTG summary
by Herve Beraud 18 Apr '25

18 Apr '25

Following the intensive discussions at the April 2025 Project Teams Gathering about the Eventlet removal initiative, this thread summarizes the current status, challenges, and strategies of all the OpenStack teams with a transversal perspective. A full and detailed report is available at: https://removal.eventlet.org/guide/openstack/flamingo-ptg/ ## Python 3.13 Compatibility The countdown has begun! As documented in the April 2025 PTG discussions, the OpenStack community is accelerating efforts to remove Eventlet dependencies across all projects. This initiative has become critical due to Eventlet's compatibility problems with Python 3.13 and the upcoming "GILectomy" (PEP 703). With Ubuntu 2025.4 planning to ship Python 3.13 by default, we're facing a hard deadline for this work https://discourse.ubuntu.com/t/plucky-puffin-release-schedule/36461 ## Migration Status ### Significant Progress - Octavia: Fully migrated since 2017! Their approach is now documented as a community case study. - Mistral: Almost there with a comprehensive migration approach. - Neutron: Significant progress with numerous patches already merged. - Glance: Can be deployed without Eventlet, though some optional features still need work. ### Work in Progress - Nova: Planning a service-by-service migration with dual-mode support during transition. - Swift: Evaluating alternatives with impressive performance results (FastWsgi showing 10x better performance!). - Manila, Cinder, Heat: All have active plans for the Flamingo cycle. - Designate, Blazar, Watcher: Starting their migration journeys. - Ironic: Facing complex challenges, particularly with the Ironic Python Agent component. ## Technical Spotlight: Oslo.service's Threading Backend A key development is the new threading backend for oslo.service that eliminates the Eventlet dependency: - Review in progress: https://review.opendev.org/c/openstack/oslo.service/+/945720 - No longer provides WSGI support - Each service will need to deprecate implementations dependent on Eventlet's WSGI server ## Migration Strategies: One Size Doesn't Fit All Projects are adopting diverse approaches: - Dual-mode support: Nova and Glance are supporting both Eventlet and native threads during transition - Canary approach: Swift is considering starting with proxy nodes - Component-by-component: Cinder is starting with the Volume Manager - Complete replacement: Heat is planning a full discontinuation of WSGI server implementations ## Nova's Detailed Roadmap Nova has a comprehensive two-cycle plan: Flamingo Cycle (2025.2): - API modernization - Architecture updates with environment variable controls - Performance improvements - Test transition to native threading Guppy Cycle (2026.1): - Core event loop conversion - Adoption of oslo.service's new threading backend ## Issues to Watch: RabbitMQ Heartbeat Problems The problem with RabbitMQ heartbeats story: - Timeouts and API failures in "green" environments - Partial solution using pthreads exists but has logging issues - Track the fix: https://review.opendev.org/c/openstack/oslo.log/+/937729 ## How to Get Involved - Join the #openstack-eventlet-removal channel on OFTC - Review the official guide: https://removal.eventlet.org/ - Look for patches under the "eventlet-removal" topic: https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22 ## Recommended Reading For teams starting their migration: 1. Official goal documentation: https://governance.openstack.org/tc/goals/selected/remove-eventlet.html 2. Migration preparation guide: https://removal.eventlet.org/guide/preparing-for-migration/ 3. Octavia case study: https://removal.eventlet.org/guide/case-studies/octavia/ ## Stay Updated - The complete version of this report is available online at: https://removal.eventlet.org/guide/openstack/flamingo-ptg/ - Track the progress of the migration across all projects at: https://removal.eventlet.org/guide/openstack/#migration-status Thanks for reading! PS: This PTG summary is based on the etherpads following the April 2025 PTG discussions (https://ptg.opendev.org/etherpads.html) For more details, refer to the full report ( https://removal.eventlet.org/guide/openstack/flamingo-ptg/)

3 4

[tacker][ptg]2025.2 Flamingo PTG summary
by Yasufumi Ogawa 18 Apr '25

18 Apr '25

Hi everyone, Thank you for joining to the vPTG sessions last week. We had great discussion for several topics about Tacker's next development items. Here is a summary of the discussion. ## Revise FTs We've revised functional tests for the recent cycles since maintainance costs or running time are getting large. It's a recap of the previous vPTG discussion and we agree to focus on reducing the number of tests by dropping useless ones and setup configurations. ## Enhancing Tacker Testing Coverage in the OpenStack Helm Check Pipeline A proposal for enhancing Tacker testing within the OpenStack Helm (OSH) pipeline by adding more test cases. It will use the OpenStack CLI for Tacker testing, ensuring that no modifications to the OSH test code will be needed even if Tacker's functional tests change. It's also a recap from the previous cycle and we agreed to continue the development. ## Balancing Test Execution Efficiency and Resource Consumption in Tacker Testing It's a sub task of revising functional tests. Since some of usecases in tacker are little bit complicated and several nodes are used for test such a cases. As the result, the resource consumption is higher than we expected. This proposal aims to analyze this issue and propose possible optimizations to balance resource usage and test execution efficiency. ## Tacker Strategy and Guidelines to Support Newer TST Releases and V2 API We're planning to introduce ETSI NFV standard tests called as TST for ensuring Tacker's capabilities are exactly compliant with the standards, but there is a painpoint about supporting versions. The purpose of this proposal is to outline the strategy and guidelines for updating Tacker to support newer TST releases and its v2 API so that we can define how Tacker can collaborate with the TST team to implement support for newer releases. ## Potential new usecase from vRAN feedback Discussion for a new vRAN usecase other than basic ones already implemented in Tacker as a part of cross community collaboration items between O-RAN SC and OpenStack. Tacker is expected to be SMO which is a frontend of O-Cloud infrastructure defined in the O-RAN SC reference architecture model. In a highliy distributed deployment usecase called as D-RAN (Distributed RAN), there is a concern about resource consumption because of limited num of servers is available on each edge site. K8s may not support a case of far controll node on retional site and worker nodes on edge sites. We discussed two key points and will continue the discussion: (1) Tacker manages container via Docer directly by Infra-driver? and (2) How can Tacker ensure to manage container with delay? ## PaaS Manager It's a emerging requirement for Tacker. In ETSI NFV standards, PaaS and its manager are expected as key components for containers. ETSI NFV has specified PSM (PaaS Service Management) to manage LCM of PaaS in clause 10 of ETSI GS NFV-IFA 049. However, there might be several missing point in term of implementation, such as how manages dependency between VNF and PaaS, e.g. order of start/stop, capacity of PaaS, recovery when PaaS is failure. It's also required to provide a parser for PaaS Service Descriptor (PSD). In the vPTG discussion, we agree to continue the discussion to make it clear the actual requirements for managing PSM or describing PSD, and contribute ETSI NFV specifications. ## Add option to enable/disable Cinder volume recreation in v1 Heal request A proposal for enhancing Tacker v1 APIs by enabling to cancel cincer volume is recreated while heal operation. This feature was already implemented in v2, but it's also required to implement in v1 for keeping compatibility. ## Add default_secret_key Option to [vim_keys] for Multi-Master Tacker Deployment Currently, all Tacker nodes need to share or sync the VIM keys across all nodes. Since VIM keys are randomly generated and stored only on the conductor where the VIM registration process occurs, it doesn't work if instantiate or terminate requests are performed from a different conductor, the VIM key is also required on that host. This proposal is for allowing the Tacker administrator to use a pre-generated common key eliminates the need for key sharing or syncing, making the setup simpler. We agreed to the implementation strategy and expect to merge the feature in Flamimngo. Yasufumi

1 0

openstack ansible nova
by engineer2024 18 Apr '25

18 Apr '25

When running the n os-nova playbook, I want to disable need_online_data_migrations in the nova role. I tried this pasing to the playbook '-e need_online_data_migrations=False', but it did not work. tried deleting the fact file for the nova containers at /etc/openstack_deploy/ansible_facts. folder. still it did not work. It is resetting each time to 'True' Finally I hardcoded in the file /etc/ansible/roles/os_nova/tasks/nova_install.yml ---- - name: Install the python venv import_role: name: "python_venv_build" vars: venv_python_executable: "{{ nova_venv_python_executable }}" venv_build_constraints: "{{ nova_git_constraints }}" venv_build_distro_package_list: "{{ nova_devel_distro_packages }}" venv_install_destination_path: "{{ nova_bin | dirname }}" venv_pip_install_args: "{{ nova_pip_install_args }}" venv_packages_to_symlink: >- {{ (nova_services['nova-compute']['group'] in group_names and nova_virt_type != 'ironic') | ternary(nova_compute_kvm_packages_to_symlink, []) }} venv_pip_packages: "{{ nova_venv_packages }}" venv_facts_when_changed: - section: "nova" option: "need_service_restart" value: "True" - section: "nova" option: "need_online_data_migrations" value: "False" - section: "nova" option: "venv_tag" value: "{{ nova_venv_tag }}" when: nova_install_method == 'source' - name: Record local facts for distro path when: nova_install_method == 'distro' block: - name: Record the osa version deployed ini_file: dest: "/etc/ansible/facts.d/openstack_ansible.fact" section: nova option: venv_tag value: "{{ nova_venv_tag }}" mode: "0644" - name: Initialise the upgrade facts ini_file: dest: "/etc/ansible/facts.d/openstack_ansible.fact" section: nova option: "{{ item.name }}" value: "{{ item.state }}" mode: "0644" with_items: - name: "need_service_restart" state: "True" - name: "need_online_data_migrations" state: "False" when: - (install_packages is changed) or (ansible_local is not defined) or ('openstack_ansible' not in ansible_local) or ('nova' not in ansible_local['openstack_ansible']) or ('need_online_data_migrations' not in ansible_local['openstack_ansible']['nova']) or ('need_service_restart' not in ansible_local['openstack_ansible']['nova']) ---------- how to override it without hardcoding it ?

3 5

[neutron] Drivers meeting canceled Friday, April 18th
by Brian Haley 17 Apr '25

17 Apr '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as it does not look like we will have quorum, please add things to the wiki to discuss next week. Have a nice weekend! -Brian

1 0