- openstack-discuss - lists.openstack.org

[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

[cinder][glance][telemetry][barbican] Deliverables defined in governance but not released yet
by Thierry Carrez 07 Jul '25

07 Jul '25

Hi everyone, The release team latest consistency check revealed a number of deliverables that are defined in the openstack/governance repository but do not have a deliverable file in the openstack/releases repository yet. [cinder] rbd-iscsi-client has been added Jan 2021, never released yet. Should it be removed from governance at some point? [glance] os-test-images has been added July 2024, never released yet. Is it a repository that is not meant to be "released" ? If yes, we can mark it "release-management: none" in governance to avoid flagging it. [telemetry] aetos and grian-ui have been recently added (April, 2025). Do you plan to release them as part of the Flamingo release? If yes we should add deliverable files for them in openstack/releases. [barbican] barbican-ui has been added Oct 2019, never released yet. Should it be removed from governance at some point? Thanks in advance for your answers! -- Thierry Carrez (ttx)

2 1

[neutron] Bug Deputy report Jun 30 - Jul 7
by Oleg Bondarev 07 Jul '25

07 Jul '25

Hello Neutron Team, Bug report for the week of June 30 is below: High: ----- - https://bugs.launchpad.net/neutron/+bug/2115629 - mariadb and centos 9 stream mysql tempest and functional jobs failing - Fix Released: https://review.opendev.org/c/openstack/neutron/+/953768 Medium: ------- - https://bugs.launchpad.net/neutron/+bug/2115776 - Neutron fails to delete records for a VM or FIP when there is A and AAAA records with the same name - Triaged - Unassigned Low: ---- - https://bugs.launchpad.net/neutron/+bug/2115878 - [doc] Document how to manually spawn a WSGI process for debugging purposes - Confirmed - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2115952 - [OVN][QoS] Allow max-bw only QoS policies to use the OVN policer - In progress: https://review.opendev.org/c/openstack/neutron/+/954137 - assigned to Rodolfo Alonso Undecided: ---------- - https://bugs.launchpad.net/neutron/+bug/2115768 - Mellanox Technologies MT2892 Family [ConnectX-6 Dx] SRIOV using Openstack - No IP inside the VM - Incomplete Thanks, Oleg

1 0

[skyline] Skyline appends v3 in the RC file
by Joao Antonio 07 Jul '25

07 Jul '25

2 3

[skyline] Administrator Page not available for an admin user in another domain
by Joao Antonio 05 Jul '25

05 Jul '25

Hello, When I access skyline using admin@Default I'm able to access the Administrator Page. When I access skyline using taikun@taikun I'm not able to access the Administrator Page. Some idea why? openstack domain show taikun +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | id | ab2384baf3cc43f7ae1fda0ce7e6ae71 | | name | taikun | | enabled | True | | description | None | | options | {} | +-------------+----------------------------------+ openstack project list --domain taikun +----------------------------------+-----------+ | ID | Name | +----------------------------------+-----------+ | 02c534188ec74a3a89ec530b6d224249 | taikun | +----------------------------------+-----------+ openstack user list --domain taikun +----------------------------------+--------+ | ID | Name | +----------------------------------+--------+ | 659c6b30bbc54f32a7e90b63d92a9d9d | taikun | +----------------------------------+--------+ openstack role add --project taikun --user taikun --project-domain taikun --user-domain taikun admin openstack role assignment list --project taikun --project-domain taikun --names --effective --user taikun --user-domain taikun +---------+---------------+-------+---------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +---------+---------------+-------+---------------+--------+--------+-----------+ | admin | taikun@taikun | | taikun@taikun | | | False | | manager | taikun@taikun | | taikun@taikun | | | False | | member | taikun@taikun | | taikun@taikun | | | False | | reader | taikun@taikun | | taikun@taikun | | | False | +---------+---------------+-------+---------------+--------+--------+-----------+ openstack role assignment list --project taikun --project-domain taikun +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | abeef1135b254247b3ed7e82d67a74ff | 659c6b30bbc54f32a7e90b63d92a9d9d | | 02c534188ec74a3a89ec530b6d224249 | | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ openstack role list +----------------------------------+-------------------------------+ | ID | Name | +----------------------------------+-------------------------------+ | 030aa5e0f28a4e229469478d4bc3a041 | heat_stack_user | | 12c79c14d89a4d9bae40f57f7334430f | load-balancer_observer | | 58f7e34845f946b99d02ad8ceafeabe5 | service | | 6ad502b80f8146fa8bf84ea46ad4f279 | load-balancer_global_observer | | 8176fa996c014ced9ac93e057712baa4 | reader | | 9a61d8d430c944b2b95a3773b472347d | member | | 9babd66862fc4df8922c88311640fee6 | load-balancer_quota_admin | | abeef1135b254247b3ed7e82d67a74ff | admin | | b06622b5167d4f5ca1c08f63f6da3be4 | load-balancer_member | | eb3cf02635894e5d8f80cfc93398520e | load-balancer_admin | | fd01d0c357b64d3da37dd482d80d14f7 | manager | +----------------------------------+-------------------------------+ openstack role assignment list --project admin --project-domain Default --names --effective --user admin --user-domain Default +---------+---------------+-------+---------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +---------+---------------+-------+---------------+--------+--------+-----------+ | admin | admin@Default | | admin@Default | | | False | | manager | admin@Default | | admin@Default | | | False | | member | admin@Default | | admin@Default | | | False | | reader | admin@Default | | admin@Default | | | False | +---------+---------------+-------+---------------+--------+--------+-----------+ openstack role assignment list --project admin --project-domain Default +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | abeef1135b254247b3ed7e82d67a74ff | 4eabf78b22254a7f99a34a02c09bd45e | | 0667c5c9c4da4584815880d94f649524 | | | False | | abeef1135b254247b3ed7e82d67a74ff | 659c6b30bbc54f32a7e90b63d92a9d9d | | 0667c5c9c4da4584815880d94f649524 | | | False | | abeef1135b254247b3ed7e82d67a74ff | 659c6b30bbc54f32a7e90b63d92a9d9d | | 0667c5c9c4da4584815880d94f649524 | | | True | | abeef1135b254247b3ed7e82d67a74ff | c2d61ab27c6a4563bb96fa549eae2ee8 | | 0667c5c9c4da4584815880d94f649524 | | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+

3 5

[release] Release countdown for week R-12
by Thierry Carrez 04 Jul '25

04 Jul '25

Development Focus ----------------- We are now past the flamingo-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 21, 2025). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (August 28, 2025) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, August 28, 2025. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September 12, 2025) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (September 26, 2025) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 21, 2025 (R-6 week) Client library freeze: August 28, 2025 (R-5 week) Flamingo-3 milestone: August 28, 2025 (R-5 week) Final 2025.2 "Flamingo" release: October 1st, 2025 OpenInfra Summit Europe: October 17-19, 2025 -- Thierry Carrez (ttx)

1 0

[neutron][octavia] vip port missing virtual-parent in ovn
by Maximilian Stinsky-Damke 03 Jul '25

03 Jul '25

Greetings, I'm currently debugging a strange issue related to Octavia loadbalancer failovers and was wondering if anyone has encountered something similar or has any insights. We're running Neutron with ML2/OVN and the ovn-bgp-agent. When we create Octavia load balancers using the Amphora driver, they come up fine. After attaching a floating IP, the ovn-bgp-agent correctly announces the FIP. However, during load balancer failovers, we sometimes observe that the FIP is no longer being announced. After some debugging, we found that the ovn-bgp-agent stops announcing the FIP because the VIP port in OVN is down and no longer has a neutron:host_id set in external_ids. Digging deeper, we noticed that the VIP port's options:virtual-parents only includes a single port ID and it's not the one corresponding to the current VRRP master. As a result, OVN doesn't associate the VIP with the active amphora, causing the port to be up=false and leaving the external_ids:neutron:host_id field empty. Because of this, no bgp-agent sees itself as responsible for announcing the FIP. Looking at the Octavia amphora ports in Neutron, all of them have the correct allowed address pairs set. This should normally result in the correct virtual-parents being reflected in OVN. Interestingly, I was able to reproduce this behavior even with the SINGLE topology in Octavia, a failover sometimes removes the entire options fields related to virtual-parents and virtual-ip from the VIP port. Manually unsetting and re-setting the allowed address pair on the affected port always restores the correct virtual-parents, and the announcement resumes. Now the question is how could this happen? It seems completely random, but it's very reproducible in my environment. We're running Neutron 2025.1 (26.0.0) with OVN 24.03.1-5.el9. I haven't found any errors in the Neutron server logs indicating issues writing to OVN, or any relevant tracebacks. Thanks in advance for any input or ideas! Best regards, Max

2 3

[cinder] How to retype while maintaining volume usage
by Yuta Kambe (Fujitsu) 02 Jul '25

02 Jul '25

Hi everyone, We are using a Ceph cluster as the backend for Cinder. The Ceph cluster has two pools: volumes_data_hdd for HDDs and volumes_data_ssd for SSDs. These are assigned to the Cinder volume types ceph-hdd and ceph-ssd, respectively. To change the type of a ceph-hdd volume to ceph-ssd, I executed the following command: openstack volume set --type ceph-ssd --retype-policy on-demand <ID of ceph-hdd volume> After execution, checking the capacity with the 'ceph df' command shows an increase in usage after the type change. The following is an example of migrating a newly created, empty 10GB ceph-hdd type volume to ceph-ssd: $ sudo ceph df | grep volumes_data volumes_data_hdd 19 1 98 GiB 25.51k 195 GiB 2.24 4.2 TiB volumes_data_ssd 22 1 91 GiB 23.89k 181 GiB 3.55 2.4 TiB $ openstack volume list --long | grep 7fd16e56-71ec-430b-8499-8d216a57f1c6 | 7fd16e56-71ec-430b-8499-8d216a57f1c6 | test | available | 10 | ceph-hdd | false | | | $ openstack volume set --type ceph-ssd --retype-policy on-demand 7fd16e56-71ec-430b-8499-8d216a57f1c6 $ openstack volume list --long | grep 7fd16e56-71ec-430b-8499-8d216a57f1c6 | 7fd16e56-71ec-430b-8499-8d216a57f1c6 | test | available | 10 | ceph-ssd | false | | | $ sudo ceph df | grep volumes_data volumes_data_hdd 19 1 98 GiB 25.51k 195 GiB 2.24 4.2 TiB volumes_data_ssd 22 1 101 GiB 26.45k 201 GiB 3.95 2.4 TiB Despite the volume being empty, the usage of volumes_data_ssd increases by 10GB. I suspect this is due to zero-filling of unused space during the copy process. Is it possible to change the volume type using Cinder functionality while maintaining the same usage? If not, I think it would be better to use the 'rbd cp' command internally for type changes within Ceph, as it should be able to copy the image while preserving the image size. What are your thoughts on this approach? OpenStack and Ceph versions are: $ ceph -v ceph version 17.2.8 (f817ceb7f187defb1d021d6328fa833eb8e943b3) quincy (stable) $ dnf list --installed | grep openstack-cinder openstack-cinder.noarch 1:21.3.2-1.el9s @centos-openstack-zed Best regards,

2 1

[publiccloud-sig] Next meeting of Public Cloud SIG - July 2nd (today) at 0700 UTC
by Felix Kronlage-Dammers 01 Jul '25

01 Jul '25

Hi everyone, This upcoming Wednesday (which is today, July 2nd) 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 See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG Sorry for the short notice! Have fun! 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

[Nova] - Upgrading to Epoxy causes Ubuntu cloud images to fail DHCP
by Karl Kloppenborg 01 Jul '25

01 Jul '25

Hi Team, We’ve got a weird one where other images (cirros, Debian, fedora etc) work fine. However upgrading to Nova Epoxy ubuntu fails cloud-init because network timed out. Note network loads fine and DHCP is received on cirros etc and setting config-drive for the installation Ubuntu works, and continues to work. It smells of some driver issue/change but I haven’t put my finger on it yet. Boot log: https://gist.github.com/inventionlabsSydney/3d491bb08ea96d1f32ed16fd6b58179a Image was uploaded as such: openstack image create --file ~/noble-server-cloudimg-amd64.img --disk-format qcow2 \ --min-disk 8 \ --min-ram 1024 \ --public \ --property hw_firmware_type=uefi \ --property hw_disk_bus=scsi \ --property hw_scsi_model=virtio-scsi \ --property hw_machine_type=pc-q35-focal-hpb ’Noble Test' Has anyone else seen this yet? Karl Kloppenborg Chief Technology Officer m: +61 437 239 565 resetdata.com<https://resetdata.com/> [cid:reset_69557fc2-1d63-4932-b5fd-93bd4f39ca7b.png] ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting For more information on the phasing of these requirements for business please visit; https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…<https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…> This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact(a)resetdata.com.au<mailto:contact@resetdata.com.au>

1 0

Error Occurred After Multipath Configuration
by jiwooo.oh＠samsung.com 01 Jul '25

01 Jul '25

After setting up multipath on netapp, errors occur frequently when detaching a volume. Unexpected error while running command. Command: multipath -f 3600a098038314e7a4b24577351787462 Exit code: 1 Stderr: map in use' This occurs when executing the multipath -f command, and a 'map in use' error occurs. [Full error log] 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Traceback (most recent call last): 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/block_device.py", line 413, in driver_detach 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] virt_driver.detach_volume(context, connection_info, instance, mp, 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/driver.py", line 2860, in detach_volume 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] self._disconnect_volume(context, connection_info, instance, 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/driver.py", line 2099, in _disconnect_volume 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] vol_driver.disconnect_volume( 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/volume/iscsi.py", line 74, in disconnect_volume 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] self.connector.disconnect_volume( 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/utils.py", line 174, in trace_logging_wrapper 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] return f(*args, **kwargs) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/initiator/connectors/base.py", line 78, in inner 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] return f(*args, **kwargs) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/utils.py", line 415, in change_encrypted 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] res = func(**call_args) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/initiator/connectors/iscsi.py", line 894, in disconnect_volume 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] return self._cleanup_connection(connection_properties, force=force, 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/initiator/connectors/iscsi.py", line 948, in _cleanup_connection 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] multipath_name = self._linuxscsi.remove_connection( 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/initiator/linuxscsi.py", line 382, in remove_connection 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] self.flush_multipath_device(multipath_name) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/initiator/linuxscsi.py", line 450, in flush_multipath_device 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] self._execute('multipath', '-f', device_map_name, run_as_root=True, 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/executor.py", line 55, in _execute 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] result = self.__execute(*args, **kwargs) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/os_brick/privileged/rootwrap.py", line 172, in execute 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] return execute_root(*cmd, **kwargs) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_privsep/priv_context.py", line 271, in _wrap 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] return self.channel.remote_call(name, args, kwargs, 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_privsep/daemon.py", line 215, in remote_call 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] raise exc_type(*result[2]) 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266]oslo_concurrency.processutils.ProcessExecutiON-ERROR: Unexpected error while running command. Jun 4, 2025 @ 05:08:04.928 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Jun 4, 2025 @ 05:08:04.928 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Stderr: '9203485.810915 | 3600a098038315143433f58706d524b7a: map in use\n' Jun 4, 2025 @ 05:08:04.928 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Stdout: '' Jun 4, 2025 @ 05:08:04.928 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Exit code: 1 Jun 4, 2025 @ 05:08:04.928 1487897 ERROR nova.virt.block_device [instance: 402cec31-5d7e-4167-b057-09675dcf4266] Command: multipath -f 3600a098038315143433f58706d524b7a [Related config] use_multipath_for_image_xfer: true netapp_lun_space_reservation: disabled image_volume_cache_enabled: true image_volume_cache_max_size_gb: 0 image_volume_cache_max_count: 50 [Error Occurrence Case] - Create volume with image - Volume detach - Stop then start operation - vm resize Is there a solution to this situation?

1 0

[heat][ops] Removal of standalone api services (heat-api and heat-cfn-api)
by Takashi Kajinami 01 Jul '25

01 Jul '25

Hello, Historically heat has provided two methods to deploy api services (native heat api and heat CFN api). 1. standalone script based on eventlet 2. wsgi application run by server framework like apache or uwsgi Now the heat team is trying to get rid of eventlet following the global effort to replace it, and the current blocker is 1 because we have no good alternative to re-implement the standaloe service. The global migration strategy is to remove standalone api services using eventlet and provide only wsgi application. So I'm now sending an email to ask for any input, in case if any operator has concern about our current plan below. - Backport deprecation of standalone api scripts to 2025.1 - Remove these scripts during 2025.2 This means that any operators should use 3rd party server framework like uwsgi and apache+mod_wsgi to run heat api from 2025.2 . I understand backporting deprecation is something we won't accept usually, but I've seen this pattern was done in the past for a few exceptions like Hyper-V support removal. If we hear no objections/concerns for a week then, we aim to merge the removal during this cycle. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 1

[dev][tc] Replacing CLA enforcement with DCO enforcement
by Jeremy Stanley 30 Jun '25

30 Jun '25

As previously discussed[*], tomorrow (2025-07-01) I'll merge a change[**] switching Gerrit to start requiring Signed-off-by in commit messages when pushing new changes or revisions to changes in OpenStack repositories (existing changes don't need to be amended in order to merge; only when revising, rebasing or backporting to other branches). Agreeing to the OpenInfra ICLA will no longer be necessary. The OpenStack Contributor Guide has already been updated to reflect this[***]. After this update merges, when attempting to push or alter a change's content you may receive an error (from git review/git push at the command line or from the Gerrit WebUI if you're trying to edit a change there) notifying you that you're missing a Signed-off-by trailer in your commit message. You can either add one with git's -s option like... git commit -s (to add when making a new commit) git commit --amend -s (when altering an existing commit) ...or by directly editing the commit message to include a line at the end with your address such as... Signed-off-by: Jeremy Stanley <fungi(a)yuggoth.org> Keep in mind that if you're pushing a series of changes, you may need to update all their commit messages, e.g. through an interactive rebase. If anyone has questions, please don't hesitate to ask! [*] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [**] https://review.opendev.org/950998 [***] https://docs.openstack.org/contributors/common/dco.html -- Jeremy Stanley

1 0

[openstack]Share about OSS which used for my Openstack
by Nguyễn Hữu Khôi 30 Jun '25

30 Jun '25

Hello, I would like to share some open-source software (OSS) that I used for my OpenStack environment. https://github.com/nguyenhuukhoi/openstack-note/blob/main/Cloud%20System%20… I hope this will be helpful for you, especially those who are getting started with OpenStack. Nguyen Huu Khoi

3 4

Re: [openstack]Share about OSS which used for my Openstack
by Nguyễn Hữu Khôi 30 Jun '25

30 Jun '25

Hello, My Openstack system is on bare metal nodes. Nguyen Huu Khoi On Mon, Jun 30, 2025 at 9:01 PM Winicius Allan <winiciusab12(a)gmail.com> wrote: > So do you have a controller baremetal that you create virtual machines on > top of it to use as controller nodes? > > Regards. > > On Mon, Jun 30, 2025, 10:40 Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> > wrote: > >> Hello, >> >> I would like to share some open-source software (OSS) that I used for my >> OpenStack environment. >> >> >> https://github.com/nguyenhuukhoi/openstack-note/blob/main/Cloud%20System%20… >> >> >> I hope this will be helpful for you, especially those who are getting >> started with OpenStack. >> Nguyen Huu Khoi >> >

1 0

[oslo][mistral][keystone] broken library gate
by Elõd Illés 30 Jun '25

30 Jun '25

Hi teams in $SUBJECT, The release team usually checks the gate health of libraries which did not have merged patches recently and it seems you have a project with broken gate: oslo.utils: https://review.opendev.org/c/openstack/oslo.utils/+/952914 python-mistralclient: https://review.opendev.org/c/openstack/python-mistralclient/+/952927 python-keystoneclient: https://review.opendev.org/c/openstack/python-keystoneclient/+/952923 Could you please check and fix the gate so that we don't release 2025.2 Flamingo with a broken state. Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

3 2

[keystone][horizon] OPENSTACK_KEYSTONE_DOMAIN_DROPDOWN security impact
by Pierre Riteau 30 Jun '25

30 Jun '25

Hello, The documentation for the OPENSTACK_KEYSTONE_DOMAIN_DROPDOWN option in Horizon [1] has this warning: > It is strongly advised NOT to enable this for public clouds, as advertising enabled domains to unauthenticated customers irresponsibly exposes private information. This should only be used for private clouds where the dashboard sits behind a corporate firewall. In a context where this option enables one or multiple domains that would be publicly documented anyway, is there really any issue with using this option on a publicly-accessible Horizon deployment? Thanks, Pierre Riteau (priteau) [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#opens…

1 0

"tag" API in OpenStack, case sensitive
by Rodolfo Alonso Hernandez 30 Jun '25

30 Jun '25

Hello all: I initially found this issue in Neutron [1] but it seems to be more of an OpenStack wide problem. In Neutron, when you try to create a tag with different case (upper, lower), the API fails: $ openstack port create --network private port_tags $ openstack port set --tag tag1 port_tags $ openstack port set --tag TAG1 port_tags # this command will fail with the following message: ConflictException: 409: Client Error for url: http://192.168.10.100/networking/v2.0/ports/21788aea-98b7-4606-bcf4-5f963ce…, Failed to create a duplicate Tag: for attribute(s) ['tags.PRIMARY'] with value(s) 47-TAG1 That happens because in Neutron we don't sanitize the input "tags" and we consider that "tag1" is different to "Tag1", as recommended by [2]: "Tags are case sensitive". But checking the table definitions in OpenStack (for example [3][4][5]), all projects seem to have the same problem: we define the tuple (resource, tag) as the primary key. But if we use a case insensitive table collation (for example "utf8_general_ci" or "utf8mb3_general_ci"), the comparison between "tag1" and "TAG1" will match. In the Neutron API, because we don't consider this scenario, the API raises the mentioned exception. In Nova, for example, the command succeeds but the new tag is not added. So the question here is: * Do we change the API definition to make it case insensitive? That will need, most probably, to revisit all stored tags and convert them to lower case. It will also require sanitizing the API input and making all tags lower case. * Do we enforce a charset and collation case sensitive for these specific tables? Regards. [1]https://bugs.launchpad.net/neutron/+bug/2114819 [2] https://specs.openstack.org/openstack/api-wg/guidelines/tags.html#tags-rest… [3] https://github.com/openstack/neutron/blob/39b183645e071f9c2926f0bd870723fb6… [4] https://github.com/openstack/nova/blob/64ca204c9cf497b0dcfff2d3a24b0dd795a5… [5] https://github.com/openstack/octavia/blob/2fb6ba9343e39f60f058a781afd14b906…

2 1

nova-ovs-hybrid-plug CI jobs failing for Nova
by Michael Still 30 Jun '25

30 Jun '25

Hi, over the weekend it appears that nova-ovs-hybrid-plug CI jobs have been failing for Nova, I think because of this error: "Failed to contact the endpoint at https://200.225.47.11/image for discovery. Fallback to using that endpoint as the base url." https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90 is an example of such a failure. The CI job then executes: openstack --os-compute-api-version 2.74 server create --image --flavor --nic net-id= --host np0041269081 --wait evacuate-test Which is invalid because it doesn't have an argument to the --image flag. I am unsure who owns 200.225.47.11. Is it possible its offline? Thanks, Michael

3 3

[neutron] Bug deputy report for week 26 of 2025 (June 23th)
by Lajos Katona 30 Jun '25

30 Jun '25

Hi Neutrinos! Last week (week 26, from 23 june) I was the Neutron bug deputy, please check the report for that week. * *Unassigned*: ** https://bugs.launchpad.net/neutron/+bug/2115411 ([ovn-octavia-provider] Exception observe when there no IP available for VIP ): TL;DR: shall we throw http500 or 409 when there's no available IP. ** https://bugs.launchpad.net/neutron/+bug/2115241 (test_spawn_rate_limited_metadata_proxy unit test fails randomly ) ** High Bugs* ** https://bugs.launchpad.net/neutron/+bug/2115327 ([fullstack] Migrate the fullstack tests to other FWs ) ** Medium Bugs* ** https://bugs.launchpad.net/neutron/+bug/2115184 ([S-RBAC] Custom role can't get resources which belongs to different projects ) Owner: Slaweq ** https://bugs.launchpad.net/neutron/+bug/2115189 ( [OVN] ``sync_port_qos_policies`` and ``sync_fip_qos_policies`` only have "repair" mode), owner: Rodolfo, https://review.opendev.org/c/openstack/neutron/+/953081 ** https://bugs.launchpad.net/neutron/+bug/2115242 ([FT] Random errors in ``test_floatingip_mac_bindings``), owner: Rodolfo, https://review.opendev.org/q/Ia153b48aaec72e6a073b313ef2aea8efac6dbbae ** https://bugs.launchpad.net/neutron/+bug/2115510 ([neutron][os-ken] Bug on the BGP loop prevention), assigned: Anas Jouhdy, https://review.opendev.org/c/openstack/os-ken/+/953631 Best wishes, Lajos Katona (lajoskatona)

1 0

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

29 Jun '25

Hello Stackers, We're thirteen weeks away from the coordinated release of OpenStack 2025.2 "Flamingo" [1]. This Thursday marks Milestone-2 of the release cycle. This is a bug-targeting milestone for OpenStack project teams, as well as a checkpoint for the OpenStack Release Management team to line up deliverables that will be part of the coordinated release at the end of this development cycle. Currently, the number of deliverables to be released has only changed slightly from the OpenStack 2025.1 release. No significant deliverables have been deprecated or removed. In the past week, the OpenStack Technical Committee did not make any new governance changes; however, several proposals are under the community's review. Most significantly, today (2025-06-30) marks the end of the OpenStack Contributor License Agreement (CLA). The CLA was adopted in July 2010 (do you feel old yet?) [2], and thousands of contributors have signed it. However, for over a decade, we've felt encumbered by how it was arcane, perceived to be more permissive than Apache v2 and caused friction with individuals and organizations. We believe it has limited contributor involvement. Today, we join several other open source projects in requiring the "Developer Certificate of Origin" as a way to sign off your contributions. As we close the lid on the CLA regime, you'll need to "git commit -s" each of your contributions from 2025-07-01 to adhere to the DCO [3][4]. We do anticipate hiccups and request your cooperation in ironing out any issues in the code review system and contributor tooling during this transition. If you notice something broken, please chime in on this mailing list or on OFTC's #opendev channel. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on 2025-06-24 [5]. The meeting was well attended and covered several topics. The proposal to mark the Cyborg project as inactive [6] was withdrawn after critical CI fixes were merged. While activity has resumed for this cycle, there are concerns about the project’s long-term maintenance, particularly in light of future OpenStack-wide changes like eventlet removal and dependency updates. It was opined that Cyborg is not "feature complete" and must stay responsive to ongoing ecosystem changes, even if its core functionality appears stable. The upcoming cycle's elections will serve as a checkpoint to reassess the project’s trajectory and whether new maintainers need onboarding. We then discussed the timeline of the ongoing effort to phase out eventlet. A new governance patch [7] proposes a timeline that aligns with operator and distro expectations, especially in light of Python 3.13 adoption. Python 3.12 will continue to be a fallback for some time, but when supporting Python 3.13, we hope not to depend on eventlet across the board. The TC emphasized that continued discussion on the Gerrit change is necessary to finalize acceptable timelines. The next major topic concerned setuptools changes that will impact PBR (Python Build Reasonableness). Setuptools will remove "ScriptWriter" and "pkg_resources" by October 31, 2025. These removals break current functionality in PBR and could jeopardize CI and release workflows. A critical bug was reported against PBR by maintainers of setuptools [8]. The TC discussed options ranging from vendoring replacements to rewriting PBR logic or adopting upstream tools despite performance tradeoffs. A key concern is that PBR’s CI is currently broken and must be fixed before any meaningful changes can be implemented. We'd like to seek a volunteer to resolve this issue. Please chime in on OFTC's #openstack-tc or #openstack-oslo if you're keen to help with this. In closing, we discussed the OpenInfra Summit 2025 CFP for Forum Sessions and Project Updates. CFP submissions must be made before 23:45 PST on 2025-07-08 [9]. The next meeting of the OpenStack Technical Committee will be held on 2025-07-01 at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. You're welcome to join whichever platform you prefer. The Meetpad session will be recorded, and the recording will be shared on the TC's YouTube channel [10]. Please find the agenda and joining information on the meeting's wiki page [11]. I hope you'll be able to join us there. === Governance Proposals === ==== Open for review ==== - 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-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ 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 and its CLA: https://wiki.openstack.org/wiki/OpenStackAndItsCLA [3] OpenStack will replace CLA with DCO: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [4] OpenStack Contributor Guide to DCO: https://docs.openstack.org/contributors/common/dco.html [5] TC Meeting IRC Log 2025-06-24: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.html [6] Cyborg will not be marked inactive: https://review.opendev.org/c/openstack/governance/+/952798 [7] Timeline changes for the Eventlet Removal goal: https://review.opendev.org/c/openstack/governance/+/952903 [8] PBR setuptools incompatibility: https://bugs.launchpad.net/pbr/+bug/2107732 [9] CFP for OpenInfra Summit 2025: https://summit2025.openinfra.org/cfp/ [10] OpenStack TC YouTube Channel: https://www.youtube.com/@openstack-tc [11] TC Meeting Agenda, 2025-07-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ops][largescale-sig][scientific-sig] Ops Radio Hour on June 27, 2025
by Ildiko Vancsa 29 Jun '25

29 Jun '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __June 27th, 2025 at 1300UTC.__ The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. Topics the next gathering will dive into: - Networking: switches and transitioning to OVN - RabbitMQ upgrade - OpenInfra Summit Forum session planning What other topics should we add to the agenda? A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on June 27th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 2

[keystone] Status of External OAuth2 grant support
by Waines, Greg 29 Jun '25

29 Jun '25

What is the status and forecast of the work on this 'approved' spec ? https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddlewa… Greg.

1 0

Floating IP randomly becomes unreachable from external network (OSA AIO 30.0.2, Ubuntu 24.04)
by christophel＠silival.com 27 Jun '25

27 Jun '25

Hello, I’m currently running an OpenStack-Ansible All-In-One deployment (version 30.0.2) on Ubuntu 24.04. The environment hosts several virtual machines across multiple tenant networks. Each VM is assigned a floating IP from a public 172.x.x.x range, which allows access from the controller host and external clients. The issue From time to time, a VM becomes unreachable via its floating IP. The instance is still: Running normally. Reachable from other VMs on the same internal tenant network using its private IP (10.x.x.x). Associated with the same security groups and port configuration as before. This happens without any apparent trigger or configuration change. I can still ping and SSH to other VMs’ floating IPs, so the problem is isolated to one instance at a time. Workaround The only way I’ve found to restore external access is: Disassociate and delete the current floating IP. Allocate a new floating IP from the same pool. Associate it to the same VM port. Once the new floating IP is set, the VM becomes immediately reachable again. This has now occurred several times across different VMs. I’m concerned it will keep happening randomly. Question Has anyone encountered similar behavior with floating IPs in an OpenStack-Ansible AIO setup? Is there a known root cause, or any specific logs or areas I should investigate? If this mailing list is not the right place for this type of question, I’d also appreciate guidance on where to report it or who to contact. Thanks in advance for your help, Christophe.

3 7

[openstack]Detach and Attach Openstack Instance interfaces wont work
by Nguyễn Hữu Khôi 27 Jun '25

27 Jun '25

Hello. It is not a problem from Openstack but I think it will impact to our users https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2115545 Nguyen Huu Khoi

1 0

[manila] Python-manilaclient functional tests hack-a-ton - Jun 30th - Jul 4th
by Carlos Silva 27 Jun '25

27 Jun '25

Hello zorillas and interested stackers, Our Flamingo hack-a-ton starts next Monday at 15:00 UTC. We've been closing the gaps on OSC for a while now, and we are getting close to wrap everything up prior to the removal of the manilaclient and fully focus on OSC. On this hack-a-ton, we will focus on adding more functional test coverage to the OSC commands. Hackathon Plan: * Task Assignments: participants are encouraged to create, claim, and edit Taiga cards for their chosen implementations. Recent additions can serve as inspiration. Please contact Carlos (carloss) to be added to the Taiga board. Additionally, please add yourself as a "watcher" to two other Taiga cards being implemented by others to serve as a code reviewer. * Code Submission Window: Code can be submitted between June 30th, 15:00 UTC, and July 4th, 15:00 UTC, to be considered part of this hackathon. * Kick-off Session: A one-hour kick-off session will be held on June 30th at 15:00 UTC. This session will cover environment setup and also how to implement and run tests in your environment. The doc was kindly prepared by Vida (vhari) and is already available [2] in case you'd like a headstart. * Mid-point Status Check: The Manila upstream weekly meeting hour will serve as a mid-point status check. [1] https://gist.github.com/silvacarloss/295ca27bc1d76aed6564ab05ebdea2c7 [2] https://docs.google.com/document/d/1n44DXYvn_HDvr-NIuL3k3SE_UxoH15swMn0zPbc… Looking forward to working with you! Regards, carloss

1 1

migrating to ovn
by Mario David 27 Jun '25

27 Jun '25

hi all after today's meetup I have compiled information/documentation about migrating to OVN here https://github.com/mariojmdavid/migrate-to-ovn feel free to check, comment, criticize, you can open issues or contribute the process is far from full bulletproof I have this openstack infra up and running in production, but there are a few points I am in doubt, and will need further discussion namely about the net namespace (I was used with ip netns exec qrouter.... on the nodes running the l3-agent), as well as how to properly configure SRIOV but will get there best Mario

1 0

Help Name the OpenStack 2026.1 "G" Release
by Allison Price 27 Jun '25

27 Jun '25

Hi everyone, It’s time to name the OpenStack 2026.1 “G” release. Below is a poll that will be open until this Friday, June 27 at 1700 UTC. Please submit your preferences and we will let you know once the winner has been identified. https://civs1.civs.us/cgi-bin/vote.pl?id=E_17c91bf2dbfe3a77&akey=d3d789cac3… Cheers, Allison

1 1

[release] Release countdown for week R-13, Jun 30 - Jul 04
by Elõd Illés 27 Jun '25

27 Jun '25

Development Focus ----------------- The Flamingo-2 milestone is next week, on July 3rd, 2025! 2025.2 Flamingo-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/flamingo/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. The release team will soon propose releases for any library that has not been otherwise released since milestone-1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new '2025.2 Flamingo' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables/flami… and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in 2025.2 Flamingo have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in 2025.2 Flamingo, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Flamingo-2 Milestone: July 3rd, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron][os-ken] Bug on the BGP loop prevention
by anas.jouhdy＠gmail.com 27 Jun '25

27 Jun '25

Hi, As it is my first message here, do not hesitate to tell me if something is wrong with the ticket ! I think there is a bug in this file https://opendev.org/openstack/os-ken/src/branch/master/os_ken/services/prot… on the method "_is_looped_path_attrs" on line 1655. In the case we found a loop, we should return True instead of None. For example in my case, I have an Openstack BGP speaker that advertise correctly the reachable subnets in Openstack. The external peer (Cumulus switch in my case) re-advertise the IP prefix of the subnets to my Openstack BGP speaker when it learns them. This rightfully raise an error in the log thanks to this method "_is_looped_path_attrs" telling that the update coming from the external peer will be ignored as the local AS was found in the AS Path but after that, the debug log implies that the path was still added to the potential path that can reach the subnet. This then become an issue when we detach our subnet from the router, because only the local path will be removed and the route will not be withdrawn (because the new best path will be the "false" route learned back from Cumulus) Do not hesitate to ask for precision !

3 2

Ops Radio!
by Chris Morgan 27 Jun '25

27 Jun '25

We'll do another Ops Radio today at 13:00 UTC which is in about 20 minutes from now as I write. See https://etherpad.opendev.org/p/openstack_ops_radiohour "*What is "OpenStack Ops Radio Hour"? * A casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments." -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[cinder] Volume to Image Upload with Multi-Store Backends (Cinder + Glance)
by Maximilian Stinsky-Damke 27 Jun '25

27 Jun '25

Greetings, I'm in the process of setting up a new OpenStack deployment where both Cinder and Glance are configured with multiple Ceph-based backends using the multi-store functionality. Basic operations (create, delete, snapshot, upload, etc.) work fine for each store in both services. However, I'm encountering issues when trying to upload a Cinder volume to Glance as an image in this setup. My understanding is that when the volume type does not include image_service:store_id, Cinder should upload the image to the default Glance store. However, in my case, this upload fails with the following error: ERROR oslo_messaging.rpc.server FileNotFoundError: [Errno 2] No such file or directory: '/etc/ceph/ceph.client.cinder.keyring' I'm having trouble understanding why Cinder is trying to access this particular keyring. Each of my Cinder backends has its own Ceph config and keyring pointing to the appropriate cluster, and everything else works correctly. Here are my specific questions: 1. Should Cinder not be uploading the volume to Glance via the API, without needing direct access to the Glance Ceph store? 2. If Cinder is expected to access the Glance backend directly (e.g., to optimize data movement), how does it determine which Ceph config and keyring to use? 3. Is there any documentation or configuration guidance available on how to tell Cinder which credentials to use when interacting with Glance stores? Any insights or pointers would be greatly appreciated. Best regards, Max

3 4

[Cinder][Nova] - Volume retype fails with libvirt error about active block job
by Karl Kloppenborg 26 Jun '25

26 Jun '25

Hi Cinder + Nova Teams. Live migrating between two storage backends, most VM’s move successfully, but we’re seeing several VM’s fail the retype with the following error: https://gist.github.com/inventionlabsSydney/137121e8a4772ea3562776c10f43371a Libvirt logs show the following: 2025-06-26 06:55:48.906+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 06:57:08.879+0000: 2509006: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 06:57:09.053+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 23:24:19.954+0000: 2509008: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 23:24:20.130+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job Has anyone else encountered similar to this, we cannot seem to find any difference between VM’s that are working and VM’s that fail this retype. Openstack details: Version Epoxy. Compiled against library: libvirt 10.0.0 Using library: libvirt 10.0.0 Using API: QEMU 10.0.0 Running hypervisor: QEMU 8.2.2 Migration backends: From: Ceph. To: PowerFlex. Karl Kloppenborg Chief Technology Officer m: +61 437 239 565 resetdata.com<https://resetdata.com/> [cid:reset_69557fc2-1d63-4932-b5fd-93bd4f39ca7b.png] ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting For more information on the phasing of these requirements for business please visit; https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…<https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…> This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact(a)resetdata.com.au<mailto:contact@resetdata.com.au>

1 0

[dev] OpenStack Templateless Provisioning
by prmjh4＠gmail.com 26 Jun '25

26 Jun '25

Do we have any mechanism in OpenStack environment where we do not need an appropriate template already exists in the OpenStack environment in order to create server instance on the OpenStack Cloud programmatically? where we can do the templateless provisioning of the server instance on OpenStack?

5 10

Help with vGPU's using an NV L4 card on U24.04 (6.8)
by Tyler Wilson 25 Jun '25

25 Jun '25

Hello All, I'm trying to get vGPU's to work with openstack and I believe I am almost there, however I can't seem to get them to register to placement. Here is what I have so far OS: Ubuntu 24.04 Kernel: 6.8.0-62-generic Nvidia GRID Version: 570.158.02-570.158.01-573.39 Openstack Deployment: Kolla w/ Docker Openstack Version: 2025.1 I have the SRIOV devices enabled with the systemd service, and can see the vgpu types; # cat /sys/bus/pci/devices/0000:25:00.0/virtfn0/nvidia/creatable_vgpu_types ID : vGPU Name 908 : NVIDIA L4-1B 909 : NVIDIA L4-2B 910 : NVIDIA L4-1Q 911 : NVIDIA L4-2Q 912 : NVIDIA L4-3Q 913 : NVIDIA L4-4Q 914 : NVIDIA L4-6Q 915 : NVIDIA L4-8Q 916 : NVIDIA L4-12Q 917 : NVIDIA L4-24Q 918 : NVIDIA L4-1A 919 : NVIDIA L4-2A 920 : NVIDIA L4-3A 921 : NVIDIA L4-4A 922 : NVIDIA L4-6A 923 : NVIDIA L4-8A 924 : NVIDIA L4-12A 925 : NVIDIA L4-24A My kolla node nova custom config (for nova-compute) is [DEFAULT] debug = true verbose = true [devices] enabled_mdev_types = nvidia-918 [mdev_nvidia-918] max_instances = 8 [libvirt] live_migration_downtime = 500000 live_migration_downtime_steps = 3 live_migration_downtime_delay = 3 I've also created flavors, classes, and traits with; openstack flavor create l4-1a --ram 8192 --disk 40 --vcpus 4 openstack flavor set l4-1a --property "resources:VGPU=1" --property "trait:CUSTOM_NVIDIA_918=required" openstack resource class create CUSTOM_NVIDIA_918 openstack trait create CUSTOM_NVIDIA_918 However I can't seem to get placement to show any vGPU's or any of the traits I registered: This just has an empty line # openstack allocation candidate list --resource VGPU=1 and this will just show the standard vCPU/Memory/Disk # openstack resource provider inventory list <Host UUID> Have I missed a step somewhere, do I need to prepare the devices further before nova can pick them up? Thanks for any and all help!

2 2

[largescale-sig] Next meeting: June 25, 14utc
by Thierry Carrez 25 Jun '25

25 Jun '25

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

2 1

[neutron] [openvswitch] Outage problem while upgrading openvswitch
by İzzettin Erdem 25 Jun '25

25 Jun '25

Hello, We have a kolla-ansible yoga environment with 9 controller nodes and more than 1000 compute nodes. When I upgrade neutron and openvswitch to a newer version (doesn't matter which, in my case Antelope) access to all virtual machines is lost, but if there are existing ping flows, new ones are not created. This continues until openvswitch deploy is completed, i.e. neutron_openvswitch restart. In some cases, the access outage can be prolonged. When I send an upgrade to neutron alone, I don't experience any outage. How can I prevent this, is there a way to send a hot-upgrade to neutron&openvswitch without any outage? Or is it normal to have an outage?

2 1

[neutron] Disable fullstack CI job
by Rodolfo Alonso Hernandez 25 Jun '25

25 Jun '25

Hello Neutrinos: As commented yesterday in the Neutron meeting [1], the "fullstack" CI is blocking the eventlet removal. This CI FW is also blocking the SDK migration [2]. The refactor of this CI is now not possible due to time constraints. Because of this, we are going to disable it and migrate the tests implemented to other FWs, if possible. The coverage of this CI is important but limited. The advantage of this FW is the possibility of, for example, restarting services or agents; this is something achieved by other FWs like "tobiko". Another advantage is the possibility of testing with different configurations, but that could also be achieved by using the same CI job with different static configurations; it is also possible to change the API configuration and restart it using "whitebox-neutron-tempest-plugin". I've created a bug to track these efforts [3]. In the next few hours I'll send a patch to remove the "fullstack" FW from our CI. Regards. [1] https://meetings.opendev.org/meetings/networking/2025/networking.2025-06-24… [2]https://review.opendev.org/c/openstack/neutron/+/947851 [3]https://bugs.launchpad.net/neutron/+bug/2115327

1 0

[qa] Devstack gate is blocked, avoid recheck until fix is merged
by Ghanshyam Maan 24 Jun '25

24 Jun '25

Hi All, Devstack master gate is blocked due to swift-dsvm-functional failure. Tim has fix up for review [1], please do not recheck until that is merged. [1] https://review.opendev.org/c/openstack/swift/+/953234 -gmann

1 1

Problems with the Placement service
by Ron Gage 24 Jun '25

24 Jun '25

5 7

[ironic]SSH login failure to baremetal instance deployed by ironic
by Junya Noguchi (Fujitsu) 24 Jun '25

24 Jun '25

To whom it may concern I failed to SSH into a baremetal instance deployed by Ironic. I deployed the baremetal instance using an OS image created for Ironic by Diskimage-builder. When I tried to SSH into the instance, the connection was refused due to a "Permission denied" error. [aaaaaaaa@localhost ~]$ ssh -i .ssh/key.pem cloud-user(a)xxx.xxx.xxx.xxx cloud-user(a)xxx.xxx.xxx.xxx's password: Permission denied, please try again. cloud-user(a)xxx.xxx.xxx.xxx's password: Permission denied, please try again. cloud-user(a)xxx.xxx.xxx.xxx's password: cloud-user(a)xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). [aaaaaaaa@localhost ~]$ When I created a virtual machine (VM) instance using the same image, I was able to successfully SSH into it using the same steps. [aaaaaaaa@localhost ~]$ ssh -i .ssh/key.pem cloud-user(a)yyy.yyy.yyy.yyy Last login: Fri Jun 6 07:41:42 2025 from yyy.yyy.yyy.yyy [cloud-user@vm_instance ~]$ To build the OS image, we used the following commands from the ironic-python-agent-builder documentation: $ disk-image-create rocky-container vm dhcp-all-interfaces block-device-efi openssh-server cloud-init growroot -o rocky9.5_ironic_x86 $ openstack image create Rocky-9.5_x86_baremetal --file rocky9.5_ironic_x86.qcow2 --disk-format qcow2 --property architecture=x86_64 --container-format bare In the past, I have successfully SSH login into baremetal instances deployed with OS images created in this way. https://docs.openstack.org/ironic/latest/user/creating-images.html#disk-ima… SSH login succeeds for VM instances but fails for bare metal instances, even though the same OS image is used. If you know the reason why this happens, please let me know. Best regards, Junya Noguchi

2 1

Custom Role Configuration for Admin Activities in OpenStack
by Thamanna Farhath 24 Jun '25

24 Jun '25

Hi Team, As part of enhancing our OpenStack RBAC policy management, we are in the process of setting up custom roles for various admin-related activities. Custom Roles Used: admin_instance_read,admin_volume_read,admin_network_read,admin_glance_read Policy Customizations: # Compute - List all instances across tenants "os_compute_api:servers:index:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" "os_compute_api:servers:detail:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" # Network - Get networks (shared/external/own project) "get_network": "(rule:admin_only) or (role:reader and project_id:%(project_id)s) or rule:shared or rule:external or rule:context_is_advsvc or role:admin_network_read" # Volume - List all volumes and snapshots across projects "volume:get_all": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" "volume:get_all_snapshots": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" # Image - List all images including shared/community/public "get_image": "role:admin or (role:reader and project_id:%(project_id)s) or project_id:%(member_id)s or 'community':%(visibility)s or 'public':%(visibility)s or 'shared':%(visibility)s or role:admin_glance_read" "get_images": "role:admin or (role:reader and project_id:%(project_id)s) or role:admin_glance_read" Issue: Despite the above configurations, listing all instances, images, volumes, and networks across all projects still only works for the admin role. The custom roles (e.g., admin_instance_read, etc.) are not taking effect for cross-project visibility as expected. Request: I would appreciate any suggestions or insights on: Whether additional policy bindings or role scopes are required. If any service-specific constraints might be overriding the custom roles. Any known limitations regarding get_all_tenants behavior with custom roles. Thanks & Regards Thamanna Farhath N Associate engineer - R&D Zybisys IT consulting Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

5 17

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

23 Jun '25

Hello Stackers, We're fourteen weeks away from the coordinated 2025.2 "Flamingo" release of OpenStack [1], and Milestone-2 for this release is on 2025-07-03. In the past week, the Call for Papers for the upcoming OpenInfra Summit in Paris-Saclay ended; however, the deadline to propose Forum sessions and Project Updates sessions is 2025-07-08 at 23:59 PST [2]. This time at the summit, there's also a "New Contributor Showcase" inviting presentations on projects that leverage or support open infrastructure. Whether it’s your first contribution, an open source tool, or a collaboration with a community, we want to hear about it, so please consider applying [3]. In the past week, the OpenStack Technical Committee did not merge any new governance changes. A few change proposals are open for the community's input. OpenDev Infra administrators and OpenStack's Release Management team have posted several changes to begin enforcing the Developer Certificate of Origin in lieu of the Contributor License Agreement from July 1, 2025 [4]. If you haven't already begun using "git commit -s" to sign off your commits in adherence to the DCO, please do so. As a reminder, from July 1st, OpenDev's Gerrit system (https://review.opendev.org) will reject any changes that do not include a "Signed-off-by" line in the commit message. Simultaneously, the existing CLAs will no longer be available for new contributors to sign. === Weekly Meeting === The OpenStack Technical Committee met on OFTC's #openstack-tc channel on 2025-06-17 [5]. The team confirmed plans to transition to DCO (Developer Certificate of Origin) by July 1st, approving updates to the contributor guide and discussing the ongoing process of integrating DCO across tools and translations. We then focused on improving the contributor experience, with analyses of review metrics being shared with various project teams like Nova and Cinder through weekly IRC meetings. This data collection aims to identify pain points and best practices to inform future strategies. We plan to drive collective attention to this effort during the PTG in October. We also discussed the level of activity in the Cyborg project. We have had issues contacting the core maintainers to get some critical fixes merged, and the TC agreed to begin the process to mark the project "inactive." This decision aligns with the upcoming M-2 release deadline. The discussion also prompted a health check on several project teams. We'll be discussing this in further detail on proposals directly on Gerrit, or in a future weekly meeting. OpenDev Infra administrators completed a transition from Nodepool to Zuul-launcher and pleasantly have not seen any negative impact on the CI. During an Open Discussion, concerns were raised about the timeline specified by the Eventlet Removal TC goal [6]. Nova maintainers, in particular, expressed the need for more time to ensure a stable transition to threading and adequate operator testing, suggesting a revised target of 2028.1 for full Eventlet removal, a point that will be further debated on the mailing list [7] and a Gerrit proposal [8]. The next meeting of the OpenStack Technical Committee is on 2025-06-24. It will be hosted over IRC in OFTC's #openstack-tc channel 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. === Governance Proposals === ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Mark Cyborg inactive | https://review.opendev.org/c/openstack/governance/+/952798 === Upcoming Events === - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair

1 1