- openstack-discuss - lists.openstack.org

[neutron] Drivers meeting canceled Friday, July 11th
by Brian Haley 10 Jul '25

10 Jul '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is currently nothing listed in the agenda. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[skyline] Request to extend core reviewers team
by Vladimir Kozhukalov 09 Jul '25

09 Jul '25

Hi team, The Skyline project seems to be interesting for many users but the review is slow at the moment. Maybe we could call for more volunteers who are able to spend some of their time for review and extend the project core reviewers team. Opinions are welcome. -- Best regards, Kozhukalov Vladimir

3 2

[neutron] Seeking Advise: Automatic Assignment of Default Neutron QoS Policy in OVN-based OpenStack
by Simon Stephan 09 Jul '25

09 Jul '25

Hi all, we’re currently migrating an OpenStack deployment from a setup using libvirt-based QoS (with per-flavor bandwidth limits) to a newer environment using OVN as the networking backend. In the previous environment, bandwidth limits were enforced via libvirt, and each flavor had an associated QoS configuration. Now with OVN, this approach is no longer viable, and we are evaluating Neutron’s native QoS feature as a replacement. Our goals: * Enforce one default bandwidth limit per project (formerly done via flavor). * Apply a default QoS policy automatically to every new project, without requiring manual intervention. * Allow users to create their own projects via Domain Manager. Current Observations: * Neutron QoS policies must be explicitly associated with ports or networks, and there is no system-wide default or setting it on a domain level * There is no built-in mechanism in Neutron or Keystone to automatically attach a default QoS policy when a new project is created. Our Proposed Solution: We are exploring a solution where we: 1. Listen to project.create events on the RabbitMQ message bus. 2. Automatically assign a shared default QoS policy (defined in our service project and marked as shared=True) to the newly created project. 3. Possibly enforce this via automation, e.g. an event-driven microservice or script that uses openstacksdk. Question to the community: * Has anyone implemented something similar? * Is there an existing feature or plugin to apply a default Neutron QoS policy to all newly created projects or their ports/networks? * Are there better alternatives or architectural considerations we should keep in mind? * Any feedback or suggestions would be greatly appreciated. Regards, Simon

2 1

[Nova] Flavor visibility management
by Masahito Muroi 09 Jul '25

09 Jul '25

Hi Nova team, I wonder there is an official Nova way to manage Flavor's visibility. The is_public flag can manage a flavor is visible to all users or not, but it can't block user to use the flavor. Usecase: - Cloud admin sets up some custom flavor for users, but the custom flavors are not available to all users at beginning. - Cloud user needs to get some approval to use the custom flavor before using the custom flavor. - Cloud system needs to show custom flavor list not approved yet to cloud users. The problem is user can only see flavors which are already gotten approval. If not, they can't see custom flavor's list using flavor list API. It's kind of chicken and egg problem. Flavors being visible to cloud user means the cloud user can create an instance using the visible flavor. best regards, Masahito

2 3

[i18n][infra][horizon] Zanata translation job failures after Python 3.8 deprecation
by Ian Y. Choi 09 Jul '25

09 Jul '25

Hi all, During last week's PTG, the I18n SIG identified Zanata translation job failures for Horizon (and likely related plugins). The root cause appears to be Python 3.8 deprecation on Horizon [1]. Failed jobs have been observed on Zuul [2], and translation proposals were made on Gerrit [3]. Since translation sync on Horizon stable branches is functioning correctly, the error message seems to be related to Python 3.8 deprecation: ERROR: Cannot install -r doc/requirements.txt (line 3) due to conflicting package version dependencies. To address this, I'd like to raise two points: 1/ To resolve the issue, would you support updating translation sync jobs with Bionic-based Zuul jobs by either upgrading to Jammy or modifying the Bionic image to support Python >3.8? 2/ At least me from I18n SIG acknowledges that recognizing these translation job errors was delayed. Moving forward, would it be beneficial to implement periodic (e.g., monthly) reporting on translation job successes and failures? Thank you, /Ian [1] https://docs.openstack.org/releasenotes/horizon/2024.2.html#upgrade-notes [2] https://zuul.opendev.org/t/openstack/builds?job_name=propose-translation-up… [3] https://review.opendev.org/q/owner:proposal-bot+project:openstack/horizon+b…

2 3

Action Required: Renew Your OpenInfra Individual Membership by July 19
by Wes Wilson 08 Jul '25

08 Jul '25

Dear OpenInfra Community, OpenInfra Individual membership is now open and requires your immediate action. Following OpenInfra's integration with the Linux Foundation, all individual members must complete a brief renewal process[1], including agreeing to the OIF Individual Member Program[2] and Community Code of Conduct[3], to maintain their voting rights and board representation under our new governance structure. Why this matters: Only members who complete this process by July 19, 2025 will be eligible to vote in the 2026 Individual Governing Board election. According to the OpenInfra Elections Procedures Policy[4], individual members must become a member at least 180 days before an election to be eligible to vote. Missing this deadline means you will not be able to participate in the 2026 board election. For existing members: Complete the renewal form[1] to maintain your membership status. For new members: This is your opportunity to join as an OIF Individual Member and gain voting rights in the 2026 election. Note: The process takes just a few minutes Log in with your OpenInfraID and confirm the permissions check to view the form OIF Individual membership is completely free This secures your ability to vote in and run for the governing board The 180-day eligibility requirement is firm, so we cannot extend 2026 voting eligibility to anyone who misses the July 19 cutoff. This would compromise the integrity of our 2026 board election process. If you miss this cutoff, you will be able to vote in elections beyond 2026 assuming you maintain eligibility. Your participation has always been vital to OpenInfra's mission. As we enter this new chapter with the Linux Foundation, we need engaged individual members more than ever to help shape the future of open infrastructure. Feel free to reply to this email with any questions or reach out to me (wes(a)openinfra.dev) Thierry (thierry(a)openinfra.dev) or Jonathan (jonathan(a)openinfra.dev) directly. Thank you for your continued participation in the OpenInfra Foundation! Regards, Wes Wilson Chief of Staff OpenInfra Foundation [1] https://openinfra.org/a/renew-membership [2] https://openinfra.org/legal/oif-individual-member-program [3] https://openinfra.org/legal/code-of-conduct [4] https://openinfra.org/legal/election-procedures-policy

1 0

Ceilometer-Container (Kolla-Ansible) dauerhaft unhealthy – veraltete Komponenten
by M P 08 Jul '25

08 Jul '25

Hallo zusammen, wir betreiben ein OpenStack-Setup mit Kolla-Ansible (Ubuntu 22.04, aktuelle Kolla-Master-Images) und beobachten dabei regelmäßig, dass der ceilometer_compute-Container in einen dauerhaft unhealthy-Status fällt. Wir haben versucht, dem Problem über die Logs auf den Grund zu gehen – konnten aber bisher keinen klaren Fehler identifizieren, der das Verhalten erklärt. Der Dienst startet zwar scheinbar normal, bleibt aber aus Sicht von Docker dauerhaft „unhealthy“. *Frage in die Runde:* Könnte das Verhalten damit zusammenhängen, dass Teile von Ceilometer mittlerweile deprecated oder nicht mehr aktiv gepflegt sind (z. B. die Ceilometer API oder bestimmte Agenten)? Oder gibt es bekannte Probleme mit Ceilometer in neueren Kolla-Versionen? Über Rückmeldungen oder Hinweise, wie ihr mit Ceilometer im aktuellen Kolla/OpenStack-Umfeld umgeht, würden wir uns freuen. Viele Grüße Mai-Anh ------------------------- Hi everyone, We're running an OpenStack environment with Kolla-Ansible (Ubuntu 22.04, latest Kolla master images), and we’ve been seeing the ceilometer_compute container frequently stuck in a permanently unhealthy state. We've tried investigating through the logs, but haven’t been able to pinpoint a clear cause. The service appears to start normally, but Docker continues to report it as unhealthy. *Question:* Could this be related to the fact that parts of Ceilometer are now deprecated or no longer actively maintained (e.g., the Ceilometer API or specific agents)? Or are there known issues with Ceilometer in recent Kolla/OpenStack releases? We’d appreciate any insights or suggestions — especially regarding how others are handling Ceilometer in current setups. Best regards, Mai-Anh

1 0

[cinder] not rescanning during VM attach
by Anthony Galica 08 Jul '25

08 Jul '25

Hi all, We have a customer problem where LUNs are not able to be scanned in time by cinder, so the operation fails. We fixed the problem in the "create image from volume workflow" by configuring "num_volume_device_scan_tries" in cinder.conf to a larger value. However, this doesn't appear to work for creating a VM and attaching to it, which still always fails. Any configuration or advice here? Thank you, Anthony

2 1

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

07 Jul '25

Hello Stackers, We're officially in the second half of the OpenStack 2025.2 "Flamingo" release cycle [1]. Starting on 2025-08-06, election officials will begin merging nominations for Project Team Leads for the 2026.1 release cycle and to fill four seats on the OpenStack Technical Committee. If you're interested in leading a project or joining the OpenStack TC, I'd encourage you to submit a nomination through the openstack/election repository [2]. The Call for Proposals soliciting project team updates and Forum sessions at the OpenInfra Summit (17–19 October 2025) in Paris-Saclay will be closing on 2025-07-08 at 23:45 PST [3]. The schedule for the event is live and contains some exciting material [4]. In the past week, the OpenStack Technical Committee didn't merge any significant governance changes. However, some proposals are open for the community's review. === Weekly Meeting === The last weekly meeting of the OpenStack TC was held simultaneously on Video (Meetpad) and IRC (OFTC's #openstack-tc channel) on 2025-07-01. The recording of the meeting was posted to the TC's YouTube channel [5], and meeting notes were logged on IRC [6]. The meeting was brief yet efficient, covering updates on various ongoing initiatives. TC members were glad to see the smooth implementation of the Developer Certificate of Origin (DCO) enforcement, with minimal issues reported and proactive steps taken to manage tooling changes. Key action items from the previous week, such as addressing inactive projects and the Eventlet deprecation, were discussed. We noted progress on Cyborg's potential revitalization through new and returning maintainers. We discussed the critical and impending bug in PBR [7] due to upstream changes in Setuptools. The OpenStack user survey remains open until August [8], and the TC would like broader community participation. Lastly, we made plans for a "meet-and-greet" forum session with the OpenStack TC at the upcoming summit. This would be a valuable opportunity for community engagement and discussion of TC responsibilities. We do hope to have at least half of the current TC at the summit. The next meeting of the OpenStack TC is on 2025-07-07, and will be hosted on the #openstack-tc channel on OFTC at 1700 UTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us there! === Governance Proposals === ==== Merged ==== - Remove mentions of CLA in licensing guide | https://review.opendev.org/c/openstack/governance/+/953843 ==== Open for review ==== - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Add service-types-authority to SDK deliverables | https://review.opendev.org/c/openstack/governance/+/953548 - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ 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] Submit a PTL/TC candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [3] CFP for Forums/Project Updates: https://cfp.openstack.org/app/2025summit [4] OpenInfra Summit Schedule: https://summit2025.openinfra.org/a/schedule [5] TC Meeting Video Recording, 2025-07-01: https://youtu.be/eJ03g0w8Ers [6] TC Meeting IRC Log 2025-07-01: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-01-17.00.html [7] pbr setuptools incompatibility: https://bugs.launchpad.net/pbr/+bug/2107732 [8] Take the OpenStack user survey: https://www.openstack.org/user-survey [9] TC Meeting Agenda, 2025-07-08: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

enabling compress live migration
by Jiatong Shen 07 Jul '25

07 Jul '25

Hello fellows, I am doing some research on accelerating live migration speed for some memory heavy workload, for example databases. Instances running these applications usually have large amounts of ram and high dirty page rate. Compute nodes are equipped with ten-gigabit NICs. We found it is very hard to complete the migration in 30 mins and we have to use force-complete in the end. I found some material saying enabling compression could boost migration speed and would like to try out. So how can I enable compress live migration and are there other suggestions? Thank you very much for the help. -- Best Regards, Jiatong Shen

3 2