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

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

24 Oct '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 12

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

22 Oct '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

3 5

[Octavia][Load Balancer][2023.1] Amphora Fails Health Check – “No Route to Host” & Timeout Errors
by Thamanna Farhath 15 Oct '25

15 Oct '25

Hi OpenStack Community, I am currently facing an issue with the Load Balancer (Octavia) service in my OpenStack deployment and would appreciate your guidance or suggestions on how to troubleshoot and resolve it. Environment Details: OpenStack Version: 2023.1 (Antelope) Operating System: Ubuntu 22.04 Octavia Backend: Amphora Network Type: VXLAN Deployment Tool: Kolla Ansible Issue Summary: After creating a Load Balancer, the Amphora instance is successfully launched. However, approximately 18 minutes later, the Load Balancer transitions to an ERROR state. Error Observed: octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id a222527f-8336-4fb1-8e9e-0e3ac6e8d580 to go active timeout. octavia.amphorae.driver_exceptions.exceptions.AmpConnectionRetry: Could not connect to amphora, exception caught: HTTPSConnectionPool(host='192.168.200.247', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError: Failed to establish a new connection: [Errno 113] No route to host) What I’ve Tried: Created a VXLAN-based internal network: openstack subnet create --network octavia-mgmt-net --subnet-range 192.168.200.0/24 octavia-mgmt-subnet openstack router create octavia-router openstack router add subnet octavia-router octavia-mgmt-subnet openstack router set octavia-router --external-gateway <public-network-id> Manually configured OVS interface: ovs-vsctl add-port br-int octavia-mgmt -- set interface octavia-mgmt type=internal ip addr add 192.168.200.1/24 dev octavia-mgmt ip link set octavia-mgmt up Security groups are open (allowing all ingress and egress). Verified OVS bridge setup – interface appears correctly on br-int. Behavior Noticed: Amphora instance gets created but fails to communicate with the controller after a while,so health checks fails. The controller cannot reach the Amphora management IP (192.168.200.x). Logs show heartbeat/connection issues (No route to host, timeouts). Request for Help: I would appreciate any of the following: Suggestions to verify if the management network is properly routed from controller to Amphora. Best practices for setting up the Octavia management network using VXLAN. Troubleshooting steps for verifying health manager connectivity to Amphora. 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."

3 2

[openstack][nova]qemu system wont release memory
by Nguyễn Hữu Khôi 29 Sep '25

29 Sep '25

Hello. I have an OpenStack instance that was using 14GB out of 16GB of memory. Later, when it was using only 4GB, I checked the QEMU process on the compute node, and it was still consuming 14GB, this means memory isn't released when usage decreases. Do we have solutions for this? I use Ubuntu 24.04 instances. Nguyen Huu Khoi

2 4

[Neutron][operators] LinuxBridge to OVN Outreach
by Daniel Failing 29 Sep '25

29 Sep '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

2 3

[openstack-magnum ui] Cannot choose an external network ID when creating a cluster template
by Nguyễn Hữu Khôi 27 Aug '25

27 Aug '25

Hello, When I create a cluster template, I cannot choose an external network ID, it disappears from horizon. My env: Ubuntu 22.04 Openstack 2024.2 Thank you. Regards Nguyen Huu Khoi

3 2

[blazar] Blazar-dashboard contains non-free files (ie: minified Javascripts)
by Thomas Goirand 22 Aug '25

22 Aug '25

Hi, I've been trying to package Blazar, all is already in Debian, but I can't get blazar-dashboard in, because upstream source contains non-free files. Namely: https://github.com/openstack/blazar-dashboard/blob/master/blazar_dashboard/… is a minifed version of a much more complex package: https://github.com/apexcharts/apexcharts.js/tree/v3.31.0 Reminder: minified Javascripts are considered by most distributions (this includes Red Hat, Ubuntu, and in my case Debian) as non-free files that cannot be shipped in the distribution without the underlying source code, and packages must build from the not minified version. Could the Blazar team work on un-vendoring apexcharts.min.js, possibly removing it completely, or replacing it with a source-full version? Cheers, Thomas Goirand (zigo)

4 6

RE: Create image error
by berndbausch＠gmail.com 21 Jul '25

21 Jul '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:

1 0

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

14 Jul '25

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

3 11

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

09 Jul '25

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

3 2

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

09 Jul '25

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

2 3

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

07 Jul '25

2 3

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

05 Jul '25

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

3 5

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

01 Jul '25

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

1 1

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

30 Jun '25

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

1 0

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

30 Jun '25

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

3 4

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

30 Jun '25

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

1 0

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

30 Jun '25

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

3 2

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

30 Jun '25

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

1 0

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

30 Jun '25

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

2 1

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

30 Jun '25

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

3 3

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

30 Jun '25

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

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-13)
by Goutham Pacha Ravi 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