July 2025 - openstack-discuss - lists.openstack.org

[tacker] Skip today's IRC meeting
by Yasufumi Ogawa 21 Jul '25

21 Jul '25

Hi Tacker team, Sorry for the late notice. Due to a holiday in Japan and most of us will not join, I would like to skip today's IRC meeting. Thanks, Yasufumi

1 0

[kolla-ansible][proxysql] "Wait for backup proxysql container to start" fails
by Bursztynowski Dariusz 20 Jul '25

20 Jul '25

Hello OpenStack community, Installing Kolla-ansible OpenStack 2025.1, I've met a problem with proxysql which does not start (in task [loadbalancer : Wait for backup proxysql to start]) because of unsupported system page size: sudo cat /var/log/kolla/proxysql/proxysql.log <jemalloc>: Unsupported system page size <jemalloc>: Error in malloc(): out of memory I'm working with aarch64 CPU (Raspberry Pi 5 cluster, instructive tool for educational purposes). I have posted the bug here including more detailed description: https://bugs.launchpad.net/kolla-ansible/+bug/2117309 . What is interesting, version 2023.1 works just fine on the same HW/OS platform. I would be grateful for any suggestions on how to resolve this. Best, Dariusz Bursztynowski

1 1

[Nova] Unable to fetch CPU/RAM allocation ratios via /os-hypervisors API (Nova API v2.91 vs v2.1 support)
by Thamanna Farhath 19 Jul '25

19 Jul '25

Hello OpenStack community, I'm working with OpenStack (2023.1 kolla ansible) Nova and using the /os-hypervisors API to gather hypervisor information. I noticed that the CPU and RAM allocation ratios (which are shown in the Horizon dashboard) are not included in the response from: GET /os-hypervisors GET /os-hypervisors/{id} We're currently using Nova API version 2.91, but I see that the /os-hypervisors API appears to support only up to version 2.1, I’d like to clarify the following points: Is it expected behavior that the /os-hypervisors API does not return CPU and RAM allocation ratios? Is there any API endpoint that exposes these ratios programmatically? As we are using Nova API version 2.91, but /os-hypervisors seems limited to v2.1, is this a known limitation or design choice? If the only source of truth is the nova.conf configuration file (e.g., cpu_allocation_ratio, ram_allocation_ratio), is there any plan to expose this via API in future releases? It would be helpful to know if this is something we should work around by manually collecting config values, or if there's a more appropriate method in modern Nova setups. Thamanna Farhath Associate Engineer R&D mailto:manoj.kumar@zybisys.com thamanna.f(a)zybisys.com https://www.zybisys.com https://in.linkedin.com/company/zybisys https://www.facebook.com/Zybisys/ https://www.instagram.com/ZyBiSys/ https://www.youtube.com/@zybisys https://www.facebook.com/Zybisys/ Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[mariadb][keystone][blazar] Deadlock error on Galera cluster
by Winicius Allan 18 Jul '25

18 Jul '25

Hi community o/ Suddenly, I noticed that the login on the dashboard wasn't working, so I checked the keystone logs. I saw some entries like that: 2025-07-10 00:53:45.120 23 ERROR sqlalchemy.pool.impl.QueuePool oslo_db.exception.DBDeadlock: (pymysql.err.OperationalError) (1205, 'Lock wait timeout exceeded; try restarting transaction') Nova-conductor was also showing messages like these. At the same time, blazer-manager was logging after every _process_event calling: ERROR sqlalchemy.exc.TimeoutError: QueuePool limit of size 1 overflow 50 reached, connection timed out, timeout 30.00 I do not know if it's related to the _process_event method that batches events concurrently[1], and the DB was locked. Well... I increased the max_pool_size from 1 to 2 on blazar-manager, and that message stops showing. Does anyone know what can cause this deadlock generally? I'd like to ask another question: I have three controllers in my environment. Why do controllers with no active VIP address bind connections on the MySQL port, for example: tcp ESTAB 0 0 10.0.0.105:3306 10.0.0.107:50642 users:(("mariadbd",pid=977010,fd=1089)) [1] https://github.com/openstack/blazar/blob/stable/2024.1/blazar/manager/servi… Best regards.

3 5

[ops] Very basic newby questions
by Leroy Tennison 17 Jul '25

17 Jul '25

I am looking for a solution to automatically move (upon request) running VMs from one hypervisor to another. The current hypervisors are KVM/QEMU. Just looking at the documentation I am becoming overwhelmed. Questions (A URL which directly addresses the question is quite acceptable): Does OpenStack work with existing hypervisors or would existing hypervisors have to be "converted" (somehow) to OpenStack? If it can be used with existing hypervisors, is there a how-to for this specific task (I understand that OpenStack can do many things). If OpenStack can't be used with existing hypervisors, are you aware of solutions for this need? I have looked at ProxMox but it appears to want centralized storage and very fast networks which doesn't match the environment. Thank you for your help.

5 10

[neutron] Drivers meeting canceled Friday, July 18th and 25th
by Brian Haley 17 Jul '25

17 Jul '25

Hello Neutrinos: As discussed in our weekly meeting, I am going to cancel the next two Drivers meetings as there is no agenda and I am on PTO. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend/week! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[ops][api][all] What are we going to do about pastedeploy usage?
by Stephen Finucane 17 Jul '25

17 Jul '25

oslo.service is going through a lot of churn right now as part of the eventlet migration. We recently noticed that some unrelated WSGI routing code had been inadvertently deprecated, and moved to undeprecate this [1]. In the long-term, however, this code doesn't really belong in oslo.service and should be moved elsewhere. I took a stab at bootstrapping an oslo.wsgi package, and after some hacking I arrived at a dependencies list containing the following: * Paste [2] * PasteDeploy [3] * Routes [4] * WebOb [5] As some of you might know, all of these packages are minimally maintained bordering on unmaintained. I'm not entirely sure we want to want to bootstrap a new project using these libraries as opposed to migrating off of them. My question is this: how important is the pastedeploy framework and the paste.ini files nowadays, particularly for deployers? While their use is relatively consistent across projects (see below), not every service uses them and for those that don't, I personally haven't heard complaints about their absence. Rather than migrating the pastedeploy stuff elsewhere, would it make more sense for affected projects to simply define a static set of middleware (with some config knobs for those we want to be able to enable/disable) and call it a day? Cheers, Stephen PS: This topic came up about 18 months ago [6], but we don't appear to have reached a conclusion. Thus my bringing it up again. [1] https://review.opendev.org/c/openstack/oslo.service/+/954055 [2] https://pypi.org/project/Paste/#history [3] https://pypi.org/project/PasteDeploy/#history [4] https://pypi.org/project/Routes/#history [5] https://pypi.org/project/WebOb/#history [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… --- fwict, the following services all rely on this combo to build their own frameworks, with Nova most likely the progenitor in each case (I'm guessing) * Nova * Barbican * Cinder * Designate * Freezer * Glance * Heat * Manila * Monasca * Neutron * Swift * Trove * Vitrage * Watcher The following services do *not* use these libraries: * Cyborg (pecan) * Ironic (pecan) * Keystone (Flask + Flask-RESTful, with some webob) * Magnum (pecan) * Masakari (homegrown framework using webob) * Zaqar (falcon) * Zun (Flask)

3 2

[Kolla] Looking for a Support Provider
by Buddhika S. Godakuru - University of Kelaniya 17 Jul '25

17 Jul '25

Hi All, We are a University in Sri Lanka, and we have a small Openstack (2023.1) deployment using Kayobe. The on-prem cloud is currently operational, but currently there is only one member who has the idea about the design, and implementation of hardware/OS/configuration/network setup. So the management is trying to find an additional entity who can support in an emergency, as well as to avoid being dependant on a single person. Are there any person/institute/person who can support our setup (not day to day activities) in case of service/hardware failure, preferably within Sri Lanka. Thank you -- බුද්ධික සංජීව ගොඩාකුරු Buddhika Sanjeewa Godakuru Systems Analyst/Programmer Information and Communication Technology Centre (ICTC) University of Kelaniya, Sri Lanka, Kelaniya, Sri Lanka. -- **** *University of Kelaniya, Sri Lanka, accepts no liability for the content of this email or for the consequences of any actions taken on the basis of the information provided unless that information is subsequently confirmed in writing. * *If you are not the intended recipient, this email and/or any information it contains should not be copied, disclosed, retained or used by you or any other party, and the email and all its contents should be promptly deleted fully, and the sender informed. * ** ** *E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. * ****

2 1

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

16 Jul '25

Hi Eugen, Thank you for your reply. I've confirmed that 'rbd sparsify' can increase available space. However, I believe there's room for improvement in the retype implementation. Currently, retyping between Ceph backends causes zero-filling, which unnecessarily consumes time and storage space. This is likely to happen frequently, for example, with retypes between Ceph's HDD and SSD backends, and the Ceph administrator would need to run 'rbd sparsify' frequently. Are there any improvements to the retype implementation being considered in the community? I would also appreciate hearing your opinion on the need for improvement. Best regards,

4 11

[horizon] Cancel weekly meetings on 2025-07-23 and 2025-07-30
by Tatiana Ovchinnikova 16 Jul '25

16 Jul '25

Hello team, I am cancelling the two upcoming weekly meetings since about a half of the members are on PTO. See you all in three weeks, August 6th! With kind regards, Tatiana

1 0

[publiccloud-sig] Chairing Public Cloud SIG
by Kees Meijs | Nefos 16 Jul '25

16 Jul '25

Hi all, Recently Felix Kronlage-Dammers asked for someone to take over chairing the bi-weekly Public Cloud SIG. After giving it some thought, I proposed to continue his legacy from the next round and on. Unless someone would object, I'll be sending out meeting invitations from here on. Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

3 2

Short Bitergia dashboard outage due to maintenance
by Ildiko Vancsa 16 Jul '25

16 Jul '25

Hi OpenStack community, I’m reaching out to let you know that the OpenStack Bitergia metrics dashboard[1] will be unavailable for a short period of time due to scheduled maintenance, where the underlying OpenSearch cluster will be updated. Details of the downtime: * Start Date: Thursday, July 17th at 10:00 AM CEST (01:00 AM PDT) * End Date: Thursday, July 17th at 12:00 PM CEST (03:00 AM PDT) __During this maintenance window, the dashboard will be inaccessible.__ Thank you for your understanding. Best Regards, Ildikó [1] https://openstack.biterg.io/app/dashboards#/view/Overview

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - July 16th (tomorrow) at 0700 UTC
by Felix Kronlage-Dammers 15 Jul '25

15 Jul '25

Hi everyone, This upcoming Wednesday (which is tomorrow, July 16th) 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 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] Information Sharing for Arm CCA Feature (Following 4/8 PTG)
by taketani.ryo＠fujitsu.com 15 Jul '25

15 Jul '25

Thank you for the productive discussion about Arm CCA feature [1] at the PTG on April 8th. > The use case for Arm CCA looks ok. But it is a bit early. It is wise to wait at least libvirt / qemu release to have a "stable" code. > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature The above information is quoted from the PTG Etherpad [2](L316) summary. I'd like to follow up on these points. I'd like to share relevant information about Arm CCA surrounding components (libvirt, QEMU, OS Distributions(e.g., Ubuntu xx.xx), hardware) as it becomes available, and proceed with the discussion step by step.. I'm starting with this email, but if there's a more appropriate method for sharing this type of information, please let me know. Here's the Arm CCA software components information I can share at this time: * Linux Kernel: The roadmap is outlined on the fifth page of the third attachment in this link [3]. The initial commits I've proposed to OpenStack are focused on RMM 1.0. KVM host support for RMM 1.0 will be available in H2 2025. * QEMU Upstream Status: The development is in-progress, awaiting the Linux Kernel merge * libvirt Upstream Status: The development is in-progress, awaiting the QEMU merge * OS Distribution Support: The road map is not clear now > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature I have a question regarding the above. For design discussions leading to spec approval, I understand that upstream QEMU/libvirt stable release is necessary. Is a specific OS distribution release (e.g., Ubuntu xx.xx) also required for spec approval? [1] https://review.opendev.org/c/openstack/nova-specs/+/938276 [2] https://etherpad.opendev.org/p/nova-2025.2-ptg [3] https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o… Regards, Ryo Taketani

3 11

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

14 Jul '25

Hello Stackers, We're eleven weeks away from the date of the coordinated release of OpenStack 2025.2 ("Flamingo") [1]. The feature freeze date for this release cycle is 2025-08-28. OpenStack project teams are busy working on and polishing features to meet this deadline. In the past week, we marked the shade and os-client-config packages as deprecated [2]. The functionality provided by these two packages has long been available through openstacksdk. We don't plan to create any new releases for these packages unless critical bugs are discovered. Besides that, there have been no significant governance updates; however, several proposals are under community review. As part of the OpenInfra Foundation's transition under the Linux Foundation, your individual membership must be renewed. The OIF staff have made this a super-easy one-click process [3]. Please complete this by 2025-07-19 to contest or vote in the next OIF Board elections. OpenStack's own PTL and TC elections will occur between 23:45 UTC on 2025-08-27 and 23:45 UTC on 2025-09-17 [4]. To contest or vote in these elections, you must renew your Foundation membership by 00:00 UTC on 2025-08-20. Don't wait—this process only takes a couple of minutes! === Weekly Meeting === The last weekly IRC meeting of the OpenStack TC took place on 2025-07-08 [5]. We noted that consensus is emerging on the updated Eventlet removal timelines [6]. We followed up on the removal of all references to the Contributor License Agreement from governance docs and OpenStack manuals. There may still be some references lurking in various project documentation websites. We request contributors to file bugs or submit simple documentation updates to switch these references to the Developer Certificate of Origin [7]. OpenStack CI jobs saw some multinode hiccups over the week due to bugs in zuul-launcher. These have been resolved by the OpenDev Infra team, and CentOS/Rocky 10 along with Debian Trixie node images are expected to be served by zuul-launcher soon. The proposal to retire Monasca [8] was discussed at length. While the project has been inactive for several cycles, the TC agreed to give maintainers a chance to state their intentions before moving ahead with retirement. We also agreed that we need better visibility into inactive projects for users and operators. We'll be tweaking the appropriate badges that show up on the repositories and adding notices on project documentation websites. Lastly, we were updated that work is underway to fully remove CLA references from Gerrit. The next weekly meeting of the OpenStack TC is on 2025-07-15 at 17:00 UTC. This meeting will be hosted over IRC in OFTC's #openstack-tc channel. Please find the meeting details, including the agenda, on the meeting's wiki page [9]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 ==== Open for review ==== - 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 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 === Upcoming Events === - 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/ === How to Contact the TC === You can reach the TC in several ways: - Email: send an email with the tag [tc] on this mailing list. - Ping us using the tc-members keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 17:00 UTC [9]. 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] Deprecation of shade and os-client-config: https://review.opendev.org/c/openstack/governance/+/953549 [3] Renew OIF membership: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] OpenStack Election Schedule: https://summit2025.openinfra.org/a/schedule [5] TC Meeting IRC Log 2025-07-08: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.html [6] Eventlet removal timeline proposal: https://review.opendev.org/c/openstack/governance/+/952903 [7] DCO instructions: https://docs.openstack.org/contributors/common/dco.html [8] Retiring monasca: https://review.opendev.org/c/openstack/governance/+/953671 [9] TC Meeting Agenda, 2025-07-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Handling VirtualMedia under Systems path (HPE Superdome Redfish)
by Sangle, Pooja 14 Jul '25

14 Jul '25

Hi all, I'm working with HPE Superdome hardware and noticed that their Redfish implementation exposes VirtualMedia under `/redfish/v1/Systems/{id}/VirtualMedia/`, which differs from the common `/Managers/{id}/VirtualMedia/` path expected by sushy and Ironic. HPE confirms this is standard-compliant per Redfish, but Ironic fails to locate the media devices due to this layout. Before opening a bug or patch, is there known support or discussion around handling this variant? Any pointers welcome! Best, Pooja Sangle

3 4

[neutron] Bug report Jul 7 - Jul 13
by Rodolfo Alonso Hernandez 14 Jul '25

14 Jul '25

Hello Neutrinos: This is the bug report for week 28 (Jul 7 - Jul 13). High: * master networking sfc jobs broken as ovs agent crashing ( https://bugs.launchpad.net/neutron/+bug/2116337) Project: networking-sfc. Assigned. Patches: https://review.opendev.org/c/openstack/releases/+/954702 , https://review.opendev.org/c/openstack/networking-sfc/+/954633 Medium: * remote-managed vnic-type binding profile validation error ( https://bugs.launchpad.net/neutron/+bug/2116087) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954292 * OVN network metadata is broken if allowed-address is configured using the same IP (https://bugs.launchpad.net/neutron/+bug/2116249) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954570 Low: * [Doc][OVN] Precedence of enforcement for QoS resource types in ML2/OVN ( https://bugs.launchpad.net/neutron/+bug/2116317) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954911 Incomplete * gateway_port: of NAT configured on logical router: is not a valid distributed gateway port on that router ( https://bugs.launchpad.net/neutron/+bug/2116335) Missing logs. * VPN Perfect Forward Secrecy (PFS) is deactivated although configured as active (https://bugs.launchpad.net/neutron/+bug/2116723) Missing version, reproducer, logs. Regards.

1 0

[neutron] Disable subnet-external-network extension
by Maximilian Stinsky-Damke 11 Jul '25

11 Jul '25

Greetings, Since Neutron 2024.2 (25.0.0), the subnet-external-network extension is loaded by default. This causes subnetworks that are part of external networks to be visible to non-admin users. We found this behavior a bit confusing for regular users, as those subnetworks are often not usable for spawning VMs or creating load balancers. Depending on the number of external subnetworks, dashboards like Networks and Load Balancer Create in Octavia can become cluttered with entries that are effectively unusable for non-admins, as they are intended only for routers and floating IPs. I’ve reviewed the patches mentioned in [1], and as far as I can tell, the new extension is enabled by default with no apparent way to disable it or revert to the previous behavior. Am I missing something? Is there a way to prevent external subnetworks from being shown to non-admin users? [1] https://bugs.launchpad.net/neutron/+bug/2051831 Thanks in advance, Best regards, Max

2 2

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

11 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 10 Jul '25

10 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 08 Jul '25

08 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 08 Jul '25

08 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 02 Jul '25

02 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 02 Jul '25

02 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 02 Jul '25

02 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