June 2025 - openstack-discuss - lists.openstack.org

[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

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

30 Jun '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 | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+

2 4

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

30 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

[skyline] Skyline appends v3 in the RC file
by Joao Antonio 28 Jun '25

28 Jun '25

1 0

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

28 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 1

[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

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 24 Jun '25

24 Jun '25

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

2 3

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

[nova] Information Sharing for Arm CCA Feature (Following 4/8 PTG)
by taketani.ryo＠fujitsu.com 23 Jun '25

23 Jun '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 10

[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

[neutron] Neutron CI meeting cancelled for today
by Yatin Karel 23 Jun '25

23 Jun '25

Hello Neutron Team !! Sorry for the last minute change as I got it conflicting with an internal meeting. We have some known intermittent issues as mentioned in https://etherpad.opendev.org/p/neutron-ci-meetings#L83. Will report the issues for those tomorrow. -- Thanks and Regards Yatin Karel

1 0

[horizon] Change option to delete volume when deleting instance
by Winicius Allan 23 Jun '25

23 Jun '25

Hello folks, Is there any option to change the default value to delete the volume when deleting the instance on Horizon? In the configuration reference[1], I only found this topic, but nothing about volume deletion [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#launc… Best regards.

2 1

[neutron] Bug deputy report for week 25 of 2025 (June 16th)
by Miguel Lavalle 22 Jun '25

22 Jun '25

I was the Neutron bug deputy last week. Following is a brief summary of the reported bugs: High bugs -------------- https://bugs.launchpad.net/neutron/+bug/2114732 grenade-skip-level-always job fails with: Security Group None cannot perform precommit_delete due to Callback. No owner https://bugs.launchpad.net/neutron/+bug/2115026 test_direct_route_for_address_scope and test_fip_connection_for_address_scope Functional test randomly fails. Assignee Yatin Karel. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952958 Medium ---------- https://bugs.launchpad.net/neutron/+bug/2114819 "tag" plugin is not case sensitive. Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952819 https://bugs.launchpad.net/neutron/+bug/2114919 dhcp_ready_on_ports() + fwaas might fail due to open transaction. Assignee Sebastian Lohff. Proposed fix https://review.opendev.org/c/openstack/neutron-fwaas/+/952852 merged https://bugs.launchpad.net/neutron/+bug/2115053 conntrack flow created for stateless SG rule. No owner Low ----- https://bugs.launchpad.net/neutron/+bug/2114832 [FT] ``test_agent_show_real_heartbeat_timestamp`` should check the timestamp in UTC timezone. Assignee Rodolfo Alonso. https://bugs.launchpad.net/neutron/+bug/2114909 [FT] Random errors in ``test_create_bridges`` . Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952828 merged

1 0

Inquiry on Integrating Ansible with Vendor-Specific Cinder Driver Code
by Sumit Gupta 21 Jun '25

21 Jun '25

Hello Moderators, We maintain a substantial body of open-source Ansible code (certified by Red Hat as a collection) for IBM Storage Virtualize, which we believe could directly benefit the Cinder driver roadmap. I’d like to understand whether it is technically and architecturally acceptable to invoke Ansible scripts from within a vendor-specific Cinder driver. Specifically: * Are there any guidelines or constraints on integrating external automation tools (like Ansible) within a Cinder driver implementation? * Is there any official documentation on the acceptance of such cross-language or framework integrations (e.g., calling Ansible from Python)? Your guidance would be greatly appreciated to ensure any contributions align with community standards and best practices. Thank you! Sumit K Gupta sumit.gupta16(a)ibm.com Senior Storage Leader, IBM

2 1

[eventlet-removal]When to drop eventlet support
by Balazs Gibizer 19 Jun '25

19 Jun '25

Hi Stackers! I would like to sync about the planned timeline of dropping eventlet support from OpenStack / Oslo. Nova definitely needs at least the full 2026.1 cycle to have a chance to transform the nova-compute service. But this plan already feels stretched based on the progress in the current cycle. So being conservative means we need the 2026.2 cycle as a buffer. Nova would like to keep a release where we support both eventlet and threading in parallel. So that operators can do the switching from eventlet to threading outside of the upgrade procedure. (This was an explicit request from them during the PTG). So 2026.2 could be that version where nova fully supports both concurrency mode, while eventlet can be marked deprecated. Then the 2027.1 release could be the first release dropping eventlet. However we need to align with the SLURP upgrade as well. 2026.1 is a SLURP. But in that release Nova might not be ready to have all services running in threading mode. So the 2026.1 - 2027.1 SLURP upgrade would force the operators to change the concurrency mode during the upgrade itself. I see two ways forward: * A) We say that operators who want to do the concurrency mode change outside of an upgrade could not skip the 2026.2 release, i.e. they cannot do SLURP directly from 2026.1. to 2027.1. * B) We keep supporting the eventlet mode in the 2027.1 release as well and only dropping support in 2028.1. What do you think? Cheers gibi

10 22

[Cinder] SystemReader & all_tenants filter issue
by skryhin＠godaddy.com 19 Jun '25

19 Jun '25

Hey Cinder team, We're running into a problem where our SystemReader role can't use the all_tenants filter when listing Cinder volumes (e.g., via `openstack volume list --all-projects`). The filter is getting stripped at the API layer here<https://github.com/openstack/cinder/blob/stable/2024.1/cinder/volume/api.py…>. This is a blocker for auditability and integrating with third-party CMDB systems, as granting full admin access for these tools isn't a secure option. We’ve seen similar functionality handled in other services like Nova (e.g., `os_compute_api:servers:index:get_all_tenants` for SystemReader), as well as in Keystone and Neutron via policy tuning. Is there a particular reason this pattern hasn’t been implemented yet in Cinder? And would it make sense to consider making this configurable via the `volume:get_all_tenants_filter` policy rule? Appreciate any insights! Best regards, Serhii K.

1 0

The Placement API endpoint was not found
by mitku.bade＠mitm-tech.com 18 Jun '25

18 Jun '25

I was trying to setup a three node (controller, compute, and neutron)openstack environment manually using ubuntu 22.04 and the openstack caracal 2024.1 release. Every instance that I have created went into cell0 ,while I expect it to went into cell1 .Plus, the cells and the hots mapping are correctly configured and are working without error .But, I face an error which related to the Placement API endpoint. Running nova-status upgrade check returns the Placement API with Failure , while the other checks such as cellV2 are successful. Also running the nova-scheduler log returns The placement API endpoint was not found :keystoneauth1.exceptions.catalog.endpointnotfound:couldnot find the requested endpoint in service catalog. I validated the [placement],[keystone_Authtoken],[DEFAULT]],[database] settings, the endpoint,service,role of placement to be correct .It has been many days .Any one to stretch his/her support on this ?

2 2

[manila] No weekly meeting tomorrow Jun 18
by Carlos Silva 18 Jun '25

18 Jun '25

Hello, Tomorrow is a holiday for some people in the US and in Brazil, and that impacts on the attendance of the meeting, so let's cancel the meeting. Please ping me on email or in #openstack-manila in case you'd like to bring up something. Thank you, carloss

1 1

VMware Migration Guide - It’s LIVE!
by Kendall Nelson 18 Jun '25

18 Jun '25

Hello Everyone, Over the last few months, the VMware Working Group has been hard at work crafting a more in depth, detailed follow up to the initial VMware Migration Whitepaper. The goal of this follow up effort is to do a deeper dive into what migration away from VMware to OpenStack could look like, the considerations, the benefits, the key pieces that OpenStack offers to meet the needs of the workloads being migrated, etc. I am pleased to announce the VMware Migration Guide <https://www.openstack.org/vmware-migration-to-openstack/vmware-to-openstack…> ! Please feel free to share this document with the larger industry, future or present customers, and anyone else looking to learn more about what it means to migrate from VMware to OpenStack. We, the working group, really hope that this resource will provide all of the answers to common questions (and more!) about the migration process and help sustain this huge resurgence of OpenStack. Additionally, we’ll be putting together a series of Superuser posts on case studies around VMware migration. If you or your company have not already submitted one, now is the time! You can send them to kendall(a)openinfra.dev! Thank you to the VMware Working Group for all of the hard work, expertise, and knowledge shared to put together this HUGE achievement. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 0

[cinder] Unexpected Ceph RBD snapshot retention behavior when deleting image-based volumes
by Rocha Lobo, Vinicius 18 Jun '25

18 Jun '25

Hi, OpenStack Community. I'm part of the StarlingX Community and our starlingx-openstack distribution is currently delivering the 2024.1 (Caracal) release. We are facing an issue when using Cinder with the Ceph RBD backend: volumes created from Glance images leave behind protected snapshots and *.deleted volumes in the cinder-volumes pool after deletion, and these remnants are not being cleaned up automatically, even though I’ve enabled deferred deletion and garbage collection. So, I'm writing this email to explain our current issue and get feedback on this new Launchpad [1] I’m creating for Cinder. Environment: * OpenStack version: 2024.1 (Caracal) * Ceph version: Reef * Cinder configuration (via Helm override): conf: cinder: backend_defaults: rbd_flatten_volume_from_snapshot: True enable_deferred_deletion: True deferred_deletion_purge_interval: 10 ceph: image_volume_cache_enabled: False Issue description: 1) Create volume(s) from an image: * openstack volume create --image <image_id> --size 100 volume-test 2) Cinder creates a protected snapshot of the source image and then clones from it (as expected due to Ceph’s requirement for protected snapshots when cloning). 3) Delete the volume(s) via OpenStack CLI: * openstack volume delete volume-test After the deletion the corresponding RBD image and its snapshot are not cleaned up: * rbd -p cinder-volumes ls -l NAME SIZE PARENT FMT PROT LOCK <uuid>.deleted 100 GiB 2 <uuid>.deleted@<clone_snap>.clone_snap 1 GiB 2 yes... Even with the garbage collection features enabled (enable_deferred_deletion, rbd_flatten_volume_from_snapshot, and deferred_deletion_purge_interval), these protected snapshots and deleted volumes persist indefinitely, unless I clean them manually: * rbd snap unprotect <volume>.deleted@<snapshot> -p cinder-volumes * rbd snap rm <volume>.deleted@<snapshot> -p cinder-volumes * rbd rm <volume>.deleted -p cinder-volumes Here’s the logs that cinder pod shows while trying to delete the volume each 10 seconds: 2025-05-28 19:44:48.079 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' 2025-05-28 19:44:58.076 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' 2025-05-28 19:45:08.081 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' Questions: * Is this behavior expected in Cinder/CEPH integrations? * Shouldn't Cinder unprotect/delete the snapshot when the last volume, depending on how it is removed? Any insights or best practices would be greatly appreciated. Thanks in advance, Vinicius Lobo StarlingX contributor [1] https://bugs.launchpad.net/cinder/+bug/2114853

2 1

[all][tc][cyborg] Call for cyborg project maintainers
by Ghanshyam Maan 17 Jun '25

17 Jun '25

Hello Everyone, Cyborg project is lacking the active maintenance. The gate is broken, no response on the fix[1]. Two weeks ago, Sean raised the conern to ML[2] but there is no response from current core. We discussed it in TC meeting (last week[3] and today[4]) and as per foundation staff reachout, the next step is to call for new maintainers. If anyone using or interested to maintain it then this is right time to step up. Also, I would like existing maintainers (first of all, thanks for maintaining it till now) to give more insight about project status and their bandwidth which can help new maintainers to onboard. As per TC process to check project status, I have proposed to mark cyborg as inactive[5], feel free to provide your opinion here or in gerrit. If we do not hear back and mark project Inactive, there will be no cyborg project deliverables release in this cycle. [1] https://review.opendev.org/c/openstack/cyborg/+/949772 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-10-17.00.log.html#… [4] https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-17-17.00.log.html#… [5] https://review.opendev.org/c/openstack/governance/+/952798 -gmaan

1 0

Nova bug report #2114855
by Vicentini Fracarolli, Joao 17 Jun '25

17 Jun '25

Hello OpenStack Community, I'm part of the StarlingX Community and our starlingx-openstack distribution is currently delivering the 2024.1 (Caracal) release. We were exploring the openstack-client "server rebuild" feature [1], and we might have found a bug. So, I'm writing this email to explain our current issue and get feedback on this new Launchpad we are creating for the Nova component https://bugs.launchpad.net/nova/+bug/2114855 [2]. It happened in the following scenario: * Create a VM with some small disk flavor and a small image. For example, using a flavor of 1 GB with the Cirros image (~ 21 MB of disk size). * Try to rebuild the VM using a new image. Example: the ubuntu-jammy qcow image. When the steps above are executed with an image with a disk size greater than the flavor size, the Nova API returns an error and the VM is not rebuilt: Flavor's disk is too small for requested image. Flavor disk is 1073741824 bytes, image is 1283063808 bytes. (HTTP 400) (Request-ID: req-7db974bb-15f3-425f-b97b-98b789b7e10f) But when we use an image with a disk size smaller than the flavor disk size, but with a virtual size bigger than the flavor disk size, Nova will try to rebuild the VM and fail: the VM state will be ERROR. It looks like the Nova API is accepting such rebuild requests, but when Nova Compute checks for virtual size, it fails. Is that expected behavior? Shouldn't the Nova API reject the request with an explicit warning telling the user to resize the VM before trying to rebuild? Thank you very much [1] https://docs.openstack.org/python-openstackclient/latest/cli/command-object… [2]https://bugs.launchpad.net/nova/+bug/2114855 Bug #2114855 “VM rebuild starts even if image virtual size is gr...” : Bugs : OpenStack Compute (nova)<https://bugs.launchpad.net/nova/+bug/2114855> Description =========== Openstackclient + Nova API accept to rebuild server with virtual size greater than the specified flavor’s disk size. Steps to Reproduce ================== 1 - Create a server specifying a flavor with small disk size (example: 1 GB) and an image small enough to fit. openstack flavor create --ram 512 --disk 1 --vcpus 1 tiny openstack server create –flavor tiny –image cirros vm-test 2 - Try to rebuild the server using a larger image but that still fits. It’s v... bugs.launchpad.net

2 1

[nova] multiple pci types with same address
by Arnaud Morin 17 Jun '25

17 Jun '25

Hello nova team, Quick question regarding support for multiple types (see [1]) with the same address: {vendor_id: "10de", product_id: "233b", "address": "00000000:03:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:04:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:44:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:45:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:83:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:84:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C3:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C4:00.0", "resource_class": "CUSTOM_H200_B"} This works fine, I was able to define multiple aliases: {name: "h200a", device_type:"type-PF", resource_class: "CUSTOM_H200_A"} {name: "h200b", device_type:"type-PF", resource_class: "CUSTOM_H200_B"} I did that to create two blocks of 4 resources (A or B). But now, I need to create a flavor to boot instances with these devices. I want to have only one flavor that can use either A or B: For now I created a flavor with: pci_passthrough:alias='h200a:4' And was forced to create a second flavor with h200b:4. Is there any way to achieve a single flavor with both: Something like this? pci_passthrough:alias='h200a:4|h200b:4' I can't figure that out for now, is it possible? [1] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#support-f…

2 1

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

16 Jun '25

Hello Stackers, We're fifteen weeks away from the coordinated 2025.2 "Flamingo" release of OpenStack [1]. Milestone-2 is in a couple of weeks. This milestone is observed by several project teams for bug targeting. From the point of view of OpenStack's governance, this milestone serves as a point where we vet project deliverables to be included in the coordinated release. Releases are not tagged for deliverables from project teams that are deemed "inactive" [2]. In OpenStack, a project team is considered "inactive" when it no longer has regular contributor engagement or ongoing development. This often reflects that the problem the project once addressed is now being solved more effectively by another solution—either within or outside OpenStack. Inactivity isn't a failure, but rather a natural sign of how technology needs evolve over time. Any community member can propose a change to mark a project team inactive prior to Milestone-2. Doing so will prevent shipping broken or unmaintained code. In the past week, the OpenStack Technical Committee did not make any new governance changes. The team's focus has been on the implementation of the DCO by our deadline of 2025-07-01. I'd like to gently remind you that beyond July 1st, changes without a "Signed-off-by" line in the commit message cannot be uploaded to Gerrit. If you have a project team meeting before this date, please let folks know about this change. === Weekly Meeting === The last weekly meeting of the TC was held over IRC on OFTC's #openstack-tc channel on Tuesday, 2025-06-10 [3]. The main focus of the meeting was tracking all the changes necessary for enforcing the Developer Certificate of Origin in lieu of the ICLA beginning on 2025-07-01 [4]. We noted changes to various infrastructure pieces, and while we're hoping for a smooth transition, we do anticipate some hiccups. We are hoping for the community's patience and cooperation as we iron out the kinks. Further, concerns were raised about the Cyborg project's apparent inactivity. The last change merged into Cyborg was over two months ago, and a critical CI fix remains open, lacking review attention. Efforts to engage the team via the mailing list have not yielded any response, and there is no recent activity on IRC or Gerrit. While it's known that the Cyborg team has historically preferred WeChat/Weixin for communication, relying on unofficial channels or Foundation staff for outreach isn’t sustainable. The TC agreed that it’s important to determine whether the project is defunct or simply in need of new leadership, and to encourage maintainers to monitor and respond through community channels. Additionally, a self-report from the Vitrage team indicated that Tempest tests are currently failing due to a lack of contributor time this cycle. With the M-2 milestone deadline approaching on July 3rd, we emphasized the importance of project teams providing accurate and timely updates to the release team. The next meeting of the OpenStack TC is today, 2025-06-17. It'll be held over IRC in OFTC's #openstack-tc channel at 1700 UTC. Please find the agenda on the meeting's wiki page [5]. 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 === Upcoming Events === - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ === 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. - IRC: Ping us using the tc-members keyword on the #openstack-tc IRC channel on OFTC. - Meeting: Join us at our weekly meeting. The Technical Committee meets every week on Tuesdays at 1700 UTC [4]. 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] Inactive projects: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [3] TC Meeting IRC Log 2025-06-10: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-10-17.00.html [4] Replace ICLA with DCO: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [5] TC Meeting Agenda, 2025-06-17: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 16 Jun '25

16 Jun '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 10

[neutron] bug deputy report for week of 2025-06-09
by Bence Romsics 16 Jun '25

16 Jun '25

Hi Team, We only had a handful of new bug reports last week: High: * https://bugs.launchpad.net/neutron/+bug/2113861 [FT] Test ``test_initialize_network_segment_range_support_parallel_execution`` randomly failing already unblocked on master, backport in progress: https://review.opendev.org/q/topic:bug/2113861 Medium: * https://bugs.launchpad.net/neutron/+bug/2114176 [L3] L3 agent ``ProcessMonitor`` is not correctly registering the new processes fix merged: https://review.opendev.org/c/openstack/neutron/+/952450 Low: * https://bugs.launchpad.net/neutron/+bug/2114190 [whitebox-neutron-tempest-plugin] ``test_only_dropped_traffic_logged`` test failing with the WSGI Neutron API migration fix merged: https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/951264 [BTW: Maybe this project would be in a better place under the openstack namespace?] RFE: * https://bugs.launchpad.net/neutron/+bug/2114451 [RFE] ports should contain a reference to the segment_id they are bound to Related to https://bugs.launchpad.net/neutron/+bug/2105855. Probably a good idea to discuss on the drivers meeting. Cheers, Bence

1 0

[nova] Is It Possible to Attach a Cinder Volume as device='lun' ?
by Janaka Wickramasinghe 16 Jun '25

16 Jun '25

Hi, I'm running an OpenStack setup with Fibre Channel (FC) storage using Cinder volumes. I'm currently trying to configure a Windows Failover Cluster in guest VMs and have encountered an issue. Windows is querying the SCSI device for the Device Identification VPD (Page 0x83). The LUN is attached as a SCSI device using a virtio-scsi controller. In the domain XML (via libvirt), I see that the disk is defined as <disk type='block' device='disk'> also has a <serial>cinder-vol-uuid</serial> When Page 0x83 is queried, it returns the serial value (i.e., the cinder-vol-uuid), which Windows fails to recognize or accept. However, if I modify the XML to use: <disk type='block' device='lun'> and remove the <serial> tag, the guest is able to retrieve the expected information (I had to stop the compute service and restart the libvirt domain). Unfortunately, any changes made directly to the domain XML do not persist. Is there a supported way to specify device='lun' instead of device='disk' for volumes attached ? Any guidance would be greatly appreciated. Thank you With Best regards, Janaka

3 3

Re: [Octavia] - Loadbalancer appear offline but are running
by Wells, Aaron 14 Jun '25

14 Jun '25

Hi Karl, We ran into and fixed this issue on our installation by making sure that the UDP heartbeat packets on port 5555 were reaching the controllers. Thanks. Aaron -- Aaron Wells wellsaar(a)iu.edu DevOps Engineer Jetstream 2 https://kb.iu.edu/d/bfde

2 1

[neutron] Neutron BGP integration upstream sync
by Jakub Libosvar 13 Jun '25

13 Jun '25

Hi all, as per the previous suggestions I created the doodle [1] to pick the right time when we could meet. Finding a good timeslot is challenging as I noticed interest from all around the globe (US, EU, Australia). Please vote for which slot fits you best and if anyone has better suggestions, please let me know and let’s discuss. Thanks! Jakub [1] https://doodle.com/group-poll/participate/aK9Nkknd/vote

1 1

[horizon] Cancel weekly meeting on 2025-06-18
by Tatiana Ovchinnikova 13 Jun '25

13 Jun '25

Hello team, I am cancelling the upcoming weekly meeting since most of the members are on PTO. See you all in two weeks, June 25th! With kind regards, Tatiana

1 0

[nova][eventlet-removal]Weekly sync video call
by Balazs Gibizer 13 Jun '25

13 Jun '25

Hi, The Nova core team agreed to have a weekly high bandwidth sync meeting about the ongoing Eventlet removal work. Here are the details: [public]Nova Eventlet removal sync Every Wednesday: 14:30-15:00 UTC (16:30 – 17:00 CEST) Video call link: https://meet.google.com/bcy-uqoz-hje Cheers, gibi

2 1

[neutron] Drivers meeting agenda for Friday, June 13th
by Brian Haley 12 Jun '25

12 Jun '25

Hello Neutrinos: We have one item on the agenda for tomorrow's drivers meeting. Please add anything else to the wiki [0] to discuss if I missed something. * [RFE] Internal DNS resolution with OVS Agent - https://bugs.launchpad.net/neutron/+bug/2112446 See you tomorrow, -Brian [0] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

[designate] It only syncs at reboot
by Alexander Luedtke 12 Jun '25

12 Jun '25

Hello Everyone, I have a strange problem, I wanted the designate services as hidden master, everything works fine, expect that the designate server does only sync with the master DNS server if I do a reboot of the host where the designate docker is on, or I have to restart the designate docker. Has anyone an idea how to fix that ? best regards Alex

2 1

[horizon] Changing the Term “Instance” to “Server” for improved clarity and consistency
by Dmitriy Chubinidze 11 Jun '25

11 Jun '25

Propose changing the term "Instance" to "Server" ( "Instances" to "Servers") in the platform’s user interface. This update will be aiming to improve clarity for users, align with industry terminology, and create a more intuitive experience. "Server" is a more commonly understood term than "Instance", especially for users who are not deeply familiar with cloud computing. Major platforms like AWS and Azure often use "Server" in their UI, even when referring to virtual instances. Adopting this term will make OpenStack easier to use and understand. This change will affect only the visual elements — such as UI labels, menus, and documentation. The underlying code, APIs, and data structures using the term instance will remain unchanged. This ensures there is no impact on functionality or development processes. We are open to feedback and discussion on this proposal.

7 8

Re: Api routes
by Bernd Bausch 11 Jun '25

11 Jun '25

I took the liberty to add the OpenStack mailing list on CC. As far as I know, the list of a service's APIs is not advertised to users, except in the documentation. An operator with access to the cloud controllers can list all endpoints of a service by generating a policy file, for example oslopolicy-sample-generator --namespace nova This will create a YAML file that contains a paragraph similar to the following per endpoint, which describes the authorization policy of this endpoint: # Delete a server # DELETE /servers/{server_id} # Intended scope(s): project #"os_compute_api:servers:delete": "rule:project_member_or_admin" This example is from https://docs.openstack.org/nova/2025.1/configuration/sample-policy.html. You need to run the oslopolicy command on a controller that contains the service's (in this case, Nova's) code. ________________________________________ From: engineer2024 <engineerlinux2024(a)gmail.com> Sent: Tuesday, June 10, 2025 10:55 PM To: Bernd Bausch <berndbausch(a)gmail.com> Subject: Re: Api routes This is not what I need. I need a way, sya, for nova api services, how many api routes or urls it supports. like, /servers , /servers/detail/ /os-aggregates etc On Tue, Jun 10, 2025 at 1:41 PM Bernd Bausch <berndbausch(a)gmail.com> wrote: These commands list API endpoints in your cloud: openstack endpoint list openstack catalog list ________________________________________ From: engineer2024 <engineerlinux2024(a)gmail.com> Sent: Monday, June 9, 2025 2:59 PM To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: Api routes In openstack, is there a feature to list all the available routes for the rest api servers, instead of checking and referring the documentation? Thanks elinux

1 0

[openstack helm] [Glance] Glance showing OSError: unable to receive chunked part when uploading image
by daniel890723＠gmail.com 10 Jun '25

10 Jun '25

Hello i'm testing using Openstack-helm to install all component but after the installation complete i can't upload the OS image through both openstack CLI or Horizon it stuck at Queueing and when i checking Glance Api log it shows 2024-11-07 07:31:19.362 7 INFO glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2024-11-07 07:31:19.400 7 ERROR glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Failed to upload image data due to internal error: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Caught error: unable to receive chunked part: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Traceback (most recent call last): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1302, in __call__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1345, in dispatch 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return method(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 415, in wrapped 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 299, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 162, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 492, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 443, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/quota/__init__.py", line 322, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 596, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 487, in _upload_to_store 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 397, in add_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 479, in store_add_to_backend_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/driver.py", line 294, in add_adapter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/capabilities.py", line 176, in op_checker 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 764, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise errors.get(e.errno, e) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 746, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi for buf in utils.chunkreadable(image_file, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 294, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = self.data.read(i) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 121, in readfn 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = fd.read(*args) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/format_inspector.py", line 956, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = self._source.read(size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1045, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi data = uwsgi.chunked_read() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Ceph Cluster Status: NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID ceph /var/lib/rook 3 82m Ready Cluster created successfully HEALTH_OK 5cf8b9bb-13e1-4c31-b47d-9e7d92c3c05d Ceph osd status: ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 0.35156 - 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 1.00 - root default -5 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 - host instance-lu-1 2 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 195 up osd.2 -3 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-2 0 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 195 up osd.0 -7 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-3 1 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 197 up osd.1 TOTAL 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 MIN/MAX VAR: 1.00/1.01 STDDEV: 0.01 now i'm able to create Empty Volume using horizon(can't create volume using default cirros image ) and i can start an Instance without volume and mount the empty volume in(Ceph also can detect when i use that volume) is there something i need to set when starting glance? because i'm following the Openstack-helm installation document to install openstack with helm

4 7

nova.conf : can [pci]alias be multivalued ?
by Michel Jouvin 10 Jun '25

10 Jun '25

Hi, We need to support several GPU models in our Nova configuration. This normally requires to add multiple `alias` entries (lines) in the [pci] section of nova.conf. Unfortunately for us, it complicates a lot the generation of nova.conf by our system configuration management tool (where the section is represented by a dict/hash, meaning that there is only 1 possible entry for 'alias'). Before trying to hack our tool, we were wondering if there is a way to put the different values as a list for a single 'alias' line and what should be the separator or syntax ? I was not able to identify a generic description of the syntax for multivalued parameters, if there is a generic rule. I already found this limitation (but we could live with it) for Keystone [federation]trusted_dashboard for example... Thanks in advance for any hint. Best regards, Michel

4 6

[neutron] Bug deputy report for week of June 2nd
by Brian Haley 10 Jun '25

10 Jun '25

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2112314 - [OVN] Missing call to update the 'neutron:ovn-bridge' in the OVN agent "metadata" extension - https://review.opendev.org/c/openstack/neutron/+/951512 * https://bugs.launchpad.net/neutron/+bug/2112569 - [ml2/ovn] Neutron sending network-vif-plugged event to nova on port down - https://review.opendev.org/c/openstack/neutron/+/951863 * https://bugs.launchpad.net/neutron/+bug/2112648 - [OVS Firewall] Remote-group member flows not restored after port rebind with same IP/MAC during migration to OVS - Patch included in bug - Need to reproduce Medium ------ * https://bugs.launchpad.net/neutron/+bug/2112453 - subnet create with subnet-pool and --gateway none creates gateway ip - Confirmed, needs owner * https://bugs.launchpad.net/neutron/+bug/2112492 - neutron-metadata-agent shows XXX (dead) status despite being functional in Neutron 26.0.0 - I could not confirm, asked for more info * https://bugs.launchpad.net/neutron/+bug/2112620 - [neutron-tempest-plugin] Test ``test_vlan_transparent_allowed_address_pairs`` failing - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/952177 - Is more work necessary? Low --- * None Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2112313 - [OVN] Deprecate OVN metadata agent in favor of OVN agent (with metadata extension) - Rodolfo took ownership * https://bugs.launchpad.net/neutron/+bug/2112446 - [RFE] Internal DNS resolution with OVS Agent - Will add to future driver's agenda

1 0

[CINDER] Dependent reviews need to be merged
by Harsh Ailani 10 Jun '25

10 Jun '25

Hello core reviewers, The following reviews are very important in the upcoming cinder release for IBM SVf Cinder Driver : 925450: [IBM SVf driver] Adding support for temporary volumegroup | https://review.opendev.org/c/openstack/cinder/+/925450 926844: [IBM SVf Driver] Added support for volumegroup-snapshot for temporary volumegroup | https://review.opendev.org/c/openstack/cinder/+/926844 916722: [IBM SVf Driver] Added support for restorefromsnapshot CLI for volumegroups | https://review.opendev.org/c/openstack/cinder/+/916722 938771: [IBM SVf Driver] Added support of clone operation for volumegroup | https://review.opendev.org/c/openstack/cinder/+/938771 929906: Doc: Documentation updates for ibm-svf-volumegroup feature. | https://review.opendev.org/c/openstack/cinder/+/929906 They are dependent on each other and our upcoming features are all dependent on these reviews. Zuul has passed on these and our internal customer reviews are also completed. Requesting you to please review them and help us merge them in the upcoming release. Thanks and Regards, Harsh

2 1

October 2025 PTG Team Signup Kickoff
by Kendall Nelson 09 Jun '25

09 Jun '25

Hello Everyone! The next OpenInfra PTG[1] will take place October 27-31, 2025 and registration for the event is now open[2]! To sign your team up, you must complete the survey[3] by September 14th at 19:00 UTC. If your team is not interested in participating, there is no need to fill out the survey. The contact information (email and preferably also IRC nickname) in the form will be used to share important details with moderators about team signup and further logistics. To ensure you receive all communications please double check and submit *ACCURATE* information! If you are not on IRC, please get on the OFTC network[4] and join #openinfra-events as much of the coordination for the event will be done in the #openinfra-events channel. You are also encouraged to familiarize yourself with the PTGBot documentation[5] as well. If you have any questions, please reach out to ptg(a)openinfra.org! Information about signing up for time slots will be sent to moderators after the team signup deadline. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.org/ptg/ [2] PTG Registration: http://ptg.openinfra.org/ [3] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2025_ptg_survey [4] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [5] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 0

[all] Submit Your OpenInfra Summit Talk This Week!
by Jeremy Stanley 09 Jun '25

09 Jun '25

Are you working on something exciting with OpenStack? This is your last chance to share it with the global OpenInfra community at the OpenInfra Summit Europe in Paris[0]! The CFP[1] closes this Friday, June 13, and the Summit organizers are especially looking for talks related to OpenStack. Whether you're operating production deployments, contributing upstream, or building new tools, this is the place to share your story. Sponsoring the Summit[2]? If you'd like to be part of the schedule launch marketing happening at the end of June, this Friday is also the deadline to confirm your sponsorship. Don’t miss the chance to highlight your work and connect with the global open source community. [0] My beloved French colleagues would want me to clarify that this is actually "Paris-Saclay" (but it's still very close to Paris!) [1] Sponsorship: https://summit2025.openinfra.org/sponsor [2] CFP: https://summit2025.openinfra.org/cfp -- Jeremy Stanley

1 0

[tacker] Proposal for changing IRC timeslot
by Yasufumi Ogawa 09 Jun '25

09 Jun '25

Hi tacker team, For some members joined our team recently, it's not convenient to attend the IRC meeting since they have another regular meeting at the same time. So I'd like to propose to change the meeting time from Tuesday 8:00 UTC to Monday 8:00 UTC. Let me know if you guys are not convenient, or we'll change the time from next week (16th June). Thanks, Yasufumi

1 0

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

09 Jun '25

Hello Stackers, We're 16 weeks away from the date earmarked for the coordinated 2025.2 "Flamingo" release of OpenStack [1]. OpenStack project teams are wrapping up design specifications and gearing up to land feature changes. In the past week, the OpenInfra Foundation officially joined the Linux Foundation [2]. This is a significant move for OpenStack and other projects under the OIF. I join you in hoping that this means greater acceleration for OpenStack and broader avenues to collaborate with other open source projects under the Linux Foundation. In the same week, the OpenStack Technical Committee also passed a few important resolutions. The primary one was to adopt the "Developer Certificate of Origin" [3] for contributor sign-offs beginning July 1, 2025. What does this mean for you? This means that any new patch uploaded to the OpenStack review system (https://review.opendev.org) on or after July 1, 2025, will require a "Signed-off-by" line in the commit message. Doing so indicates that you are submitting this code in adherence to the DCO, which replaces the Contributor License Agreement that we have long required. Adding a DCO sign-off can be done by using "git commit -s" when your username and email are properly configured in your Git environment. The TC encourages PTLs, project liaisons, and all maintainers to help other contributors become familiar with this change and assist anyone who may be confused by the new requirement. If you have any questions, please join us in #openstack-dev or #openstack-tc on OFTC, or ask away on this mailing list. Alongside this significant change, the TC also clarified the actions that the Election Officials will take when there is no need for an election [4]. The next elections for Project Team Leads and a portion of the OpenStack Technical Committee will occur between Aug 27, 2025, and Sep 17, 2025. The official nomination window opens at 23:45 UTC on Aug 06, 2025. However, you're welcome to submit your nomination at any time before this date. Doing so may be helpful if you plan to be away during the nomination window. OpenDev Infrastructure Administrators have now enabled all registered users to add or edit hashtags on the code review system [5]. Some project teams have long found this useful for linking related changes—hashtags in Gerrit are more versatile than topics. I hope you'll find this helpful! === Weekly Meeting === On Jun 3, 2025, the OpenStack Technical Committee held its weekly meeting as both a video conference [6] and over IRC in OFTC's #openstack-tc channel [7]. The meeting was well attended and primarily focused on the DCO (Developer Certificate of Origin) implementation, contributor experience challenges, and other open governance proposals. A key decision was to separate translation-related concerns from the main DCO implementation. The i18n SIG has been migrating from Zanata to Weblate and will explore how the DCO can be prominently enforced via Weblate. The discussion then moved on to the findings from the maintainer and contributor surveys for the Epoxy release cycle. The survey results [8] indicated that 73% of maintainers reported difficulty getting review attention, while 68% of non-maintainer contributors faced challenges in having their reviews completed. TC members brainstormed potential reasons, and some key concerns identified include: - Inconsistent review prioritization across projects - Poor visibility into project-specific review processes - Heavy reliance on Etherpads for tracking priorities - Underutilization of review priority labels in projects that have enabled them A couple of minor action items were identified for the TC and project maintainers. Project maintainers are expected to audit their CONTRIBUTING.rst files and clearly indicate how contributors can get their changes reviewed and merged. The TC also plans to enforce more structured cross-project discussions at the October PTG. As a tangential concern, we supported the idea of hosting an ops meetup at the upcoming OpenInfra Summit in Paris-Saclay [9]. The next meeting of the OpenStack TC is today, 2025-06-09, at 17:00 UTC. This meeting will be held over IRC in the #openstack-tc channel on OFTC. Please find the agenda on the meeting's wiki page [10]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Replace CLA with DCO for all contributions | https://review.opendev.org/c/openstack/governance/+/950463 - Add nova-contrib repository | https://review.opendev.org/c/openstack/governance/+/951569 - Clarify actions when no elections are required | https://review.opendev.org/c/openstack/governance/+/949431 ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-06-13: CFP Closes for the OpenInfra Summit EU: https://summit2025.openinfra.org/cfp/ - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 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] OIF joins Linux Foundation: https://openinfra.org/blog/openinfra-joins-linux-foundation [3] DCO enforcement from July 1, 2025: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [4] Election amendment: https://review.opendev.org/c/openstack/governance/+/949431 [5] Hashtags on review.opendev.org: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/… [6] TC Meeting Video Recording, 2025-06-03: https://youtu.be/y0BwG8TadVk [7] TC Meeting IRC Log 2025-06-03: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-03-17.00.html [8] Contributor and Maintainer Survey: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] OpenInfra Summit 2025: https://summit2025.openinfra.org/ [10] TC Meeting Agenda, 2025-06-10: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 1

Api routes
by engineer2024 08 Jun '25

08 Jun '25

In openstack, is there a feature to list all the available routes for the rest api servers, instead of checking and referring the documentation? Thanks elinux

1 0

[designate] Support for quorum queues
by Thomas Goirand 06 Jun '25

06 Jun '25

Hi, When setting-up Designate with quorum queues, when designate-central starts, I get: Queue.declare: (406) PRECONDITION_FAILED - invalid property 'non-durable' for queue 'central' in vhost '/' Does Designate support quorum queues? If so, how com it's trying to set 'non-durable', which doesn't exist as attribute, at least with RabbitMQ 4.0.5? Cheers, Thomas Goirand (zigo)

6 6

[release] Release countdown for week R-16
by Thierry Carrez 06 Jun '25

06 Jun '25

Development Focus ----------------- The Flamingo-2 milestone will happen in next month, 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 ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other 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. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/flami… You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/flamingo/schedule.html#f-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Flamingo-2 Milestone: July 3rd, 2025 -- Thierry Carrez (ttx)

1 0

Networking design for two external networks
by Andrei RADU 06 Jun '25

06 Jun '25

Hello guys, This is obviously a noob question but here goes: We want to link our openstack cloud with the rest of the network with two separate external physical routers, for redundancy. These will also be the BGP peers declared in openstack for advertising internal routes. We could do VRRP and have a shared IP between the two external routers but I understand that if we make a bgp adjacency with a VIP between the two external routers, when this will move from one router to the other in case of failure, there will be a period of outage on the BGP. So in order to avoid that, in openstack we were thinking to have two external provider network vlans, one for each external router, which will handle connectivity with the exterior. What would be the best network design to link the tenant networks to these two networks in a HA mode? Where would be best place to do the “smart” routing to direct the traffic one way or the other. Or is there a more elegant solution? Thank you and sorry if the question is too basic or too general, hopefully if someone used this design can share their experience. All the best, Andrei <a href="https://www.linkedin.com/company/the-pictet-group" target="_blank"></a> <a href="https://www.instagram.com/pictetgroup/" target="_blank"></a> <a href="https://twitter.com/PictetGroup" target="_blank"></a> This message is not intended for persons who are citizens of, domiciled or resident in, or entities registered in a country or jurisdiction in which its distribution, publication, provision or use would violate current laws and regulations. The content of this message is confidential and may be read and/or used only by the recipient of this message. For information about personal data protection, please refer to the Pictet Group’s Privacy Notice available at www.pictet.com/privacynotice. If you have received this e-mail message in error, please destroy it and delete it from your computer. The Pictet Group may not be held liable for the use, transmission or treatment of the content of this message. The recipient of this message remains solely liable for any form of reproduction, copying, disclosure, modification and/or publication of the content. No liability whatsoever will be incurred by the Pictet Group. The recipient of this message agrees to comply with the applicable laws and regulations in the jurisdictions where they use the information contained herein.<br>

1 0

[CINDER] Abandon old patches
by Harsh Ailani 06 Jun '25

06 Jun '25

Hi reviewers, Some of my team members are no longer contributors and have left the company as well. I need to abandon a few active patches which they raised earlier. How do I abandon someone else's patches? Patches to be abandoned: 871257: [SVf] Adding support of clone operation for volumegroup | https://review.opendev.org/c/openstack/cinder/+/871257 880518: [SVf] Adding support of extend operation for volumegroup | https://review.opendev.org/c/openstack/cinder/+/880518 869999: Allow Volume Migration with additional extra specs to enter driver code | https://review.opendev.org/c/openstack/cinder/+/869999 Thanks and Regards, Harsh Ailani

2 2

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 05 Jun '25

05 Jun '25

Hi all, Following on the good session we had last time discussing migrating out of LinuxBridge between operators, it was proposed to meet again in June. To find a good time slot, please respond to the following survey: https://newdle.cern.ch/newdle/TtbH8Dbv For reference, the notes from last meeting: https://etherpad.opendev.org/p/neutron-lb-ovn-migration Best, Daniel Failing CERN Cloud Infrastructure

1 1

RE: Create image error
by berndbausch＠gmail.com 05 Jun '25

05 Jun '25

Violating limits imposed by the operator should lead to a useful error message rather than an HTTP 5xx error. In any case, there should have been a message in the Glance API log. Perhaps you are using a prerelease version of OpenStack? When you get Devstack from the Git, you may want to specify the version; otherwise, you obtain software that is currently under development. For example, the following gets you the first version released this year (Epoxy): git clone https://opendev.org/openstack/devstack -b stable/2025.1 ------------------------------------------------------------------------------------------------------------------- From: BEDDA Fadhel <fadhel.bedda(a)gmail.com> Sent: Saturday, May 31, 2025 6:00 PM To: berndbausch(a)gmail.com Subject: Re: Create image error Hello, I was able to work around the problem by disabling the limits in the file: /etc/glance/glance-api.conf False instead of True Thanks Le sam. 31 mai 2025 à 09:55, <mailto:berndbausch@gmail.com> a écrit : My guess is that the image service is down. To check its status: systemctl status devstack@g-api Also check the image service log: journalctl -e -u devstack@g-api ------------------------------------------------------------------------ From: BEDDA Fadhel <mailto:fadhel.bedda@gmail.com> Sent: Saturday, May 31, 2025 3:08 PM To: mailto:openstack-discuss@lists.openstack.org Subject: Create image error Hi everyone, I installed OpenStack (DevStack). At first, I was able to create three images (Ubuntu, Debian, and Windows) in addition to the Cirros image. When I tried to add another image, everything got stuck. I couldn't add any images, and I got the infamous error 550. HttpException: 502: Server Error for url:

2 1

October 2025 PTG Dates & Registration
by Kendall Nelson 04 Jun '25

04 Jun '25

Hello Everyone! The next PTG[1] will take place October 27-31, 2025! Registration is now open[2] and free for all to attend, as per usual. Shortly, I will send along the team sign up to collect groups interested in participating. -- Kendall Nelson *Senior Upstream Developer Advocate* OpenInfra Foundation <https://openinfra.org/> [1] https://openinfra.dev/ptg/ [2] https://ptg.openinfra.org/

1 0

[neutron][ops] pre-created port remains in use after instance is deleted
by Eugen Block 04 Jun '25

04 Jun '25

Hello again, this is version Caracal, recently upgraded from Antelope. We're currently facing an issue with pre-created ports. This used to work just fine for years, now we have to delete the port, recreate it and try again. For example, we launch an instance with a pre-created port, notice that something is wrong and delete the instance. Previously, we could just launch a new instance and use the same port-id, but now we get this error: # openstack server create --image <image> --flavor 1 --port d10298ea-6dd9-40af-af7e-507f4d83a8cf test-port4 Port d10298ea-6dd9-40af-af7e-507f4d83a8cf is still in use. (HTTP 409) (Request-ID: req-e6cef8b4-d8af-4312-852b-d44ec92cf27a) I noticed that the device_id was still pointing to the previous instance, so I tried a couple of things to clear the port state, but to no avail. I tried: - openstack port set --device None d10298ea-6dd9-40af-af7e-507f4d83a8cf - openstack port set --device "" d10298ea-6dd9-40af-af7e-507f4d83a8cf and a couple of more set commands. I also don't see any option for port creation to allow reusing a pre-created port. Am I missing something? Thanks! Eugen

3 7

[Octavia] - Loadbalancer appear offline but are running
by Karl Kloppenborg 04 Jun '25

04 Jun '25

Hi Octavia Team. We’ve been recently running Octavia in our lab and despite load balancers creating and running correctly, status of them always reports offline, see attached screenshot.[cid:47E71115-B565-4330-8878-4E74F1BD57AF] Does anyone have any clues towards this? All the housekeeping and other processes seem to be working fine… Does anyone maybe have more information on how this telemetry is reported? Maybe that might send me down the correct rabbit hole. Thanks, Karl. 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

[neutron] Approach to a spec for OVN BGP integration (RFE 2111276)
by Frode Nordahl 04 Jun '25

04 Jun '25

Hello, Jakub, Thank you for filing the RFE for Neutron support for OVN native support for route exchange, which includes BGP. We appear to have a common goal of making use of this with OpenStack, and we have time set aside this cycle to work towards this goal. Communication through IRC and e-mail often has limited bandwidth, and I wonder if you would be interested in participating in a A/V sync on some cadence to get us off the ground with the initial spec work. We have good experience with how the core OVN A/V sync is organized and we could do something similar for this. WDYT? -- Frode Nordahl

6 9

[cinder]How do I configure Cinder to recognize free space in the data pool when using a Ceph Erasure Coded Pool?
by Yuta Kambe (Fujitsu) 03 Jun '25

03 Jun '25

Hi everyone, I'm using a Ceph Erasure Coded pool as the backend for OpenStack Cinder. I've created a replicated pool (volumes_meta) for metadata and an erasure-coded pool (volumes_data) for data, following the documentation here: https://docs.ceph.com/en/latest/rados/operations/erasure-code/ When I set rbd_pool to volumes_meta in cinder.conf, I receive an "Insufficient free virtual space" error, even though volumes_data has ample free space. This is because Cinder is calculating free space based on the metadata pool. When rbd_pool is set to volumes_data, Cinder correctly calculates free space based on the data pool. However, I then encounter an "RBD operation not supported" error during volume creation. I need Cinder to recognize the free space available in volumes_data while avoiding the "RBD operation not supported" error. I'm unsure how to configure this correctly and would appreciate any advice. The following is supplemental information. cinder.conf is: [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = volumes_meta rbd_ceph_conf = /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot = false rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 rbd_user = cinder rbd_secret_uuid = <uuid> For example, if the pool usage is as follows, Cinder gets 1.6TiB as the pool free space: $ ceph df --- POOLS --- POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL volumes_meta 4 32 40 KiB 24 189 KiB 0 1.6 TiB volumes_data 7 32 61 GiB 15.67k 92 GiB 2.80 2.1 TiB $ cinder get-pools --detail +-----------------------------+-----------------------------------------------------------------------------------+ | Property | Value | +-----------------------------+-----------------------------------------------------------------------------------+ | allocated_capacity_gb | 523 | | backend_state | up | | driver_version | 1.3.0 | | filter_function | None | | free_capacity_gb | 1592.07 <-★free capacity of volumes_meta | | goodness_function | None | | location_info | ceph:/etc/ceph/ceph.conf:<uuid>:cinder:volumes_meta | | max_over_subscription_ratio | 20.0 | | multiattach | True | | name | <hostname>@ceph#ceph | | qos_support | True | | replication_enabled | False | | reserved_percentage | 0 | | storage_protocol | ceph | | thin_provisioning_support | True | | timestamp | 2025-05-29T07:44:17.903149 | | total_capacity_gb | 1592.07 | | vendor_name | Open Source | | volume_backend_name | ceph | +-----------------------------+-----------------------------------------------------------------------------------+ 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

4 4

[kolla] Weekly meeting 04/06/2025 cancelled
by Michał Nasiadka 03 Jun '25

03 Jun '25

Hello Koalas, Due to clashes with other meetings from my side and majority of core reviewers - I’m cancelling the meeting tomorrow. See you next week Michal

1 0

[cyborg][nova][tc] cyborg support for pyproject.toml and failing ci jobs.
by Sean Mooney 03 Jun '25

03 Jun '25

hi everyone, tl;dr can anyone form the cyborg team approve https://review.opendev.org/c/openstack/cyborg/+/949772 As you all are likely aware when we updated the testing runtime for 2025.2 and unfroze the setuptool version by the removal of python 3.9 support setuptools 80 became available in ci. this resulted in any project that still religed on PBRs `wsgi_scripts` extension failing to deploy under devstack if they had note converted to providing a pyproject.toml Stephen finucan and i started trying to prepare openstack for this change 18 months ago but with the release of setup-tools 80 it became much more important given it blocked gates. while there are a lot of patches still in flight for other project https://review.opendev.org/q/topic:%22pip-23.1-support%22 im reaching out specifically related to https://review.opendev.org/c/openstack/cyborg/+/949772 because the cyborg job on the nova repo has been failing for several weeks now. this change should fix the failing jobs on the cyborg repo too but the nova team does still check the status of the non voting job in our check pipeline too. i pushed https://review.opendev.org/c/openstack/cyborg/+/949772 for review 20 days ago and i have a follow up to remove the jammy jobs https://review.opendev.org/c/openstack/cyborg/+/949777/1 to align cyborgs testing to the testing runtime for this release. in general the cyborg repo seam to have a number of bot and procedural patches open for the last few release https://review.opendev.org/q/project:openstack/cyborg+status:open so its not clear if any of the current core team member are active with that said there have been a few patches merged in the last 6 months https://review.opendev.org/q/project:openstack/cyborg+status:merged so the cyborg team does not seam to be entirely inactive currently. if anyone form the cyborg team sees this could you please review those patches to unblock the cyborg gate. if we don't see movent on this after m2 ill probably propose removing the cyborg job form the nova check line since its currently just wasting ci time given it always fails. regard sean. ps note for the cyborg team https://review.opendev.org/c/openstack/cyborg/+/949772 also complete the cyborg part of https://github.com/openstack/governance/blob/master/goals/proposed/migrate-… as that is the general approach we had selected to addressing the packaging issue sand adopting pyporejct.toml was required to make that possible since it was not merged before the setuptool changes.

1 0

[glance] pushing image to all stores upon creation
by Can Özyurt 03 Jun '25

03 Jun '25

Hi everyone, AFAIK the procedure to make an image available in all the stores is: 1) Create an image (on a selected/default store) 2) Import the image with all_stores option I am looking for ways to eliminate the second step and make uploading to all stores the default behaviour. 1) Is there a config for this? 2) If not, can glance plugins/flows be used to implement this behaviour? Both sync and async approaches are fine as long as images created via dashboard are pushed to all stores all well. Looking forward to your guidance. Thanks in advance. Regards, Can

2 6

Wallaby: Password rotation
by Albert Braden 03 Jun '25

03 Jun '25

I've been asked to rotate passwords in our Wallaby clusters. I found this document for zed: https://docs.openstack.org/kolla-ansible/zed/admin/password-rotation.html When I tried it in the lab I ended up with a broken cluster. Is it possible to rotate passwords in Wallaby?

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - June 4th at 0700 UTC
by Felix Kronlage-Dammers 02 Jun '25

02 Jun '25

Hi everyone, This upcoming Wednesday (June 4th - this is tomorrow :) 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 As I'm participating in the ALASCA Hackathon, I will not be able to join the SIG call myself. 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

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

02 Jun '25

Hello Stackers, We're 17 weeks away from the release date for OpenStack 2025.2 "Flamingo" [1]. All projects following the cycle-trailing release model [2] will release their 2025.1 Epoxy deliverables by 2025-06-05, i.e., Thursday this week. The OpenStack Technical Committee is close to merging a resolution to require "Developer Certificate of Origin" [3] sign-offs from committers starting 2025-07-01. This will affect committers across the community. We request that you review what the DCO signifies [4] and how OpenStack governance plans to enforce it [3], and be prepared for the change. You can add "Signed-off-by" in your commit messages today. Project maintainers are requested to encourage this sign off, and spread the word to contributors via review comments and project team meetings. When Git is properly configured with your username and email, commit with the "-s" option to include the sign-off line in the commit message. In the past week, the TC didn't merge any new governance proposals; however, several, including the proposal to transition from the CLA to the DCO, are under review. === Weekly Meeting === Last week's meeting of the OpenStack Technical Committee occurred on 2025-05-27 on OFTC's #openstack-tc channel [5]. We covered a range of topics, including DCO implementation, the OpenInfra User Survey, and gate health. The primary focus was on the transition from CLA (Contributor License Agreement) to DCO. Many tooling changes are under review to facilitate this transition. Discussions also clarified that all new patches after July 1st will require a DCO sign-off, and existing patches can be rebased and signed off in Gerrit. There was a brief discussion about potentially abandoning patches in merge-conflict without a sign-off after July 1st, but the consensus was to instead add a comment to inform contributors about the need for the DCO with the updated patchset. The 2025 OpenInfra User Survey is currently live and will close in August [6]. Foundation staff will collate responses and share them with project leads/liaisons and the OpenStack TC in September. The TC reviewed the existing questions and decided not to make changes to avoid confusing the summarization of responses. There was also an update regarding the 2024 user survey, with clarification that anonymized raw data will be shared with PTLs and the TC, and that an NDA may be required for access. The next meeting of the OpenStack TC is on 2025-06-03. This meeting will be hosted simultaneously over video and IRC. You're welcome to join through any platform that you prefer. The agenda and call details are posted to the meeting's wiki page [7]. I hope that you'll be able to join us. === Governance Proposals === ==== Merged ==== - Fix outdated info on the tc-guide | https://review.opendev.org/c/openstack/governance/+/950446 ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - [resolution] Replace CLA with DCO for all contributions | https://review.opendev.org/c/openstack/governance/+/950463 - Clarify actions when no elections are required | https://review.opendev.org/c/openstack/governance/+/949431 - Add nova-contrib repository | https://review.opendev.org/c/openstack/governance/+/951569 === Upcoming Events === - 2025-06-03: 15 ans d'OpenStack - OpenInfra UG, Paris: https://www.meetup.com/openstack-france/events/307492285 - 2025-06-05: OpenStack 15 ans! - OpenInfra UG, Rennes: https://www.meetup.com/openstack-rennes/events/306903998 - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 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] "cycle-trailing": https://releases.openstack.org/reference/release_models.html#cycle-trailing [3] TC resolution to replace CLA with DCO for all contributions: https://review.opendev.org/c/openstack/governance/+/950463 [4] Developer Certificate of Origin: https://developercertificate.org/ [5] TC Meeting IRC Log 2025-05-27: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-27-17.00.html [6] Take the 2025 OpenStack User Survey: https://www.openstack.org/user-survey/survey-2025/ [7] TC Meeting Agenda, 2025-06-03: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ops][largescale-sig][scientific-sig] Ops Radio Hour on May 30, 2025
by Ildiko Vancsa 02 Jun '25

02 Jun '25

Hi OpenStack Community, I'm reaching out to you to draw your attention to a new online gathering called Ops Radio Hour. 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. The first meeting is scheduled to May 30, 2025 at 1400UTC [1]. The call will happen on Meetpad, and you can find the agenda on the etherpad[2] created for the series. See You there! Best Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups#2025_Ops_Radio_Hour_Seri… [2] https://etherpad.opendev.org/p/openstack_ops_radiohour

2 4

[nova][horizon] VNC console policy
by Eugen Block 02 Jun '25

02 Jun '25

Hi *, I'm a bit confused regarding the policy requirements to grant a user access to the vnc console via horizon dashboard. Since we have 10 years of history in our cloud, I tried to remove legacy stuff, e.g. old policy files and try with the defaults to see what we're missing. I recently upgraded this cloud to Caracal. It seems like currently, only a user with the admin role has access. Searching for some hints, I found the deprecated policies in (everything is commented): /usr/share/openstack-dashboard/openstack_dashboard/conf/nova_policy.yaml And then the defaults here: /usr/share/openstack-dashboard/openstack_dashboard/conf/default_policies/nova.yaml In the code I found two checks for "os_compute_api:os-consoles:show": class ConsoleTab(policy.PolicyTargetMixin, tabs.Tab): name = _("Console") slug = "console" template_name = "project/instances/_detail_console.html" preload = False policy_rules = (("compute", "os_compute_api:os-consoles:show"),) class InstanceDetailTabs(policy.PolicyTargetMixin, tabs.DetailTabsGroup): slug = "instance_details" tabs = (OverviewTab, InterfacesTab, LogTab, ConsoleTab, AuditTab) sticky = True policy_rules = (("compute", "os_compute_api:os-consoles:show"),) from /usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/instances/tabs.py. But I don't find any policy like that in the defaults. So I'm wondering what the current recommendation would be. Should I add only "os_compute_api:os-consoles:show" to /usr/share/openstack-dashboard/openstack_dashboard/conf/default_policies/nova.yaml? I'm not sure if that would override the other defaults (because of one entry only) or if this would be an additional policy (haven't been playing with those for some time now). Could anyone point me to the best approach? Thanks! Eugen

1 0

[Neutron] Bug deputy - summary from week of May 26th
by Sławek Kapłoński 02 Jun '25

02 Jun '25

Hi, I was bug deputy last week and here is short summary: ### Critical None ### High None ### Medium - https://bugs.launchpad.net/neutron/+bug/2111660 - OVN_AGENT_NEUTRON_SB_CFG_KEY doesn't set when Neutron OVN Agent starts - I marked it as Medium but I don't really have env to confirm it currently, - https://bugs.launchpad.net/neutron/+bug/2111908 - [FT] ``test_subport_delete`` fails - fix proposed already by Rodolfo, - https://bugs.launchpad.net/neutron/+bug/2112110 - [ovn-octavia-provider] LoadBalancer member not coming back after disable-enable - fix already proposed by Fernando, ### Low - https://bugs.launchpad.net/neutron/+bug/2112123 - Functional: privsep helper command exited non-zero test_trunk_creation_with_no_subports - opened by Lajos to track failiure with some functional test, ### RFE - https://bugs.launchpad.net/neutron/+bug/2111899 - [RFE] Use stateless NAT rules for FIPs - proposed by Rodolfo - https://bugs.launchpad.net/neutron/+bug/2111891 - IPv6 Subnet-Router anycast address inappropriately used for gateway_ip when specifying --subnet-range - unassigned, - https://bugs.launchpad.net/neutron/+bug/2112297 - [RFE] Support Policy Based Routing for LRs in Neutron OVN driver ### To triage - https://bugs.launchpad.net/openstack-helm/+bug/2112130 - No port found in network None with IP address 169.254.169.254 - Brian already started looking into this, it seems for me that it is more OpenStack Helm issue rather than Neutron so I added Helm project to it too. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[telemetry] Nominate Jaromír Wysoglad to Telemetry Core
by Juan Larriba 01 Jun '25

01 Jun '25

Hi, One of the things I wanted to do when becoming PTL of telemetry was to revive the interest in the community as I sensed that telemetry had been left a little bit behind from the rest of the projects. Since then, there has been a lot of movement: new Ceilometer features were added and even new projects (aethos, a prometheus-keystone proxy and grian-ui, a new metric displaying dashboard for Horizon) which has showed that the interest in gathering and displaying better and more scalable metrics is only growing. In these circumstances, the very small core contributor team needs to grow to keep up with all the influx of new features coming from the amazing community and I cannot think of anyone better than Jaromír Wysoglad to fulfill that role. Jaromír has been involved in the telemetry upstream community for years, tirelessly working to, among other things, make the whole telemetry suite to be compatible with Prometheus storage. He has implemented Prometheus compatibility with aodh, python-observabilityclient and many other things, including maintaining and improving the telemetry tempest test suite. Recently he created and is writing from scratch aetos, the new openstack-prometheus compatibility layer. I can't see a better contributor to the core group. If I don't hear any objections for one week, I'll add Jaromír to the group. Best Regards, Juan Larriba

3 3