- openstack-discuss - lists.openstack.org

[nova] Did something change about interface detach/attach from Yoga to Caracal?
by Nell Jerram 28 Apr '25

28 Apr '25

I'm not sure why it was originally written, but I have an ancient system test that: - creates a VM attached to one network - finds the VM's port and calls interface_detach for it - checks that the VM is now unpingable - calls interface_attach with the relevant network_id - hard reboots the VM - checks that the VM is now pingable again. With Yoga, the test passes, and at the end of the test the VM has one NIC, eth0, with an IP address. With Caracal, the test also passes, but at the end of the test the VM has two NICs: - eth0 with no IP address - eth1 with an IP address. Diffing the Nova code, it looks like interface_detach and interface_attach might actually have been no-ops in Yoga - although possibly only for a "vdpa" vnic-type, and I'm unsure whether that vnic-type would be relevant to my test setup. Any ideas about this? Many thanks - Nell

2 3

[openstack-ansible] lxc-container upgrade from ubuntu 18 to ubuntu 20 for USSURI
by Danish Khan 27 Apr '25

27 Apr '25

Dear Team, I am trying to upgrade lxc-container from ubuntu 18 to ubuntu 20 and I doing it by destroying and recreating lxc-containers. I have successfully upgraded cinder, glance, heat, horizon,memcached, neutron, nova and placement containers. But now I am unable to create galera, utility containers. I am getting below error for both: failed: [host5_galera_container-ac20] (item={'url': ' http://repo.vexxhost.net/mariadb/key.gpg'}) => {"ansible_loop_var": "key", "attempts": 5, "changed": false, "key": {"url": " http://repo.vexxhost.net/mariadb/key.gpg"}, "msg": "Failed to download key at http://repo.vexxhost.net/mariadb/key.gpg: HTTP Error 404: Not Found"} And it seems the URL http://repo.vexxhost.net/mariadb/key.gpg doesn't exist now. Do we have any workaround for this? Regards, Danish

2 5

[neutron] Today's CI meeting cancelled
by Yatin Karel 27 Apr '25

27 Apr '25

Hello Neotron Team !! I will not be around today so cancelling CI meeting. Sorry for the last minute change. -- Thanks and Regards Yatin Karel

1 0

[neutron][ptg] 2025.2 Flamingo PTG summary
by Brian Haley 24 Apr '25

24 Apr '25

Hi all, Thanks for all that attended the meetings, we had a good turnout for Neutron, the Nova/Cinder cross-project and the eventlet removal discussions that were important to the team. For complete notes see the etherpad [0] but a summary is below. And please comment if you feel I missed anything. Thank you, -Brian ### Epoxy retrospective ### Like any other PTG, it started with a retrospective of the past cycle, with the highlights and improvement points. Good: - Eventlet removal is going well. Even the transition period (for the Neutron API with ML2/OVN) finished with good results. - Permanent "open doors" status to welcome newcomers. Our meetings (team meeting, drivers meeting) are a good forum for them. - Removed experimental code (Linuxbridge, IPv6 PD). - Migration from ML2/Linux Bridge to ML2/OVN discussions have started in Operators community (https://etherpad.opendev.org/p/neutron-lb-ovn-migration) Bad: - The loss of 2 important core developers. - No new specs merged in Epoxy cycle. ### Gate Stability ### Team has been very good at addressing gate issues quickly, and meets on a regular basis. We have noticed a few issues related to eventlet changes and are reverting them until we can address them. ### Spring cleanup / Code base modernization ### At the beginning of every cycle, we always try and cleanup the code base, for example, removing deprecated and dead code, doc updates, job consolidation. We have made progress on those already. - During Epoxy, several changes were made to match the expected output of pyupgrade/autopep8 for py39+. We will make a similar change in Flamingo for py310+ as that is now the lower bounds (haleyb). - It was also discussed to include "ruff" to our checklist (mlavalle). - Now that the OVN agent is in place and the default in gate, it was discussed about removing the OVN metadata agent as it is unnecessary to have both. - CI job reduction: move the ML2/OVS iptables-hybrid jobs to periodic (and experimental) and determine if iptables-hybrid driver can be moved to experimental config space. - TODOs: spend some time addressing the current TODO notes in the code, fixing what is proposed, already started. - Remove the unneeded OVN maintenance tasks, according to the comments in the methods. - Will make sure beginning/end of cycle docs are up-to-date on things like CI jobs, etc. (haleyb) ### Eventlet removal ### The "oslo.service" library will implement two backends (eventlet or threading), that will allow us to test both implementations during the removal. It could be useful to have temporary CI jobs, using both implementations. The testing CI (unit test, functional and fullstack) should start the migration during this cycle, but only once the Neutron service code is migrated. Please see [1] and [2] for more information and meetings notes from the eventlet-specific agenda. ### Migration to SDK (neutronclient removal) ### Etherpad link: https://etherpad.opendev.org/p/python-neutronclient_deprecation During the last cycle a number of Horizon patches merged (thanks Lajos!). Heat patches are still under review (and not attended). Nova patch is WIP: https://review.opendev.org/c/openstack/nova/+/928022 Neutron team will add deprecation warnings in the neutronclient code as there are still a number of places in both in and out-of tree code that is using the neutronclient. The fullstack tests will migrate to SDK during this cycle. ### Migrate the OVN L3 scheduler to use HA_Chassis_Group ### Link: https://bugs.launchpad.net/neutron/+bug/2092271 As recommended by the OVN core team, the usage of ``Gateway_Chassis`` to bind a ``Logical_Router_Port`` is deprecated. Instead of this, ``HA_Chassis_Group`` should be used. This bug tracks this effort that should be done during the next cycle. ### An OVN L3 router tool ### Link: https://bugs.launchpad.net/neutron/+bug/2103521 The goal of this tool is: - To be able to list the current GW LRP assignment, according to the ``HA_Chassis_Group``. It will show the GW chassis assignation level (according to the priority) and the number of routers per chassis. - To be able to reschedule the current assignments. In case of unbalance (chassis deletion, router deletion), this tool will allow to reschedule the GW chassis across the existing LRPs. This is something that is useful to cloud operators that currently must manually try and re-balance LRPs. Status: Approved ### Alembic idempotency ### Link: https://bugs.launchpad.net/neutron/+bug/2100770 This request comes from an issue seen in RHOSO18 with a DB migration back port. It is not possible to change the cycle milestones (last DB migrations of each cycle), thus the D/S migrations (in U/S are forbidden) are done before these milestones. The problem happens when a user, that is already in the last DB migration step, needs to re-execute the DB migration tool to receive the new back ported migration. That will fail because it is not possible to execute a DB migration script twice. This proposal includes: - Implementing a new test class that checks any new DB migration in order to ensure it works, as we found issues recently. - Enforce any new DB migration (code developers and reviewers) to be idempotent. - This would be supported on all existing migrations as well, not just from today forward. - Provide a usage guide on the alembic methods if necessary Status: Approved ### Stop DB drop migrations, with field drop exceptions ### Link: https://bugs.launchpad.net/neutron/+bug/2104160 In a DB migration, developers should add a TODO note to drop anything not used in the next SLURP release. That will prevent the case described in the bug, where a user executed the "expand" phase migration code with the old Neutron API code (as specified by the upgrade guide), resulting in an error due to a missing DB column, which was dropped by a DB migration script. The initial output of this bug is a new policy in the development guide. ### Create a restricted default policy for undefined API calls ### Link: https://bugs.launchpad.net/neutron/+bug/2098737 The goal of this RFE is to define a default restrictive rule for every non-defined policy in the Neutron API, as "oslo.policy" allows us to create a "default" policy that will be used in case the API call is not defined. The "default" Neutron policy is RULE_ADMIN_OR_OWNER, we propose to change this to RULE_ADMIN_ONLY. Any new API not defined in the policies would be executable only by the admin user. This change cannot be done now, due to the high number of missing API rules not defined that are using the default rule, see https://review.opendev.org/c/openstack/neutron/+/945687 - but this rule migration should be a background tasks for any team member that will improve the quality of the RBAC system in Neutron. Status: Approved ### Nova/Cinder cross-project ### We discussed two topics at the Nova/Cinder cross-project meeting. Project-Specific QoS Controls for Granular Resource Management. Driven by Bloomberg. Link: https://bugs.launchpad.net/neutron/+bug/2102184 Despite many questions still existing about the implementation, the Neutron team agreed to accept a spec describing it. The Neutron team agreed to have a per-project QoS policy that will affect to a non-defined set of resources (ports, networks, routers, FIPs). Bloomberg agreed to work on this later this cycle. For live-migration with OVN, Nova currently has a vif-plugged event timer to work-around any missed (or not sent) notifications. Link: https://bugs.launchpad.net/nova/+bug/2073254 The code for the multiple binding is in core OVN (23.09) and Neutron. Nova team will propose a patch to remove the condition in Nova and wait for the vif-plugged event when using the ML2/OVN backend as the condition should not happen any more. Patch link: https://review.opendev.org/c/openstack/nova/+/946950 ### Service role permissions ### The Octavia allowed address pair driver requires new service role permissions. Link: https://bugs.launchpad.net/neutron/+bug/2105502 Three patches proposed: - Add new default policy for device_id field on ports: https://review.opendev.org/c/openstack/neutron/+/861169 - Allow service role to create/update port device_id: https://review.opendev.org/c/openstack/neutron/+/947003 - Allow service role more RBAC access for Octavia: https://review.opendev.org/c/openstack/neutron/+/945329 ### L3/DHCP thread pool resizing ### Link: https://review.opendev.org/c/openstack/neutron/+/938411 This proposal is related to the eventlet removal topic. There is no direct replacement for ``eventlet.GreenPool``. The resizable mechanism does not provide a resource improvement in speed or memory and there is no kernel library that provides this functionality. The default and static maximum number of threads will be 32 (the current maximum). ### VXLAN physical networks ### Link: https://bugs.launchpad.net/neutron/+bug/2105855 The goal is to be able to schedule a VXLAN port depending on the physical mappings as the VTEP interfaces in each compute node could be connected to different physical networks. This would help improve the "networking-generic-switch" back end as it could use this new information. An alternative to this could be to implement a new type driver: l2vni, used for tunneled drivers (VXLAN) with a physical back end. A spec is required to study this proposal further. ### vlan_transparent ### Link: https://bugs.launchpad.net/neutron/+bug/2092174 Proposal to deprecate and remove the vlan_transparent config option. By default, the loaded drivers will determine if the functionality is supported or not. Status: Approved ### OVN "Add-Only" Sync Mode ### Link: https://bugs.launchpad.net/neutron/+bug/2099818 Proposal to add a new OVN sync mode option that will only add things to the OVN database and never remove from either OVN or Neutron. There were a few worries, as turning-off delete might just make things more out of sync, and not address any issues being seen in ovn-controller or ovn-northd. It was also pointed out that we did spend some time over past cycles tagging neutron-owned objects in OVN explicitly, and there might just be some additional edge cases we need to fix. This might address the issue where other objects change unexpectedly. Need to discuss further at future Drivers meeting as submitter did not attend. ### RFE discussions ### On-demand topic to discuss any in-progress or proposed RFE changes, please see etherpad for more information. [0] https://etherpad.opendev.org/p/apr2025-ptg-neutron [1] https://etherpad.opendev.org/p/neutron-eventlet-deprecation [2] https://etherpad.opendev.org/p/apr2025-ptg-eventlet

1 0

[watcher] Cancelling May 1st weekly meeting
by Douglas Viroel 24 Apr '25

24 Apr '25

Hi all, Since most participants will be out on May 1st, due to local holidays, we agree[1] to cancel next week's meeting. We will meet again on May 8th. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-04-24-12.00… BR, -- Douglas Viroel - dviroel

1 0

[openstack-ansible]: Operating system upgrade procedure Ubuntu 20.04 to 22.04
by Rambo Rambo 24 Apr '25

24 Apr '25

Hi Team We are currently on below release of Openstack: Openstack Release: Zed OS Release: Ubuntu 20.04.2 LTS I am looking for the tested procedure/suggestions/experience for doing the operating system upgrade from 20.04 to 22.04 on this openstack release. Regards Rambo

2 5

Deploying a DC - DR solution
by KK CHN 23 Apr '25

23 Apr '25

Folks , I am exploring the possibility of OpenStack to set up an On Prem DC and Near line DR using OpenStack . I have exposure to OpenStack from the Ussuri version onwards but am not a master of OpenStack. Objective is to achieve near zero data loss of the growing VMs at the DC replicated in real time to the Near Line DR. At times of a DC crash or for scheduled maintenance activity to ensure business continuity (RPO near zero and RTO 30 minutes - 1 Hour) to operate from the DR site. Heard about similar solutions exists for VMWare or any proprietary OEM like vSphere replication,vSAN and SRM to orchestrate failover and fallback with RPO near zero and RTO 30 minutes to 1 Hr. But not an option due to budget constraints at the moment. What ways do folks at OpenStack achieve this kind of requirement? The underlying tools and techniques I have chosen to deploy and the best possible design of DC and DR to achieve the objectives. Any hints and guidance to start, much appreciated. Thank you, Krishane

3 2

[horizon] Heat template generator not working on Chrome
by Jorge Merlino 23 Apr '25

23 Apr '25

Hi folks, There is an issue with Horizon's heat template generator when using chrome or a chrome based browser. It can be easily reproduced by going to the Project / Orchestration / Template Generator menu. There are icons on the top of the screen that can be dragged into the canvas below. That works fine in Firefox but does not work in Chrome. When the icon is dragged over the canvas in Chrome it shows a little green plus sign next to it which does not appear in Firefox and dropping the icon does nothing. I could not see any errors show in the browser console or the debugger. Tested on horizon 22.1.1 (openstack Yoga) Thanks for your help Jorge

2 2

cinder.volume.manager: RDB permission error (error creating image)
by usridzero＠gmail.com 23 Apr '25

23 Apr '25

Running Yoga on an isolated system. Everything seemed to have installed properly with openstack-ansible, but I'm getting the error: cinder.volume.manager: RDB permission error (error creating image). I can't get any logs from the isolated systems. Any help will be greatly appreciated.

1 0

[largescale-sig] Next meeting: April 23, 15utc
by Thierry Carrez 23 Apr '25

23 Apr '25

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC at 15UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250423T15 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[horizon] 2025.2 Flamingo PTG Summary
by Tatiana Ovchinnikova 23 Apr '25

23 Apr '25

*Hello everyone,Last Horizon PTG had very interesting and productive topics. We had internal sessions on Tuesday and a cross project session with Watcher and Telemetry teams on Wednesday. All the notes are available here: https://etherpad.opendev.org/p/horizon-flamingo-ptg <https://etherpad.opendev.org/p/horizon-flamingo-ptg>Here is a summary of the discussions that we had: - Epoxy Retrospective- New core, new contributors, new SASS compiler library, new feature implemented, more work done on OpenStackSDK migration- Integration and UI tests action items- Switch UI tests to voting- Remove old integration tests from Horizon repository- AngularJS removal plan- Create a blueprint to track work - Analyze the differences between python and JS views - Adjust the tests for new views - Outreachy: post-internship experience- Opportunities, initiatives, ideas- Oslo-config discussion- Review of work remaining - Cross-project session with Watcher and Telemetry- Ideas and PoC of new panels for an admin and a tenant with new metrics- Frameworks discussion- Use-cases- Next steps proposalThanks everyone for joining!* With kind regards, Tatiana

3 2

Celebrate OpenStack Turning 15!
by helena＠openinfra.dev 23 Apr '25

23 Apr '25

Hi everyone! As part of the celebrations for OpenStack's 15th birthday, we have created interactive birthday cards. We are inviting the community to celebrate with us by filling out the cards and sharing them on social media. There are options to both talk about your individual contributions as well as your organization’s deployment. We invite you to join in on the fun, fill out a card, and share it on social media with #WeAreOpenStack Feel free to download the files from here: https://drive.google.com/drive/folders/176go2mSHZGyRAZJPBYcIlGHpmKIIRhUo?us… If you need some inspiration, check out Thierry Carrez’s post! https://fosstodon.org/@tcarrez/114386689095092405 Cheers to 15 years of OpenStack! Helena helena(a)openinfra.dev Community Programs Manager The OpenInfra Foundation

1 0

how to config DPDK on OVN ?
by alibasafa18＠gmail.com 23 Apr '25

23 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

1 0

Fwd: DPDK+OVS with OpenStack
by Mark Wittling 23 Apr '25

23 Apr '25

Looking for someone who knows OpenStack with OpenVSwitch, and in addition to that, DPDK with OpenStack and OVS.I am using OpenStack Queens, with OpenVSwitch. The architecture I am using is documented here: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlThe OVS I am using on the Compute Node, is compiled with DPDK, and I have enabled the datapath to netdev (DPDK) on br-prv (provider network bridge), and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv, are patched into another OpenStack bridge, called br-int. I wasn’t actually sure about whether to tinker with this bridge, and wondered what datapath it was using.Then, I realized there is a parameter in the openvswitch_agent.ini file, which I will list here: # OVS datapath to use. 'system' is the default value and corresponds to the # kernel datapath. To enable the userspace datapath set this value to 'netdev'. # (string value) # Possible values: # system - <No description provided> # netdev - <No description provided> #datapath_type = system datapath_type = netdev So in tinkering with this, what I realized, is that when you set this datapath_type to system or netdev, it will adjust the br-int bridge to that datapath type.So here is my question. How can I launch a non-DPDK VM, if all of the bridges are using the netdev datapath type?Here is another question. What if one of the flavors don’t have the largepages property set on them? I assumed OpenStack would revert to a system datapath and not use DPDK for those VM interfaces. Well, I found out in testing, that is not the case. If you set all your bridges up for netdev, and you don’t set the property on the Flavor of the VM (largepages), the VM will launch, but it simply won’t work.Is there no way, on a specific Compute Host, to support both DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VM interface level (VM has one interface that is netdev DPDK and another that is system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or more netdev datapath interfaces and VM 2 has 1 or more system datapath interfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’s DPDK or nothing on that Compute Host? (edited)

3 2

[ovn-bgp-agent] Add Fernando Royo to the members list
by Rodolfo Alonso Hernandez 23 Apr '25

23 Apr '25

Hello all: I would like to propose Fernando Royo as maintainer and reviewer of the ovn-bgp-agent project [1]. As other members of the project will know, he is an active developer and reviewer. Regards. [1]https://launchpad.net/~ovn-bgp-agent-drivers/+members#active

1 0

[kolla-ansible] deploying epoxy release issues
by Satish Patel 22 Apr '25

22 Apr '25

Folks, For the experiment, I am deploying epoxy in the lab and getting some nova related issues. not sure if they are bugs or just config tuning. #BUG 1 placement_api container failed to start because of uWSIG provider issue. I have changed to apache that fixed the issue. placement_api_backend: "apache" placement_wsgi_provider: "apache" # BUG 2 or Failed it this point. TASK [nova-cell : Waiting for nova-compute services to register themselves] ****************************************************************************************************************************************** An exception occurred during task execution. To see the full traceback, use -vvv. The error was: json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) fatal: [vsan2]: FAILED! => {"msg": "Unexpected failure during module execution: Expecting value: line 1 column 1 (char 0)", "stdout": ""} # BUG 3 inside the nova-computer container I didn't see any service or process related privsep-helper --config-file /etc/nova/nova.conf is this something new or missed by bug or config? (xenv) root@vsan2:/etc/kolla# docker exec -it -u0 nova_compute bash (nova-compute)[root@vsan2 /]# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND nova 1 0.0 0.0 2644 956 ? Ss 08:28 0:00 dumb-init --single-child -- kolla_start nova 7 1.0 0.0 1883120 188576 ? Sl 08:28 0:15 /var/lib/kolla/venv/bin/python3 /var/lib/kolla/venv/bin/nova-compute root 611 1.0 0.0 7636 4128 pts/2 Ss 08:52 0:00 bash root 627 0.0 0.0 10072 1580 pts/2 R+ 08:52 0:00 ps aux

3 4

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

[kolla-ansible] Nova + ceph cache mode
by Michael Knox 22 Apr '25

22 Apr '25

Hey Folks, Is it possible to use "cache=none" and "io=native" values with a kolla-ansible deployed cloud that uses a Ceph backend? Looks like that it's hard coded to use writeback for caching when the Nova backend is rbd. No globals.yaml overrides. https://github.com/openstack/kolla-ansible/blob/8d6b5de4c19681dd6cbec45d803… Cheers Michael

3 2

Using IOThreads
by Vahric Muhtaryan 22 Apr '25

22 Apr '25

Hello Everyone, I saw that using IO Thread for instance was planned but somehow implementation is deferred. https://blueprints.launchpad.net/nova/+spec/iothreads-for-instances Are there any updates regarding the schedule for IOThread implementation? Regards Vahric

3 2

[neutron] Bug deputy week 16 (April 14 - April 20)
by Lajos Katona 22 Apr '25

22 Apr '25

Hi Neutrinos, I send the bugs from week 16 (From April 14 to April 20). *High* * test_assert_pings_during_br_phys_setup_not_lost_in_vlan_to_flat functional tests randomly fails ( https://bugs.launchpad.net/neutron/+bug/2107775 ) *Medium* * When a new security group rule is created, logging is not properly configured (https://bugs.launchpad.net/neutron/+bug/2107446 ): Fix is committed: https://review.opendev.org/c/openstack/neutron/+/947324 , but I was not able to reproduce it in my local env. * Disable gateway error with flow based DHCP ( https://bugs.launchpad.net/neutron/+bug/2107552 ) Fix is under review ( https://review.opendev.org/c/openstack/neutron/+/947560 ) *RFE*: * Same Host Traffic Leaks in Neutron DVR When Using BGP ( https://bugs.launchpad.net/neutron/+bug/2107634 ) *Fix committed* * [whitebox-neutron-tempest-plugin] QoS BW limit tests after migration should check the compute of sender and receiver ( https://bugs.launchpad.net/neutron/+bug/2107368 ) *Incomplete* * router ha was split brain when restarting l3 agent docker ( https://bugs.launchpad.net/neutron/+bug/2107323 ): More information is necessary the logs contain any relevant information. Best wishes Lajos Katona (lajoskatona)

1 0

[dalmatian]display of "enable_dhcp" in horizon
by Franck VEDEL (UGA) 22 Apr '25

22 Apr '25

2 1

rally/tempest
by jacek.grodkowski＠asseco.cloud 22 Apr '25

22 Apr '25

Hi I have problem with rally/tepest - docker container rally - release 4.1.0 openstack environment is correct visible from rally tempest plugin is correct visible from rally no matter, does rally is running from rally user or root user every time after : rally verify start i receive 2025-04-10 13:13:48.318 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default setup() finished in 6.84 sec 2025-04-10 13:13:48.318 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default setup() finished in 0.03 msec 2025-04-10 13:13:50.036 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default cleanup() started 2025-04-10 13:13:50.037 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context testr@default cleanup() finished in 0.19 msec 2025-04-10 13:13:50.037 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default cleanup() started 2025-04-10 13:13:54.021 1139 INFO rally.task.context [-] Verification b24ff97f-55c8-4ff3-9ade-1745eb6f821d | Context tempest@default cleanup() finished in 3.98 sec 2025-04-10 13:13:54.030 1139 INFO rally.api [-] Verification (UUID=d92179d4-93d4-4805-8703-9861d9ce55cc) has been successfully finished for deployment 'my_openstack' (UUID=f4746f40-8527-4e79-8ce7-9196544db770)! ====== Totals ====== Ran: 0 tests in 0.000 sec. - Success: 0 - Skipped: 0 - Expected failures: 0 - Unexpected success: 0 - Failures: 0 Using verification (UUID=d92179d4-93d4-4805-8703-9861d9ce55cc) as the default verification for the future operations. rally test - json files, have correct results when i'm using tempest in standalone version i have no problem with making tests

1 0

[PTG] Keystone summary
by Artem Goncharov 22 Apr '25

22 Apr '25

Hey, Sorry for being late. Here comes the summary from Keystone team discussions during the PTG # python-keystoneclient deprecation Following what other services are doing python-keystoneclient is going to be deprecated as a standalone entity. Work in OSC is currently underway to complete the switch to using OpenStackSDK. We want to deprecate python-keystoneclient (another codebase being duplicated) but we also see many services relying on it. We will evaluate the possibilities we have here. # Switch to the DPL model We were discussing whether it makes sense for the Keystone team to switch to the DPL model, but decided to stick to the PTL model while still formally sharing responsibilities among the team members. # External OAuth2.0 Greg gave an update of the current state of the work. We discussed some corner cases as well as tried to figure out which cases (so to say deployment types) it is suitable for and which not. At the moment this approach is suitable mostly to only certain cases # Launchpad maintenance We discussed (and performed) cleanup of the launchpad teams and removed people that are not active anymore (thanks to them for doing that before) # Service accounts Certain future use cases were discussed where introduction of the "service account" concept may be useful (similarly to what they are in K8). I am continuing prototyping on that in my federation rework and will present results once something reasonable is achieved. Major use case for service accounts may be: - workload authentication (like GitHub action, GitLab CI, etc) where a certain workload should be able to authenticate with Keystone without hardcoding a regular "user" account with the password or application credentials - something similar to the AWS STS, or better to say possibility for OpenStack services (in this example Nova) to request a token for the "service account" that can be provisioned into the VM to allow workload inside the VM to auth into the cloud # Reimplementing Keystone in Rust (with Federation rework and advanced auth based on security keys/passkeys/yubikey) I provided an update of the state of reimplementation of Keystone in Rust with the numbers describing performance improvements (10x-100x depending on the use case). Demo for the yubikey auth was given some time ago separately. We discussed how is it possible to consider Keystone following a microservices approach and for the CSPs to deploy Rust reimpl in parallel to the python keystone to start using reworked federation as well as advanced auth flows (auth with the security key) # Ephemeral credentials This discussion was tightly coupled with the previous discussions on OAuth2, service accounts and federation rework. Sadly we are currently not able to implement something similar to the AWS STS with assigning limited scope tokens before we address other issues and introduce service accounts and further explore alternative policy enforcement approaches # OpenPolicyAgent (as an extension over the oslo.policy) Back in 2018 an idea of adding support for OpenPolicyAgent into the oslo.policy was presented. This time we are much further. There is an oslo.policy plugin, converter of policies from the code to the OpenPolicyAgent (rego) language together with automatic tests generation (as well as hacks for Neutron). There is now even the first CSP rolling it out in production. This step allows CSP better integration of OpenStack with other offerings (K8, Ceph, etc) while offering huge flexibility and fine-granular access control desperately desired by CSPs and full authz audit log. Thanks to all participants. Hope to see you during our regular meetings. Keep on doing your great work :-) Regards, Artem

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - April 23rd at 0700 UTC
by Felix Kronlage-Dammers 21 Apr '25

21 Apr '25

Hi everyone, This upcoming Wednesday (April 23rd) the next meeting of the publiccloud-sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig (yes, we're back on the summer schedule) See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! cheers felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[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

[tc][ptg] OpenStack Technical Committee 2025.2 Flamingo PTG summary
by Goutham Pacha Ravi 17 Apr '25

17 Apr '25

Hello Stackers, Here’s a summary of the OpenStack Technical Committee’s discussions at the 2025.2 “Flamingo” Virtual PTG held April 7–11, 2025. Find detailed notes in our discussion etherpad [1] and recordings on YouTube [2]. Feedback is welcome on this mailing list or in OFTC’s `#openstack-tc` IRC channel, perhaps during our weekly meetings [3]. == Topic: TC Retrospective == Discussion: - We reviewed the TC’s effectiveness in addressing issues raised during the cycle, including leadership gaps, licensing concerns, project guide updates, and communication practices. - Fewer teams were leaderless following the 2025.2 election cycle—thanks to better outreach and clearer election guidance. - There was consensus that the TC guideline discouraging bare “recheck” comments and the need to address persistent gate issues is now better understood. - Licensing FAQs [4] appear outdated. We noted that the TC can escalate licensing questions to the OpenInfra Foundation’s Legal team and should monitor the `legal-discuss` list more actively. - Teams encouraging non-core contributors to become PTLs was praised as a way to grow the contributor base through mentorship. Action Items: - Update the Project Team Guide, removing obsolete sections (e.g., sprint design/process). - Update licensing references across the Project Team Guide and TC governance site. - Encourage public communication, regular meetings, and the use of team-specific IRC or Matrix channels. == Topic: Goals Retrospective == Discussion: - We reviewed the status of ongoing community-wide goals, including progress, blockers, and next steps. - Migrate CI Jobs to Ubuntu Noble [5] - The goal is complete. Teams should now remove OS version pins in their repositories. - Eventlet Migration [6] - Refer to Hervé’s PTG summary [7] for updates. - Privsep Migration [8] - Progress is slow; some minor activity exists in Gerrit, but tracking doesn’t reflect it. - The Oslo team will de-prioritize removing eventlet from `oslo-rootwrap`, as it’s expected to be retired. - Clear guidance on secure, performant `privsep` usage is needed. - FIPS Compliance [9] - CentOS Stream 10 requires x86_64-v3, unsupported by our nodepool providers. - This hardware/runtime mismatch complicates long-term testing with CS9 or Ubuntu LTS. - Alternatives discussed: Debian, Rocky Linux (but Rocky may inherit CS10's hardware constraints). - Red Hat is evaluating a `paramiko` replacement this cycle. - Consistent and Secure RBAC [10] - Progress tracked [here](https://etherpad.opendev.org/p/rbac-goal-tracking#L14). - Phase 1 (personas + drop system scope): 16 projects complete. - Phase 2 (service role): 3 projects. - Phase 3 (manager role): 3 projects. - Ghanshyam Mann (gmann) continues to chair bi-weekly IRC meetings. Action Items: - Rodolfo Alonso Hernandez (ralonsoh) to send a status update on `privsep` and flag possible `rootwrap` deprecation. - Ade lee (ade_lee) to update FIPS goal status. - SRBAC liaisons must attend bi-weekly meetings and track project progress. - Publish guidance on secure, performant `privsep` usage. == Topic: Revisiting “Unmaintained” Branches == Discussion: - The TC discussed the burden and ambiguity around maintaining aging branches. - Project teams often lack resources or interest to maintain older branches; the Release team has pursued mass EOL as a workaround. - We agreed to reduce scope and prioritize core goals (e.g., eventlet removal, CI stability) rather than preserve old branches without active interest. - TC supports giving `openstack-unmaintained-core` full responsibility for EOL decisions. We may seek volunteers earlier in the branch lifecycle. - Broken jobs in unmaintained branches flood Zuul; fixing in-repo configs may not be viable. OpenDev may opt to ignore failing jobs externally. - There’s an unregistered, unlogged `#openstack-unmaintained` IRC channel on OFTC. Action Items: - Document responsibilities of unmaintained branch liaisons and `openstack-unmaintained-core`. - Propose a new process: `openstack-unmaintained-core` sets deadlines per cycle to solicit maintainers for aging branches. If no one steps up, proceed to EOL. == Topic: TC and Community Leaders Forum == Discussion: - Governance proposal under review to expand the scope of the VMT to cover all OpenStack project teams [11]. - The TC must ensure teams prioritize security. Poor handling of vulnerabilities harms community trust and ethical responsibility. - Ideas were proposed to support the VMT, including a pool of core security contacts from contributing organizations. - Projects were reminded to review community goals and prioritize them. Adding goal timelines and cross-project prioritization was suggested. - Teams should use Stackalytics and Bitergia dashboards to track activity and identify areas needing improvement (e.g., review velocity, core participation). Action Items: - Teams must audit their Launchpad “Bug Sharing” settings and confirm their `coresec` groups contain responsible, active contributors. - PTLs and Security Liaisons should ensure they can manage the `coresec` group or delegate access. - Audit deliverables against [Security Process Requirements][12]. - Benchmark project health using Stackalytics/Bitergia. Reinforce OpenStack code review best practices [13][14]. == Topic: Finding Contributors in Some Projects is Hard == Discussion: - QA, Requirements, and Release Management teams remain understaffed. - Despite upstream investment opportunities for 2025 [15], contributor interest is low. - This is a “Tragedy of the Commons” issue: shared work without clear ownership is often deprioritized. - PTG scheduling didn’t support sufficient cross-project collaboration. - The TC was encouraged to reset perfectionist expectations—approve good-enough changes, and avoid expanding review scope unnecessarily. Action Items: - Explore QA Liaisons: trusted contributors mentored into maintaining QA repos. - Avoid nitpicking or scope creep during code reviews. - Promote and participate in the contributor survey [16]. - Document expectations and best practices in the Project Team Guide. == Topic: Splintered Conversations & Communication Barriers == Discussion: - Operators report more engagement on Reddit, Kubernetes Slack, Discord, etc., than on `openstack-discuss` or OFTC IRC. - Some organizations block Matrix due to regulatory compliance, requiring platforms with retention policies. - The OpenInfra Board will not mandate platforms—projects must choose what suits them. - IRC onboarding is hard for newcomers. - Zuul contributors reported smooth onboarding to Matrix. Its e2e encryption may make it more acceptable for compliance-sensitive orgs. - The conversation continued in the `os-operators` PTG, where there was interest in trying Matrix and Meetpad for better engagement. Action Items: - Explore use of a hosted Matrix homeserver by OpenDev as a short-term workaround for those unable to use IRC. That's a wrap! It was great fun seeing you all at the PTG. I look forward to working on these AIs with you! Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://etherpad.opendev.org/p/r.51cb4e74dd9980932d32e9a9f4e8a0ce (OS TC PTG Etherpad) [2] https://www.youtube.com/playlist?list=PLhwOhbQKWT7XYzqrx21j1uizxNxnbDf5Q (OS TC PTG Recordings) [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee (OS TC Weekly Meetings) [4] https://wiki.openstack.org/wiki/LegalIssuesFAQ (OpenStack Licensing FAQs) [5] https://governance.openstack.org/tc/goals/completed/2025.1/migrate-ci-jobs-… (Migrate to Noble goal) [6] https://governance.openstack.org/tc/goals/selected/remove-eventlet.html (Eventlet removal goal) [7] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… (Eventlet PTG Summary) [8] https://governance.openstack.org/tc/goals/selected/migrate-to-privsep.html (Privsep migration goal) [9] https://governance.openstack.org/tc/goals/selected/fips.html (FIPS compliance goal) [10] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… (SRBAC goal) [11] https://review.opendev.org/c/openstack/governance/+/944817 (TC VMT Resolution) [12] https://security.openstack.org/repos-overseen.html#requirements (Security requirements for OpenStack Projects) [13] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html (Code Reviews in the OpenStack Way) [14] https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatt… (Code Review Antipatterns) [15] https://governance.openstack.org/tc//reference/upstream-investment-opportun… (OpenStack Investment Opportunities) [16] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… (Bridging the Gap)

1 0

[cinder][PTG] 2025.2 Flamingo PTG summary
by Jon Bernard 17 Apr '25

17 Apr '25

Hello everyone, thanks for a very productive PTG for the Flamingo cycle. Below is a brief summary of the highlights. The raw etherpad notes are here [1] and both the summary and transcribed etherpad notes are captured in out wiki here [2]. # Eventlet Removal This cycle we will try complete the removal of Eventlet from our codebase. We dicussed our current usage, including calls to sleep() and tpool.Proxy(). We agreed to split the work between Eric and me. I hope we can get these patches up and reviewed with time to spare before the release. An idea to revive our fake volume driver was raised to potentially gain greater confidence in high concurrency test configurations. # Testing Volume Replication Although volume replication is support by a few of our in-tree drivers, there are no integration tests that verify correct behaviour in tempest. Discussions on adding tempest tests lead to Liron being interested in driving this effort. Changes will need to be made to devstack-ceph plugin to support deploying multiple ceph clusters, as well as gate configuration to run all of this in a multi-node environment. There are a few important moving pieces which may take some time to sort out, but we agreed to commit to working towards a solution in this cycle. # Follow-up from Epoxy We have a few patch series that we didn't have time to review by the deadline of the Epoxy cycle. Volume type metadata, encryption format, and dm-clone just to name a few. Effort in reviewing and gathering feedback needs to be prioritized in the first half of the cycle to make sure we can confidently land these in Flamingo. # CI status We should review our 3rd party CI instances to make sure they're actually running, running the correct tests in the context of the related change, and reporting results that can be viewed by a gerrit reviewer. It was noted that some of them fall short of some or all of these requirements. It would be helpful to gather a current status so that we can help vendors with awareness. # 2023.2 Final Stable Release On April 30, the stable/2023.2 branch will have it's final release. This will mark the end of cinderlib. We still have a few backports that need reviews currently, see etherpad for details. # Backup Improvements crohmann raised 2 patches that both improve the speed of cinder-backup's startup routine, and decouple a volume's backup status from it's overall status. Eric and Brian agreed to review to help move these patches forward. # RBD Geometry Option We've have an old patch to allow RBD's disk geometry to be configurable. This reportedly improves performance of Windows guests significantly. We agreed to make sure this gets reviewed in this cycle. # Stephen's Patches We have 3 patches carried over from last cycle that need review. These include an OpenAPI series, a patch to map block storage AZs to Compute AZs, and updates to OSC. It would be really nice to get these reviewed in this cycle. # Tobias' Patches We have several patches from Tobias all related to cinder-backup improvements. Including adding support for backup service to os-availability-zone, support for filters in query parameters, the addition of a summary API, and potentially adding a `type` field to the API to open the posibility of support backups types beyond just `full` or `incremental`. [1] https://etherpad.opendev.org/p/apr2025-ptg-cinder [2] https://wiki.openstack.org/wiki/CinderFlamingoPTGSummary -- Jon

1 0

OpenInfra Summit Europe registration now open
by Jeremy Stanley 17 Apr '25

17 Apr '25

As most of you already know, the OpenInfra Summit Europe this year is October 17-19 at the École Polytechnique Paris-Saclay in France. Registration is now open here: https://summit2025.openinfra.org/ Don't forget, the CFP closes on June 13! If you're planning to submit a talk, there's still time but don't wait too long. For additional info, see this more detailed announcement on the foundation mailing list: https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/me… -- Jeremy Stanley

1 0

[dev][infra][tact-sig][tc] Image availability in OpenDev
by Jeremy Stanley 17 Apr '25

17 Apr '25

I want to call everyone's attention to an announcement from the OpenDev Collaboratory sysadmins: https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/t… The quick summary is that help is needed with ongoing maintenance of the following test platform images, or else they may be removed in the not too distant future: * CentOS Stream (x86 and Arm) * Rocky Linux (x86 and Arm) * Ubuntu (Arm only) * Debian (Arm only) In addition, these images have been unmaintained for a long time and can't currently be rebuilt, so without immediate intervention will be removed very soon: * openEuler * Gentoo See the above service-discuss mailing list thread for more details, and follow up there if you can help out. Thanks in advance! -- Jeremy Stanley

1 0

[watcher] 2025.2 Flamingo PTG summary
by Douglas Viroel 17 Apr '25

17 Apr '25

Hello everyone, Last week's PTG had very interesting topics. Thank you all that joined. The Watcher PTG etherpad with all notes is available here: https://etherpad.opendev.org/p/apr2025-ptg-watcher Here is a summary of the discussions that we had, including the great cross-project sessions with Telemetry, Horizon and Nova team: Tech Debt (chandankumar/sean-k-mooney) ================================= a) Croniter - Project is being abandoned as per https://pypi.org/project/croniter/#disclaimer - Watcher uses croniter to calculate a new schedule time to run an audit (continuous). It is also used to validate cron like syntax - Agreed: replace croniter with appscheduler's cron methods. - *AI*: (chandankumar) Fix in master branch and backport to 2025.1 b) Support status of Watcher Datasources - Only Gnocchi and Prometheus have CI job running tempest tests (with scenario tests) - Monaska is inactive since 2024.1 - *AI*: (jgilaber) Mark Monasca and Grafana as deprecated, unless someone steps up to maintain them, which should include a minimal CI job running. - *AI*: (dviroel) Document a support matrix between Strategies and Datasources, which ones are production ready or experimental, and testing coverage. c) Eventlet Removal - Team is going to look at how the eventlet is used in Watcher and start a PoC of its removal. - Chandan Kumar and dviroel volunteer to help in this effort. - Planned for 2026.1 cycle. Workflow/API Improvements (amoralej) ============================== a) Actions states - Currently Actions updates from Pending to Succeeded or Failed, but these do not cover some important scenarios - If an Action's pre_conditions fails, the action is set to FAILED, but for some scenarios, it could be just SKIPPED and continue the workflow. - Proposal: New SKIPPED state for action. E.g: In a Nova Migration Action, if the instance doesn't exist in the source host, it can be skipped instead of fail. - Proposal: Users could also manually skip specific actions from an action plan. - A skip_reason field could also be added to document the reason behind the skip: user's request, pre-condition check, etc. - *AI*: (amoralej) Create a spec to describe the proposed changes. b) Meaning of SUCCEEDED state in Action Plan - Currently means that all actions are triggered, even if all of them fail, which can be confusing for users. - Docs mention that SUCCEEDED state means that all actions have been successfully executed. - *AI*: (amoralej) Document the current behavior as a bug (Priority High) - done: https://bugs.launchpad.net/watcher/+bug/2106407 Watcher-Dashboard: Priorities to next release (amoralej) =========================================== a) Add integration/functional tests - Project is missing integration/functional tests and a CI job running against changes in the repo - No general conclusion and we will follow up with Horizon team - *AI*: (chandankumar/rlandy) sync with Horizon team about testing the plugin with horizon. - *AI*: (chandankumar/rlandy) devstack job running on new changes for watcher-dashboard repo. b) Add parameters to Audits - It is missing on the watcher-dashboard side. Without it, it is not possible to define some important parameters. - Should be addressed by a blueprint - Contributors to this feature: chandankumar Watcher cluster model collector improvement ideas (dviroel) ============================================= - Brainstorm ideas to improve watcher collector process, since we still see a lot of issues due to outdated models when running audits - Both scheduled model update and event-based updates are enabled in CI today - It is unknown the current state of event-based updates from Nova notification. Code needs to be reviewed and improvements/fixes can be proposed - e.g: https://bugs.launchpad.net/watcher/+bug/2104220/comments/3 - We need to check if we are processing the right notifications of if is a bug on Nova - Proposal: Refresh the model before running an audit. A rate limit should be considered to avoid too many refreshments. - *AI*: (dviroel) new spec for cluster model refresh, based on audit trigger - *AI:* (dviroel) investigate the processing of nova events in Watcher Watcher and Nova's visible constraints (dviroel) ==================================== - Currently, Watcher can propose solutions that include server migrations that violate some Nova constraints like: scheduler_hints, server_groups, pinned_az, etc. - In Epoxy release, Nova's API was improved to also show scheduler_hints and image_properties, allowing external services, like watcher, to query and use this information when calculating new solutions. - https://docs.openstack.org/releasenotes/nova/2025.1.html#new-features - Proposal: Extend compute instance model to include new properties, which can be retrieved via novaclient. Update strategies to filter invalid migration destinations based on these new properties. - *AI*: (dviroel) Propose a spec to better document the proposal. No API changes are expected here. Replacement for noisy neighbor policy (jgilaber) ==================================== - The existing noisy neighbor strategy is based on L3 Cache metrics, which is not available anymore, since the support for it was dropped from the kernel and from Nova. - In order to keep this strategy, new metrics need to be considered: cpu_steal? io_wait? cache_misses? - *AI*: (jgilaber) Mark the strategy as deprecated during this cycle - *AI*: (TBD) Identify new metrics to be used - *AI*: (TBD) Work on a replacement for the current strategy Host Maintenance strategy new use case (jeno8) ===================================== - New use case for Host Maintenance strategy: instance with ephemeral disks should not be migrated at all. - Spec proposed: https://review.opendev.org/c/openstack/watcher-specs/+/943873 - New action to stop instances when both live/cold migration are disabled by the user - *AI*: (All) Review the spec and continue with discussion there. Missing Contributor Docs (sean-k-mooney) ================================ - Doc missing: Scope of the project, e.g: https://docs.openstack.org/nova/latest/contributor/project-scope.html - *AI*: (rlandy) Create a scope of the project doc for Watcher - Doc missing: PTL Guide, e.g: https://docs.openstack.org/nova/latest/contributor/ptl-guide.html - *AI*: (TBD) Create a PTL Guide for Watcher project - Document: When to create a spec vs blueprint vs bug - *AI*: (TBD) Create a doc section to describe the process based on what is being modified in the code. Retrospective ========== - The DPL approach seems to be working for Watcher - New core members added: sean-k-mooney, dviroel, marios and chandankumar - We plan to add more cores in the next cycle, based on reviews and engagement. - We plan to remove not active members in the 2 last cycles (starting at 2026.1) - A new datasource was added: Prometheus - Prometheus job now also runs scenario tests, along with Gnocchi. - We triaged all old bugs from launchpad - Needs improvement: - current team is still learning about details in the code, much of the historical knowledge was lost with the previous maintainers - core team still needs to grow - we need to focus on creating stable releases Cross-project session with Horizon team =============================== - Combined session with Telemetry and Horizon team, focused on how to provide a tenant and an admin dashboard to visualize metrics. - Watcher team presented some ideas of new panels for both admin and tenants, and sean-k-mooney raised a discussion about frameworks that can be used to implement them - Use-cases that were discussed: - a) Admin would benefit from a visualization of the infrastructure utilization (real usage metrics), so they can identify bottlenecks and plan optimization - b) A tenant would like to view their workload performance, checking real usage of cpu/ram/disk of instances, to proper adjust their resources allocation. - c) An admin user of watcher service would like to visualize metrics generated by watcher strategies like standard deviation of host metrics. - sean-k-mooney presented an initial PoC on how a Hypervisor Metrics dashboard would look like. - Proposal for next steps: - start a new horizon plugin as an official deliverable of telemetry project - still unclear which framework to use for building charts - dashboard will integrate with Prometheus, as metric store - it is expected that only short term metrics will be supported (7 days) - python-observability-client will be used to query Prometheus Cross-project session with Nova team ============================= - sean-k-mooney led topics on how to evolve Nova to better assist other services, like Watcher, to take actions on instances. The team agreed on a proposal of using the existing metadata API to annotate instance's supported lifecycle operations. This information is very useful to improve Watcher's strategy's algorithms. Some example of instance's metadata could be: - lifecycle:cold-migratable=true|false - ha:maintenance-strategy:in_place|power_off|migrate - It was discussed that Nova could infer which operations are valid or not, based on information like: virt driver, flavor, image properties, etc. This feature was initially named 'instance capabilities' and will require a spec for further discussions. - Another topic of interest, also raised by Sean, was about adding new standard traits to resource providers, like PRESSURE_CPU and PRESSURE_DISK. These traits can be used to weight hosts when placing new VMs. Watcher and the libvirt driver could work on annotating them, but the team generally agreed that the libvirt driver is preferred here. - More info at Nova PTG etherpad [0] and sean's summary blog [1] [0] https://etherpad.opendev.org/p/r.bf5f1185e201e31ed8c3adeb45e3cf6d [1] https://www.seanmooney.info/blog/2025.2-ptg/#watcher-topics Please let me know if I missed something. Thanks! -- Douglas Viroel - dviroel

4 7

[ops][sdk] Does anyone rely on the osclient/python-openstackclient container image?
by Stephen Finucane 17 Apr '25

17 Apr '25

o/ The python-openstackclient project has an 'osc-upload-image' job that builds and uploads a Docker image to 'osclient/python-openstackclient' on docker.io [1]. This job has been failing intermittently over recent months due to changes in the docker.io rate limits. At this point, I am inclined to remove the job since the image does not appear to be documented anywhere and I'm not aware of anyone relying on it. Before I do though, I'd like to check if this is the case or if someone is in fact relying on it. If anyone *is* doing so, I'd like suggestions for a different image registry we can use, as well as assistance in updating the jobs to use this image registry. If not, I'll likely push to remove this within the next 2-3 weeks. Cheers, Stephen [1] https://hub.docker.com/r/osclient/python-openstackclient

2 2

Is DHCP relay in Openstack
by Andrei RADU 17 Apr '25

17 Apr '25

Hello, This is my first interaction with Openstck mailinglists so hopefully I am sending this question to the correct place😊 The question is simple: does Openstack(Neutron) natively support DHCP relay? We have currently a (test) deployment using OVS driver but we may think switching to OVN. We would like to use an external DHCP server(BlueCat) that is already handling the rest of our network DHCP. I could not find anything related to this in docs. I found this spec: https://review.opendev.org/c/openstack/neutron-specs/+/105660 which seems to have been abandoned. I saw they mention the ISC.org dhcp relay tool. I saw it was deprecated in 20222 and not supported anymore and the new product Kea seems to lack the DHCP relay feature. I guess we could search for other solutions(If anyone has experience in this topic I would be grateful) but we would very much prefer a native, integrated solution that would be easy to manage. So is DHCP supported or planned to be supported in the near future? Best Regards, Andrei <a href="https://www.linkedin.com/company/the-pictet-group" target="_blank"></a> <a href="https://www.instagram.com/pictetgroup/" target="_blank"></a> <a href="https://twitter.com/PictetGroup" target="_blank"></a> This message is not intended for persons who are citizens of, domiciled or resident in, or entities registered in a country or jurisdiction in which its distribution, publication, provision or use would violate current laws and regulations. The content of this message is confidential and may be read and/or used only by the recipient of this message. For information about personal data protection, please refer to the Pictet Group’s Privacy Notice available at www.pictet.com/privacynotice. If you have received this e-mail message in error, please destroy it and delete it from your computer. The Pictet Group may not be held liable for the use, transmission or treatment of the content of this message. The recipient of this message remains solely liable for any form of reproduction, copying, disclosure, modification and/or publication of the content. No liability whatsoever will be incurred by the Pictet Group. The recipient of this message agrees to comply with the applicable laws and regulations in the jurisdictions where they use the information contained herein.<br>

3 3

[OpenInfra Foundation] VMware to OpenStack Migration Survey
by Jimmy McArthur 16 Apr '25

16 Apr '25

Last year we created the first VMware to OpenStack Migration survey and gained some valuable insight into the state of the market given the Broadcom shakeup. This year, we’re expanding the scope a bit and have added some new questions. I’d greatly appreciate it if you could take a few moments and fill this out if your organization has any business interest in this topic. https://openinfrafoundation.formstack.com/forms/vmware_strategy_survey_nm Please note that there are a couple of opportunities highlighted in the survey: An option to do a customer case study and opting your org in to sharing info with some research firms that have expressed interest in this topic. I am more than happy to answer any questions around the survey and/or data usage! Thanks everyone! Jimmy McArthur OpenInfra Foundation

1 0

[nova][ptg] 2025.2 Flamingo PTG summary
by Rene Ribaud 16 Apr '25

16 Apr '25

Hello everyone, Last week was the PTG—thank you to those who joined! I hope you enjoyed it. I haven’t gathered exact attendance stats, but it seemed that most sessions had at least around 15 participants, with some peaks during the cross-team discussions. If you’d like to take a closer look, here’s the link to the PTG etherpad: https://etherpad.opendev.org/p/r.bf5f1185e201e31ed8c3adeb45e3cf6d We had a pretty full agenda for Nova, so here’s a summary I’ve tried to keep as short as possible. #### 2025.1 Epoxy Retrospective #### 17 specs were accepted, and 12 implemented — an excellent ratio. This represents a clear improvement over previous cycles. Virtiofs was successfully merged, unblocking other work and boosting contributor motivation. ✅ We agreed to maintain regular status updates via the etherpad and follow up during Nova meetings. API Microversions & Tempest Coverage, several microversions were merged with good structure. However, some schema changes were not reflected in Tempest, causing downstream blockers. Also the updates covered by the microversions were not propagated into the sdk and openstack client. ✅ Ensure client-side features (e.g., server show) are also published and tracked. ✅ Keep microversions isolated and document Tempest implications clearly in specs. ✅ Raise awareness of the tempest-with-latest-microversion job during Nova meetings. ✅ Monitor OpenAPI efforts in Nova, which may allow offloading schema checks from Tempest in the future. Eventlet Removal, progress is behind schedule, especially compared to other projects like Neutron. ✅ Flag this as a priority area for upcoming cycles. Review Process & Tracking, spec review days were difficult to coordinate, and the status etherpad often outdated. ✅ Encourage active contributors to support occasional contributors during review days. ✅ Commit to keeping the etherpad current throughout the cycle. #### 2025.2 Flamingo Planning #### Timeline: Soft spec freeze (no new specs): June 1st Hard spec freeze (M2): July 3rd Feature Freeze (FF): August 28th Final release: late September / early October ✅ We agreed to officially adopt June 1st as the soft freeze date, based on the successful approach in Epoxy. ✅ A spec review day will be scheduled around mid June, these will be scheduled and announced early to ensure participation. ✅ Uggla will update the schedule document with the proposed milestones. #### Upstream Bug Triage #### We acknowledged that active bug triage has slowed down, resulting in a backlog increase (~150 untriaged bugs). There is a consensus that triage remains important to maintain a clear picture of the actual bug landscape. ✅ Trial a new approach: review some untriaged bugs at the end of Nova team meetings. ✅ Process the list by age (starting with the newest or most-voted first). #### Closing Old Bugs #### A proposal was made to bulk-close bugs older than 2 years, with a respectful and explanatory message, aiming to reduce backlog and improve visibility. However, multiple voices expressed strong reservations. ✅Take no action for now. Focus efforts on triaging new bugs first. ✅ If we successfully reduce the number of untriaged new bugs, we can consider scrubbing the bug backlog and possibly closing some of the older ones. #### Preparation for Python 3.13 #### While Python 3.13 is not mandatory for 2025.2, early compatibility work was discussed due to known issues (e.g., eventlet is broken on 3.13, as observed on Ubuntu 25.04) Ubuntu 24.04 and CentOS Stream 10 will stay on 3.12 for their supported lifespans. A non-voting unit test job for Python 3.13 (openstack-tox-py313) has already been added and is currently passing. Introducing a functional job for 3.13 could be a good next step, if resources allow. ✅ Gibi will track this as part of the broader eventlet removal work. #### Confidential Computing Feature Planning #### AMD SEV is already supported in Nova. SEV-ES is implemented in libvirt and work is ongoing in Nova. SEV-SNP is now supported in libvirt (v10.5.0). Work in Nova has not started yet. ✅ Pay closer attention to SEV-ES reviews to help move this forward. ✅ Tkajinam will write a new spec for SEV-SNP. Intel TDX Kernel support is nearly ready (expected in 6.15). Libvirt patches exist, but feature is not yet upstreamed or widely released. ✅ No action agreed yet, as this remains exploratory. Arm CCA No hardware is available yet; earliest expected in April 2027 (Fujitsu Monaka). Support in libvirt, QEMU, and Linux kernel is still under development. ✅ The use case is reasonable, but too early to proceed — we should wait until libvirt and QEMU support is mature. ✅ It would be beneficial to wait for at least one Linux distribution to officially support Arm CCA, allowing real-world testing. ✅ Attestation support for Arm is seen as external to Nova, with only minor flags possibly needed in the guest. #### RDT / MPAM Feature Discussion #### RDT (Intel PQoS) and MPAM (Arm equivalent) aim to mitigate “noisy neighbor” issues by allocating cache/memory bandwidth to VMs. Development has stalled since 2019, primarily due to: - Lower priority for contributors - Lack of customer demand - Infrastructure complexity (NUMA modeling, placement limitations) ✅ r-taketn to reopen and revise the original spec, showing a clear diff to the previous version. ✅ Ensure that abstractions are generic, not tied to proprietary technology, using libvirt + resource classes/traits may provide enough flexibility. #### vTPM Live Migration #### A spec for vTPM live migration was approved in Epoxy: https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/vtpm… <https://specs.openstack.org/openstack/nova-specs/specs/2025.1/approved/vtpm…>To support live-migratable vTPM-enabled instances, Barbican secrets used for vTPM need to be owned by Nova, rather than the end user. This shift in ownership allows Nova to access the secret during live migration operations. Opt-in is handled via image property or flavor extra spec, meaning user consent is explicitly required. Current Proposal to enable this workflow: - Castellan should allow per-call configuration for sending the service token (rather than relying on a global all-or-nothing setting). Proposal: https://review.opendev.org/c/openstack/castellan/+/942015 - If the Nova service token is present, Barbican should set the secret owner to Nova. Proposal: https://review.opendev.org/c/openstack/barbican/+/942016 This workflow ensures Nova can read/delete the secret during lifecycle operations like migration, without involving the user. A question was raised around possible co-ownership between Nova and the end user (e.g., both having access to the secret). While this may be interesting longer-term, current implementation assumes a single owner. ✅ User and host modes are as described in the spec. For deployment mode, Nova will: - Authenticate to Barbican as itself (using a service token). - Own the vTPM secret it creates — it will be able to create, read, and delete it. - The user will not see or control the secret, including deletion. - The secret will be visible to other members of the Nova service project by default, but this could be restricted in future via Barbican ACLs to limit visibility to Nova only. #### Cloud Hypervisor Integration #### There is an ongoing effort to integrate Cloud Hypervisor into Nova via the Libvirt driver: Spec: https://review.opendev.org/c/openstack/nova-specs/+/945549 The current PoC requires only minor changes to work with Libvirt, and the team is ready to present the proposal at the PTG. ✅ We’re happy with the direction the spec is taking. Below are some key highlights regarding the spec. ✅ Clarify platform support (e.g., is libvirt compiled with cloud hypervisor support by default? Is it available in distros?). ✅ Provide a plan for runtime attach of multiple NICs and volumes. ✅ Mark as experimental if cloud hypervisor is not yet in upstream distro packages. ✅ Ensure that the following features are expected to work and covered in the spec: resize, migrate, rebuild, evacuate, snapshot. ✅ Justify raw-only image support, and outline the path to qcow2 compatibility. #### vGPU (mdev) and PCI SR-IOV Topics #### 1. Live-migratable flag handling (physical_network tag) Bug: https://bugs.launchpad.net/nova/+bug/2102161 ✅ We agreed that the current behavior is correct and consistent with the intention: If live_migratable = false → fallback to hotplug during live migration. If live_migratable = true on both source and destination → prefer transparent live migration. ✅ Investigate how Neutron might participate by requesting live-migratable ports. 2. Preemptive live migration failure for non-migratable PCI devices Nova currently checks for migratability during scheduling and conductor phases. There’s a proposal to move these checks earlier, possibly to the API level. Bug: https://bugs.launchpad.net/nova/+bug/2103631 ✅ Confirm with gmann whether a microversion is needed — likely not, as return codes are already supported (202 → 400/409). ✅ Uggla may submit a small spec to formalize this change. ✅ Split the work into two steps: - Fix existing bug (can be backported). - Incrementally move other validations earlier in the flow. 3. PCI SR-IOV: Unify the Live Migration Code Path There’s agreement on the need to reduce technical debt by refactoring the current dual-code-path approach into a unified model for PCI live migration. ✅ A dedicated spec is needed to clarify and unify PCI claiming and allocation. ✅ This refactor should address PCI claiming and allocation, potentially deprecating or replacing move_claim in favor of more robust DB-backed logic. ✅ This effort is directly related to point 1 (migratability awareness) and will help ensure consistent resource management across the codebase. #### SPICE VDI – Next Steps #### There is an ongoing effort to enhance libvirt domain XML configuration for desktop virtualization use cases (e.g. SPICE with USB and sound controllers). Some patches were proposed but not merged in time for Epoxy. Mikal raised the question of whether a new spec would be required in Flamingo, which would be the third iteration of this work. The team also raised concern about the complexity of adding traits (e.g. os-traits) for relatively simple additions, due to the multi-step process involved (traits patch, release, requirements update, etc.). ✅ Proceed with a specless blueprint. ✅ Plan to pull os-traits and os-resource-classes logic into Placement, to simplify the integration process and reduce friction. Link the required Placement version in Nova documentation accordingly. This is a strategic direction, even if some traits might still be shared with Neutron/Cinder. #### Virtiofs Client Support #### The virtiofs server-side support was merged in Epoxy, but SDK and client-side support did not make it in time. The proposal is to merge both patches early in Flamingo and then backport to Epoxy. ✅ No concern with microversion usage here. ✅The ordering of microversion support patches across Nova, SDKs, and clients will be handled by respective owners. ✅ Uggla to track that each new microversion in Nova has a corresponding patch in SDK/client layers. ✅ Not directly related to virtiofs, but the new reset-state confirmation prompt in the client was noted and welcomed. #### One-Time-Use (OTU) Devices #### OTU devices are designed to be consumed once and then unreserved. There is a need to provide practical guidance on handling these cleanly, especially in notification-driven environments. Additionally, there's an important patch related to Placement behavior on over-capacity nodes: https://review.opendev.org/c/openstack/placement/+/945465 Placement currently blocks new allocations on over-capacity nodes — even if the new allocation reduces usage. This breaks migration from overloaded hosts. The proposed fix allows allocations that do not worsen (or improve) usage. Note: A similar OTU device handling strategy has been successfully used in Ironic. ✅ Provide an example script or tool for external OTU device cleanup, based on notifications. ✅ Agreement on the proposed Placement fix — it is operator-friendly and resolves real issues in migration workflows. ✅ We likely need to dig deeper into implementation and tooling for broader OTU support. #### Glance cross-project session #### Please look at glance summary. #### Secure RBAC – Finalization Plan #### Tobias raised concerns about incomplete secure RBAC support in Nova, particularly around default roles and policy behavior. Much of the groundwork has been done, but a number of patches still require review and finalization. ✅ Gmann will continue working on the outstanding patches during the Flamingo cycle. The objective is to complete secure RBAC support in Nova as part of this cycle. #### Image Properties Handling – DB Schema & API Response #### The issue arises from discrepancies between image property metadata stored by Nova and what is received from Glance. Nova’s DB schema enforces a 255-character limit on metadata keys and values, which can lead to silent truncation or hard failures (e.g., when prefixing keys like image_ pushes the total length over 255). Nova stopped supporting custom image properties nearly a decade ago, when the system moved to structured objects (ImageMetaProps via OVO). Glance still allows some custom metadata, which may be passed through to Nova. This led to invalid or non-standard keys (e.g., owner_specified.openstack.sha256) being stored or exposed, even though they are not part of Nova’s supported set. Consensus emerged that we are facing two issues: - Nova's API may expose more metadata than it should (from Glance). - Nova stores non-standard or overly long keys/values, resulting in silent truncation or hard DB errors. ✅ Nova should stop storing non-standard image properties altogether. ✅ A cleanup plan should be created to remove existing unused or invalid metadata from Nova's database post-upgrade. ✅ During instance.save(), Nova should identify and delete unused image_* keys from the system metadata table. ✅ We must be cautious to preserve snapshot-related keys that are valid but not part of the base ImageMetaProps. ✅ These changes are considered bugfixes and can proceed without a new spec. #### Eventlet removal #### Please read the excellent blog post series from Gibi here: https://gibizer.github.io/posts/Eventlet-Removal-Flamingo-PTG/ #### Enhanced Granularity and Live Application of QoS #### This was cross team Neutron/Cinder/Nova first topic. Bloomberg folks presented early ideas around making QoS settings more granular and mutable, and potentially applicable to existing ports or VMs, not just at creation time. Nova does not operate on multiple instances at once, which conflicts with some proposed behaviors (e.g., live update of QoS on a network/project level). QoS is currently exposed via flavors in Nova, and is only supported on the frontend for the Libvirt driver. QoS mutability is non-trivial, with implications for scheduling, resource modeling, and placement interactions. The scope is broad and would require cross-project collaboration (Neutron, Cinder, Placement). Use cases and notes from Bloomberg: https://etherpad.opendev.org/p/OpenStack_QoS_Feature_Enhancement_Discussion ✅ Use flavor-based modeling for QoS remains the Nova approach. ✅ Nova should not apply policies across many instances simultaneously. ✅ A spec will be required, especially if new APIs or behavior modifications for existing VMs are introduced. The spec should provide concrete use case examples and API design proposals, including expected behavior during lifecycle operations (resize, rebuild, shelve, etc.). ✅ Max bandwidth adjustments may be possible (as they don’t require reservations), but broader mutability is more complex. ✅ Neutron and Cinder raised no objections regarding Bloomberg’s use cases and proposals. However, please look at Neutron and Cinder's respective summaries. #### Moving TAP Device Creation from Libvirt to os-vif #### This change proposes moving the creation of TAP devices from the Libvirt driver into os-vif, making it more consistent and decoupled. However, it introduces upgrade and timing considerations, especially regarding Neutron and OVN behavior. Bug: https://bugs.launchpad.net/nova/+bug/2073254 Patch: https://review.opendev.org/c/openstack/nova/+/942786 ✅ Neutron team is open to adjusting the timing of the "port ready" event, which could eliminate the need for Nova-side hacks. ✅ Sean will proceed with the patch and verify behavior through CI. #### Instance Annotations, Labels & K8s-Like Semantics #### Sean proposed introducing a mechanism similar to Kubernetes annotations and labels in Nova, to: - Express user intent regarding instance behavior (e.g., "should this instance be migrated?") - Convey lifecycle preferences to external tools like Watcher and Masakari - Expose capabilities or constraints of an instance (e.g., "cannot be shelved because it has a vTPM") Proposed Examples of Instance Annotations: lifecycle:live-migratable=true|false ha:role=primary|secondary These would be: - Set by users (or operators) - Optionally inherited from flavors (but conflicts would raise 400 Bad Request) - Expressed intent only — not enforcement of policy In addition, labels generated by Nova could reflect actual capabilities, like: lifecycle:live-migratable=false if an instance has a PCI device lifecycle:shelvable=false if it uses vTPM ✅ Define a new API to expose capabilities of instances (e.g., “can this instance be live-migrated?”) Values will be derived by Nova based on configuration/hardware and exposed via nova server show. ✅ Sean will create a spec. ✅ Looking at user-defined labels, we eventually considered defining a second API for them to express scheduling/HA preferences. However we decided the current preferred approach is to start with metadata API, and evolve to a first-class model. We may need admin-only metadata (e.g., for HA tooling like Masakari) this has been discussed in Admin-Only Instance Metadata / Annotations later point. ✅ Sean will also create a spec for this. (Sean). #### External Traits and Node Pressure Metrics #### Sean also proposed allowing external systems (e.g., Watcher, telemetry agents) to annotate compute nodes with traits such as memory/cpu/io pressure, based on /proc/pressure. Examples: CUSTOM_MEM_PRESSURE=high EXTERNAL_IO_PRESSURE=moderate ✅ Support a COMPUTE_MEM_PRESSURE-like trait, populated from sysfs as static info (not dynamic). ✅ A weigher could use these traits to influence placement.Default traits list could be configured (e.g., prefer/avoid hosts with certain pressures or hardware features). This approach could evolve into a generic “preferred traits” weigher, similar to Kubernetes taints/tolerations. ✅Sean will create a dedicated spec for this feature. ✅ Sbauza volunteered to help, especially as the work aligns with weigher logic from the previous cycle. #### OpenAPI Schema Integration #### Stephen highlighted that most of the heavy lifting for OpenAPI support is now complete, and the work is down to pure response schema definitions. This effort spans over three cycles now, and it would be valuable to finalize it early in Flamingo. ✅ We'll formalize this work with a blueprint. ✅ The goal is to make early progress in Flamingo, ideally with a dedicated review day. ✅ Stephen is happy to join synchronous review sessions and will coordinate pings for progress. ✅ Masahito volunteered to help with the remaining work. #### OpenStack SDK & Client Workflows #### Stephen raised a few concerns regarding timing mismatches between SDK/OSC freezes and microversion patch merges in Nova. Some microversion support landed too late to be integrated in the SDK before the Epoxy freeze. Patches were sometimes missed due to lack of "depends-on" links or broken initial submissions. ✅ Uggla will follow up and finalize these patches early in the Flamingo cycle. #### Upstream Testing for PCI Passthrough and mdev Devices #### With IGB support merged in Epoxy, and vIOMMU enabled in some Vexxhost workers (thanks to dansmith), the opportunity exists to expand PCI testing upstream in Tempest. This would also benefit testing of one-time-use (OTU) devices. Finalizing mtty testing is a priority, as it helps ensure device support is consistent and regressions (like bug #2098892) are caught early. ✅ Bauzas will lead on wrapping up mtty testing. ✅ Gibi will coordinate with cloud providers to assess Epoxy support and revisit this topic during the next PTG if needed. #### CPU Power Management – Expected Behavior #### Melanie raised questions about inconsistencies between design and implementation in Nova’s CPU power management logic. In particular: - CPUs were being offlined too aggressively, sometimes during reboot or migration operations. - This contradicts the intent that only unassigned or deallocated cores should be powered off. There was confusion between two approaches: - Aggressive power-down of unused CPUs during all idle states (stop, shelve, etc.) - Conservative behavior, powering off cores only when the VM is deleted or migrated away Consensus favored the aggressive-but-safe model: - Power down cores only when not used, e.g., VM is stopped or migrated. - Be cautious not to power off cores prematurely (e.g., during reboot or verify-resize). ✅ Do not rush to power off CPU cores at compute startup or mid-operation. ✅ Revisit the implementation so the resource tracker runs first, and determines actual core assignments before making decisions. #### Live Migration with Encrypted Volumes (Barbican Integration) #### HJ-KIM raised the point that Nova does not currently support live migration of instances using encrypted Cinder volumes managed by Barbican. This is a critical blocker in environments with strict compliance requirements. ✅ This is a parallel issue to vTPM support. We will learn from the vTPM implementation and consider applying similar concepts. ✅ A future solution may involve adjusting how ownership is managed, or providing scoped access via ACLs. ✅ Further discussion/spec work will be needed once an implementation direction is clearer. #### Manila–Nova Cross-Team Integration #### The initial Manila–Nova integration is now merged — thanks to everyone involved! The next step is to: - Add automated testing (currently manual tests only). - Start with a few basic positive and negative test scenarios (create, attach, write, delete; snapshot and restore; rule visibility; restricted deletion; etc.). Additionally, longer-term features and improvements are being considered please look at the etherpad. ✅ We will work on tempest tests. ✅ We will continue enhancing Nova–Manila integration during Flamingo (F) and beyond. ✅ Uggla will submit a spec as needed for land memfd support. #### Provider Traits Management via provider.yaml #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/937587 Problem: Traits defined in provider.yaml are added to Placement but never removed if deleted from the file. ✅ Implement a mechanism where Nova copies the applied file to /var/lib/nova/applied_provider.yaml, and diffs it with the active one on restart. This would allow traits (and possibly other config) to be safely removed. #### Admin-Only Instance Metadata / Annotations #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/939190 Issue: Current instance metadata is user-owned, and shouldn't be used by admins. Proposal: Introduce admin-only annotations (or metadata with ownership tracking), allowing operators to set system-visible metadata without violating user intent. ✅ Introduce a created_by field (similar to locked_by) to track who created metadata: user vs admin. Consider an admin: prefix namespace for admin-controlled keys (applied to annotations or metadata). Implementation requires a DB change and a nova-spec. Note: This aligns well with broader annotation work already discussed in this cycle. #### delete_on_terminate for Ports (Server Create / Network Attach APIs) #### 📌 Related discussion: https://review.opendev.org/c/openstack/nova-specs/+/936990 Background: This was discussed in past PTGs. Currently, delete_on_terminate can't be updated dynamically across instance lifetime. ✅ A spec with a working PoC will help clarify the desired behavior and unblock the discussion. Long-term solution may require storing this flag in Neutron as a port property (rather than Nova-specific DB). #### Graceful Shutdown of Nova Compute Services #### 📌 Spec: https://review.opendev.org/c/openstack/nova-specs/+/937185 Challenge: Need a mechanism to drain compute nodes gracefully before shutdown, without interrupting active workloads or migrations. Graceful shutdown is tricky in the presence of live migrations. Ideas include: - Temporary “maintenance mode” (block write requests). - Group-level compute draining. ✅ The topic is important but not urgent — bandwidth is limited. Note: Eventlet removal may simplify implementing this. ✅ Please report concrete bugs so we understand the blockers. ✅ A nova-spec with PoC would help drive the conversation. #### Libvirt/QEMU Attributes via Flavor Extra Specs #### Target: Advanced tuning of I/O performance via iothreads and virtqueue mapping, based on: https://developers.redhat.com/articles/2024/09/05/scaling-virtio-blk-disk-i… ✅ Introduce new flavor extra specs such as: - hw:io_threads=4 - hw:blk_multiqueue=2 These can be added to both flavor and image properties. ✅ A nova-spec should be written to document naming and semantics. #### Dynamic Modification of libvirt Domain XML (Hook Proposal) #### oVirt allows for plugins to alter the libvirt domain XML just before instance launch (via VDSM hooks). Nova does not offer a mechanism to intercept or modify the domain XML, and the design explicitly avoids this. The desired use case involves injecting configuration that libvirt cannot currently represent, for example, enabling multiuser SPICE consoles. ✅ This proposal is explicitly rejected. ✅ Nova will not support hook points for permuting libvirt XML. ✅ Operators may use out-of-band libvirt/qemu hooks at their own risk, but should not expect upstream support or stability guarantees. #### Revisiting the "No More API Proxies" Rule #### Masahito proposed allowing users to filter instances via API based on related service data, such as network_id. ✅ The "no API proxy" rule remains, but with pragmatic exceptions: - Filtering is acceptable if the data exists in Nova’s DB (e.g., network ID, image ID). - No cross-service REST calls allowed (e.g., Neutron QoS types still out of scope). - Filtering by network_id in nova list is reasonable and can proceed. ✅ Masahito will provide a spec. #### OVN Migration & Port Setup Timing #### 📌 Context: https://bugs.launchpad.net/nova/+bug/2073254 In OVN-based deployments, Neutron signals the network-plugged event too early, before the port is fully set up. This causes issues in live migration, especially under load. ✅ Nova already supports waiting on the network-plugged event. OVN in Ubuntu Noble should behave properly. A proposal to improve timing in Neutron was discussed (Neutron to wait for port claim in southbound DB). Nova might support this via a Neutron port hint that triggers tap interface creation earlier during migration (pre-live-migration). ✅ Next step: open an RFE bug in Neutron. If accepted, a Nova spec may be needed. #### Blocking API Threads During Volume Attachments #### 📌 Context: https://bugs.launchpad.net/nova/+bug/1930406 Volume attachment RPC calls block API workers in uWSGI, leading to starvation when multiple attachments are made in parallel. ✅ Volume/interface attachments should become async, reducing API lock contention. Fix is non-trivial and will require a microversion. In the meantime, operators may tune uWSGI workers/threads or serialize attachment calls. #### Inventory Update Failure – DISK_GB Bug #### 📌 Bug: https://bugs.launchpad.net/nova/+bug/2093869 When local storage becomes temporarily unavailable (e.g., Ceph down), Nova sends total=0 for DISK_GB, which Placement rejects if allocations exist. ✅ The real fix is to restore the storage backend. Nova should improve error handling/logging, but should not shut down the compute service. #### Security Group Name Conflict Bug #### 📌 Bug: https://bugs.launchpad.net/nova/+bug/2105896 When multiple security groups share the same name (via Neutron RBAC), instance builds can fail due to incorrect duplicate detection logic. ✅ The issue was fixed in: https://review.opendev.org/c/openstack/nova/+/946079 ✅ Fix will be reviewed and backported to Epoxy. If you've read this far — thank you! 🙏 If you spot any mistakes or missing points, please don't hesitate to let me know. Best regards. René.

2 1

[manila] 2025.2 Flamingo PTG summary
by Carlos Silva 16 Apr '25

16 Apr '25

Hello Zorillas and interested stackers, Last week's PTG had plenty of topics and good takeaways. In case you would like to watch any of the discussions, please take a look at the videos in the OpenStack Manila Youtube channel [0]. The PTG etherpad has all of the notes we took [9]. Here is a summary of the discussions grouped by each topic: Retrospective ========== Highlights ------------- Mid cycle alongside feature proposal freeze provided a good opportunity for us to have collaborative review sessions and move faster on reviews. Two bugsquashes had a good impact on the bug backlog and the bug trend was more positive on this cycle, despite the numbers growing due to low-hanging-fruits we started reporting. Internships with City University of Seattle, Valencia College and North Dakota State University - they are definitely helping with progress on manila-ui and OpenAPI. We will continue the effort. We would like to speed up reviews and improve our metrics [1] on how long changes are open before being merged. Review dashboards can help and we can work with our reviewers to have a more disciplined approach on reviews. Broken third party CI systems currently mean that we have little testing. We need to rely on the authors' or their peers to test and ensure that a feature is working. We will look into documenting CI setup procedures and gather thoughts from maintainers. New API Features should be tested as early as possible to ensure it won't break any workflows. Our contributor documentation will be updated with extra guidelines. AIs: (carloss) Encourage Bug Czar candidates and bring this up more often in the manila weekly meetings (carloss) Encourage spec authors to schedule a meeting to discuss the spec to speed up the review process. (carloss) include iCal with event announcements (bugsquash / mid cycle) (gouthamr) Creating a review dashboard (carloss) Record "expert seminars" on FAQs: it would be great to have some videos documenting how-tos in OpenStack and help people to unblock themselves when they are hitting common openstack-developer issues: https://etherpad.opendev.org/p/manila-howcasts (carloss) communicate a deadline for the manila CLI -> OSC documentation changes. The work with our interns should go until FPF. It needs to be done before the client release, when we are planning to drop the manilaclient support. ashrodri offered help to get it completed after we come to the FPF deadline. (carloss) We should update these docs and mention that first party driver implementations should be done for features and be more strict about the testing requirements. All things CephFS [2] ================ Deprecation of standalone NFS-Ganesha ------------------------------------------------------- We added a warning in Dalmatian, deferred plans to deprecate based on community feedback. Our plan is to remove it in the 2026.1 release. There is a suggested update procedure, please reach out in case there are questions. AI: (carloss) send a reminder email in this cycle to incentivize people to move to clustered NFS Supporting NFSv3 for Windows workloads -------------------------------------------------------- manila-tempest-plugin now supports multiple NFS protocol versions in one of the scenario tests. As soon as we get the build, we will update the CephFS NFS job to run tests for NFSv3 as well. Testing and stabilization -------------------------------- Bumped Ceph version in the CI jobs to Reef in Antelope, Bobcat, Caracal, Dalmatian. We are starting to test with Ceph Squid; we intend to test with Squid on "master" and "stable/2025.1" (epoxy) branches. A couple of Ceph and NFS-Ganesha issues are impacting us at the moment [4] [5] [6] and we managed to find the workaround for some. We needed to stop testing with ingress daemon at the moment and we will get back to testing as soon as the fix is out. Manage unmanage of shares and snapshots ----------------------------------------------------------- Feature is merged and working and we are going to backfill tempest test patches AI: (carloss) will propose a new job variant to allow testing this feature. Plans for 2025.2 Flamingo ----------------------------------- Investigate support for SMB/CIFS Ceph-NFS QoS: we will follow the implementation of this feature in NFS Ganesha and start discussing and drafting the Manila implementation when the code is merged in Ganesha upstream. Out of place restores and backup enhancements [7] ======================================== CERN is pursuing a backup backend with their C-Back tool. Currently Manila backups can be restored back to the same share; there are some problems with such approach when the source share backend is down and to prevent browse by restore behavior. Zachary Goggins (za) proposed a specification, and plans to work on it during the Flamingo Cycle. The share backups feature also needs some enhancements like a get progress and get restore progress actions. Zach plans to make it part of the implementation. We agreed that a backup resource should have a new "state" attribute, instead of only relying on the status in order to have well defined backup states. AI: (za) update the out of place restore spec. Tech debt ======= Container driver failures -------------------------------- The container driver tempest tests are perma-failing right now. We seem to have a problem with RBAC and pre-provisioned tempest credentials. AIs: (carloss) Report a tempest bug to track the issues; (gouthamr) will propose a change to switch back to using dynamic credentials in our testing. DockerHub rate limits ----------------------------- We are only building an image in manila-image-elements. It's more pulls than pushes. Pushes happen very rarely. The kolla team has moved away from DockerHub as well. Zach offered help in case we need another approach for registry. CERN has its own tool. AI: we will look into moving to quay.io "manila" CLI removal ---------------------------- We added the deprecation warning 6 releases ago and we should proceed with the removal. We will need an additional push to update all of our documentation examples and move to keystoneauth. We need more functional test coverage and we should have a hackathon just as we did some years ago. AI: carloss will schedule a hackathon for enabling more tests and send the removal email to openstack-discuss. We are targeting the removal to 2025.2 Flamingo. CI and testing ------------------ ZFSOnLinux job left on jammy: We created a bug for it and we can use it for tracking. IPv6 testing: The BGP software we were using (quagga) is now deprecated and everything was migrated to FRR. We will need help to fix it as unfortunately, things didn't have a 1x1 translation between the libraries. If someone has experience on this, it would be nice to collaborate to get this fixed. API ---- We are going to stop testing the v1 API and stop deploying it on DevStack test jobs. We'll update the install guide as well that we've stopped supporting it. It was deprecated in 2015 ("Liberty" release). That's a good code cleanup opportunity. V2 is an extension of v1 with microversions. If we stop supporting it, who is affected? Mostly people that have automations using it. What's the impact on manila-tempest-plugin? We have v1 and v2 tests. We have a lot of coverage for v2. If you don't have the v1 API in the cloud, the tests refuse to run. We will need to fix it. AIs: Work on the removal patches during the 2025.2 Flamingo release; (carloss) will send an announcement email to the ML, including operators tag. Manila UI ------------- We have been making progress in the Manila UI feature gap. Currently working on manage/unmanage share servers, manage share with dhss=true, filtering user messages on date, updating quotas table. Share limits view broke some time ago, code lives in horizon. We hit some issues using horizon's tox "runserver" environment, apparently more people ran into the same issue. We will talk to other impacted parties and check how to overcome this issue. AI: (carloss) will reach out to the horizon team and ask how we can re-introduce Manila limits to the overview tab. Enable share encryption at-rest (back-end) with secret refs stored on Barbican/Castellan. [8] ===================================================================== We merged a specification some time ago with an implementation architecture. That spec contemplated both Share encryption and Share server encryption. NetApp is now planning to work only on share server encryption. Encryption can be disabled per share, but shares exported via a share server cannot have a separate encryption key on ONTAP. We reached an agreement that when a new share creation is triggered, if there isn't a share server matching the provided key, a new share server will need to be spawned. We also agreed that we should allow using names for the secret reference for better user experience. 2025.2 Flamingo is the target release. AIs: (kpdev/Sai) The spec will be updated and only the DHSS=True scenario will be documented; The manila team will review the spec as soon as it is proposed Replication Improvements ==================== Back when we implemented replication, we didn't account for specific configurations that the storage backends can have, for example whether the backend could support zero RPO technologies or not. Zero RPO is is an important feature that allows data to be written simultaneously between the share and its replicas. We agreed that the way we should send the information to the backend is through a backend specific share type extra spec. Administrators will be able to define it in the share type and the backend will pick it up. Operator concerns / questions ======================= Where to put parameters that change behaviour only of one protocol (NFS in this case)? We agreed that we should have write once type of metadata and not allow the metadata to be updated afterwards. A configuration option can be introduced for this where the operator can determine what metadata will not be updated. AI: carthaca will propose a lite-spec for this Lustre FS Support for HPC Use Cases in OpenStack Is there any possibility for OpenStack to officially integrate or support parallel file systems like Lustre, either through Manila or other components? We've heard in the past as a request from the scientific-sig group. Building a driver should be straightforward and it does not necessarily need to be in-tree, and it would be easier to maintain. This is a very good use case. This discussion will continue with the scientific-sig group. Replica / Snapshot Retention / Expiration Policy While replicas in Manila are designed to be continuously in sync with the active share, certain use cases — such as disaster recovery (DR) replicas or manually created replicas that are no longer needed — could benefit from lifecycle management. Replicas are continuously synced with the source share, so if they're "unused", they're there for some reason is the assumption. We had a spec a while ago about automating snapshots (creation and deletion) on schedule. It would be preferable that an external automation tool is used to achieve such behavior. Maybe openstack/mistral can be a good approach (Support for manila snapshots already exists on Mistral) Affinity/Anti-affinity spec updates ========================= This feature allows users to create share groups with affinity policies, which determine the affinity relationship between shares within the group. There was an open question about strategies of locking. We came to an agreement that we can use tooz, database or oslo. AI: (chuanm) will update the spec. Force deleting subnets ================= This is a feature that follows the ability to add multiple subnets to a share server. We should also be able to remove them. This spec is under review. We agreed that we should also implement the "check" mechanism before deleting the subnet. AIs: (sylvanld) will update the spec Eventlet removal ============= Need to remove wsgi uses, use oslo service's new Threading based backend instead for the ProcessLauncher, periodic tasks. Neutron is doing some work around periodic tasks and we can benefit from their learning. AI: Work on this in Flamingo, aiming for completion in 2026.1 cycle. Manila/Nova Cross-project session: VirtioFS ================================= VirtioFS implementation is now complete and we are looking at the next steps. We currently don't have CI testing the feature and the Manila team is planning to work on it during the 2025.2 Flamingo release. The nova team intends to drive the remaining SDK and OSC patches to completion during the 2025.2 Flamingo release. We also discussed some possible enhancements: mem_fs support, online attach and detach and live migration. These will take some time and the Nova team will work on such features gradually. AIs: (carloss) will share the test scenarios with the Nova team and ask for reviews and the Manila team will work on the implementation of the tests. (rribaud) will work on the remaining SDK patch and work on mem_fd support. [0] https://www.youtube.com/watch?v=MLXkBRhViS0&list=PLnpzT0InFrqADxXi_dtPqfWLt… [1] https://openstack.biterg.io/app/dashboards#/view/Gerrit-Backlog?_g=(filters…:'Gerrit%20Backlog%20panel%20by%20Bitergia. ',filters:!(('$state':(store:appState),meta:(alias:'Changesets%20Only',disabled:!f,index:gerrit,key:type,negate:!f,params:(query:changeset),type:phrase),query:(match:(type:(query:changeset,type:phrase)))),('$state':(store:appState),meta:(alias:Bots,disabled:!f,index:gerrit,key:author_bot,negate:!t,params:(query:!t),type:phrase),query:(match:(author_bot:(query:!t,type:phrase)))),('$state':(store:appState),meta:(alias:!n,disabled:!f,index:gerrit,key:project,negate:!f,params:(query:manila),type:phrase),query:(match_phrase:(project:manila)))),fullScreenMode:!f,options:(darkTheme:!f,useMargins:!t),query:(language:lucene,query:(query_string:(analyze_wildcard:!t,default_field:'*',query:'*',time_zone:Europe%2FMadrid))),timeRestore:!f,title:'Gerrit%20Backlog',viewMode:view) [2] https://etherpad.opendev.org/p/flamingo-ptg-manila-cephfs [3] https://bugs.launchpad.net/manila/+bug/2049538 [4] https://github.com/nfs-ganesha/nfs-ganesha/issues/1227 [5] https://tracker.ceph.com/issues/69214 [6] https://tracker.ceph.com/issues/67323 [7] https://review.opendev.org/c/openstack/manila-specs/+/942694 [8] https://etherpad.opendev.org/p/share-encryption-with-barbican-secret-ref [9] https://etherpad.opendev.org/p/flamingo-ptg-manila Thank you everyone that participated on the PTG! Best regards, carloss

1 0

[trove-dashboard][designate-dashboard] Stuck translation proposal jobs
by Dmitry 16 Apr '25

16 Apr '25

Hello, team. Wanted to bring your attention for stuck translation proposal jobs for both trove-dashboard and designate-dashboard (https://zuul.opendev.org/t/openstack/build/e6849eafd29c4ee78c57fff6a8768ac6 ,https://zuul.opendev.org/t/openstack/build/3489b918e89642a4a607665edd6a5d41) As I have found out this behaviour is caused by jobs running on Ubuntu Focal with Python 3.8. Is there anything can be done to fix this issue? Thanks.

3 2

[barbican] Cancel Weekly Meeting
by Mauricio Harley 16 Apr '25

16 Apr '25

Hello, everyone. Barbican current's PTL here. We need to cancel the weekly meeting that would happen on Monday the 21st. This is necessary since this day will be a public holiday in many countries in Europe. Looking forward to meeting you all on the Monday following: April the 28th. Best regards, Mauricio

1 0

[trove-dashboard][designate-dashboard] Stuck translation proposal jobs
by dcu995＠gmail.com 16 Apr '25

16 Apr '25

Hello, team. Wanted to bring your attention for stuck translation proposal jobs for both trove-dashboard and designate-dashboard (https://zuul.opendev.org/t/openstack/build/e6849eafd29c4ee78c57fff6a8768ac6 ,https://zuul.opendev.org/t/openstack/build/3489b918e89642a4a607665edd6a5d41) As I have found out this behaviour is caused by jobs running on Ubuntu Focal with Python 3.8. Is there anything can be done to fix this issue? Thanks.

1 0

[kolla-ansible][dalmatian]Apply a patch to fix a bug
by Franck VEDEL (UGA) 15 Apr '25

15 Apr '25

Hello, and first sorry for coming back with my problem. After 3 days of trying to resolve it (applying a patch to fix a known bug in Horizon), it's still not working. No changes have been made to the problematic file (workflows.py). First question: This link discusses the topic (« Patching Customization") https://docs.openstack.org/kolla/latest/admin/image-building.html But not in the one for version 2024.2: https://docs.openstack.org/kolla/2024.2/admin/image-building.html So maybe the method doesn't apply to Dalmatian. Second question: what is wrong with what I’m doing: https://review.opendev.org/changes/openstack%2Fhorizon~938238/revisions/1/p… patch Archive ZIP · 409 octets The patch is a zip file We can download it: c2cce40.diff.zip I create the directory : /home/user/PATCH/horizon My /etc/kolla/kolla-build.conf file is these 2 lines [DEFAULT] patches_path = /home/user/PATCH In this directory, we can list files: (I tried with the zip and the unzip file, the diff file) (venv) user1@pc1:~$ ll /home/user/PATCH/horizon/ total 24 drwxrwxr-x 2 user1 user1 4096 avril 14 09:14 ./ drwxrwxr-x 3 user1 user1 4096 avril 11 08:24 ../ -rw-rw-r-- 1 user1 user1 1093 déc. 25 03:01 c2cce40.diff -rw-rw-r-- 1 user1 user1 716 avril 14 09:12 c2cce40.diff.zip -rw-rw-r-- 1 user1 user1 716 avril 14 09:12 c2cce40.zip -rw-rw-r-- 1 user1 user1 13 avril 14 09:14 series The series file (the try with the zip file): (venv) user1@pc1:~$ more /home/user1/PATCH/horizon/series c2cce40.zip I also tried Without the zip extension I modify the file: /home/user/venv/share/kolla-ansible/ansible/roles/horizon/defaults/main.yml #################### # Docker #################### #horizon_image: "{{ docker_registry ~ '/' if docker_registry else '' }}{{ docker_namespace }}/{{ docker_image_name_prefix }}horizon" #horizon_tag: "{{ openstack_tag }}" # #horizon_image_full: "{{ horizon_image }}:{{ horizon_tag }}" horizon_image_full: "kolla/horizon:19.4.0 » The next command create a new docker image (horizon:19.4.0) Kolla-build -b ubuntu horizon No problem… I have a new image named horizon:19.4.0. I copy the image on my second computer (2 nodes in my test cluster) Next: kolla-ansible reconfigure -I multinode Everything works , the new image is used to build horizon containers. But no modification in the file (venv) user1@pc1:~$ docker exec -it horizon bash (horizon)[root@pc1 /]# more ./var/lib/kolla/venv/lib/python3.12/site-packages/openstack_dashboard/dashboards/project/networks/ports/workflows.py class UpdatePortSecurityGroupAction(sg_base.BaseSecurityGroupsAction): def _get_initial_security_groups(self, context): port_id = context.get('port_id', '') port = api.neutron.port_get(self.request, port_id) return port.security_groups No modification on the container, in the workflows.py file. What is wrong ? There's something I'm not doing right, but what? Do you have any ideas? I'm definitely not managing it. Thank you, really, if you have any ideas. Franck

3 3

[neutron] ML2/OVN vs ML2/OVS
by Nguyễn Hữu Khôi 15 Apr '25

15 Apr '25

Hello. I am going to deploy an openstack network for a DC. I would like to have some advice on choosing between them. Could you show me some pros and cons between them? About OVN, I don't see many articles about it. And How can I check traffic routes via which GW, I can check this via ha_state with OVS Thank you very much. Nguyen Huu Khoi

4 8

[heat][ptg][ops] Flamingo PTG summary
by Takashi Kajinami 15 Apr '25

15 Apr '25

Hello, Last week during the PTG the heat team gathered to discuss a few topics. Thank you all who attended the session and the valuable discussions. The details can be found in https://etherpad.opendev.org/p/apr2025-ptg-heat but I'll leave some summary. There are a few plans about which we want to ask for any feedback from operators so I'm adding [ops] tag here. 1. Eventlet removal During the session we reviewed the current global plan to remove/replace eventlet and discussed the plan to follow it in heat. Our current idea is to remove/deprecate unmaintained code first so that we can shrink the scope. At this moment we aim to deprecate and remove the following items. - Standalone heat-api and heat-cfn-api - These are deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. Users can run api server by external server mechanism such as mod_wsgi or uwsgi. - heat-all service - This is deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. We expect this is not really used in production - legacy engine - This was deprecated in favor of convergence. Note that removing this means we no longer support adopt/abandon/check feature. Question to operators: Does anyone have concern about deprecating/removing these items ? Please be aware that the current heat team is quite small and we need actual help to replace eventlet for these features. 2. CFN API We discussed the current status of heat-cfntool which heavily depends on unmaintained boto library. However we also agreed that replacing boto by boto3 requires some effort due to the fact that boto3 does not allow overriding endpoint quite easily. While we aim to deprecate CFN api, we agreed that we still have to asses the impact because CFN API is used for signaling by default. Question to operators: Is anyone using CFN API in any other use case than signaling ? For the first topic, if we don't hear any objections, we'll follow the plan to move the removal work forward. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0