April 2025 - openstack-discuss - lists.openstack.org

[neutron][ovn] both vxlan and geneve cannot get full bandwidth
by Nguyễn Hữu Khôi 28 Apr '25

28 Apr '25

Hello. I am going with ovn for my system but when I use vxlan and geneve, my instance cannot get full bandwidth(12 gbps)-instance to instance with private network. It is ok if I use vlan or floating ip for instances. My env: Openstack 2025.1 Kolla Ansible master-2025.1 Ubuntu 22.04 with uplink 25gbps x 2 for bonding, lacp 802.3ad, layer3+4 Ps give me some points. Thank Nguyen Huu Khoi

2 3

[Cinder] : Group API query
by Harsh Ailani 28 Apr '25

28 Apr '25

Hello team, In one of our customer requirements we came across a use-case to move a volume from one group to another directly. Currently user needs to first remove the volume from the current group and add it to the new group. Wanted to know, if there is one direct cinder API or method to directly move the volume from one group to another ? Thanks and Regards, Harsh Ailani

1 2

[kolla-ansible][rabbitmq] RabbitMQ cluster creation took too long
by Nguyễn Hữu Khôi 28 Apr '25

28 Apr '25

Hello. I am deploying OpenStack 2025.1 with Kolla-Ansible 2025.1 (master branch) using the latest images. However, when I created a RabbitMQ(4.0.x) cluster with 3 nodes, it took too long—around 12 minutes(it stucked at DB: virgin node -> run peer discovery). I then changed the images to RabbitMQ version 3.13.7, and it worked well. My OS: Ubuntu 24.01 Nguyen Huu Khoi

1 1

[nova] Did something change about interface detach/attach from Yoga to Caracal?
by Nell Jerram 28 Apr '25

28 Apr '25

I'm not sure why it was originally written, but I have an ancient system test that: - creates a VM attached to one network - finds the VM's port and calls interface_detach for it - checks that the VM is now unpingable - calls interface_attach with the relevant network_id - hard reboots the VM - checks that the VM is now pingable again. With Yoga, the test passes, and at the end of the test the VM has one NIC, eth0, with an IP address. With Caracal, the test also passes, but at the end of the test the VM has two NICs: - eth0 with no IP address - eth1 with an IP address. Diffing the Nova code, it looks like interface_detach and interface_attach might actually have been no-ops in Yoga - although possibly only for a "vdpa" vnic-type, and I'm unsure whether that vnic-type would be relevant to my test setup. Any ideas about this? Many thanks - Nell

2 3

[openstack-ansible] lxc-container upgrade from ubuntu 18 to ubuntu 20 for USSURI
by Danish Khan 28 Apr '25

28 Apr '25

Dear Team, I am trying to upgrade lxc-container from ubuntu 18 to ubuntu 20 and I doing it by destroying and recreating lxc-containers. I have successfully upgraded cinder, glance, heat, horizon,memcached, neutron, nova and placement containers. But now I am unable to create galera, utility containers. I am getting below error for both: failed: [host5_galera_container-ac20] (item={'url': ' http://repo.vexxhost.net/mariadb/key.gpg'}) => {"ansible_loop_var": "key", "attempts": 5, "changed": false, "key": {"url": " http://repo.vexxhost.net/mariadb/key.gpg"}, "msg": "Failed to download key at http://repo.vexxhost.net/mariadb/key.gpg: HTTP Error 404: Not Found"} And it seems the URL http://repo.vexxhost.net/mariadb/key.gpg doesn't exist now. Do we have any workaround for this? Regards, Danish

2 5

[neutron] Today's CI meeting cancelled
by Yatin Karel 28 Apr '25

28 Apr '25

Hello Neotron Team !! I will not be around today so cancelling CI meeting. Sorry for the last minute change. -- Thanks and Regards Yatin Karel

1 0

[ops][upgrades][slurp] Seeking OpenStack Upgrade Case Studies
by Allison Price 25 Apr '25

25 Apr '25

Hi everyone, We have now published two case studies from OpenStack users who have implemented and are benefiting from the SLURP upgrade process[1]: Cleura[2] and Indiana University[3] I wanted to follow up to see if there are other organizations who have implemented the SLURP upgrade process who would like to tell your story? If we can get a few more, I would love to schedule an OpenInfra Live to deep dive into the improvements made around OpenStack upgrades and what users stuck on older releases should know. If you are interested, please let me know. And even if you’re not but you’re still using OpenStack—please remember to take the OpenStack User Survey[4] so we can learn more! Thanks! Allison [1] https://docs.openstack.org/project-team-guide/release-cadence-adjustment.ht… [2]https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-… [3] https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-a-… [4] https://www.openstack.org/user-survey

3 9

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

25 Apr '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

1 0

[neutron][ptg] 2025.2 Flamingo PTG summary
by Brian Haley 24 Apr '25

24 Apr '25

Hi all, Thanks for all that attended the meetings, we had a good turnout for Neutron, the Nova/Cinder cross-project and the eventlet removal discussions that were important to the team. For complete notes see the etherpad [0] but a summary is below. And please comment if you feel I missed anything. Thank you, -Brian ### Epoxy retrospective ### Like any other PTG, it started with a retrospective of the past cycle, with the highlights and improvement points. Good: - Eventlet removal is going well. Even the transition period (for the Neutron API with ML2/OVN) finished with good results. - Permanent "open doors" status to welcome newcomers. Our meetings (team meeting, drivers meeting) are a good forum for them. - Removed experimental code (Linuxbridge, IPv6 PD). - Migration from ML2/Linux Bridge to ML2/OVN discussions have started in Operators community (https://etherpad.opendev.org/p/neutron-lb-ovn-migration) Bad: - The loss of 2 important core developers. - No new specs merged in Epoxy cycle. ### Gate Stability ### Team has been very good at addressing gate issues quickly, and meets on a regular basis. We have noticed a few issues related to eventlet changes and are reverting them until we can address them. ### Spring cleanup / Code base modernization ### At the beginning of every cycle, we always try and cleanup the code base, for example, removing deprecated and dead code, doc updates, job consolidation. We have made progress on those already. - During Epoxy, several changes were made to match the expected output of pyupgrade/autopep8 for py39+. We will make a similar change in Flamingo for py310+ as that is now the lower bounds (haleyb). - It was also discussed to include "ruff" to our checklist (mlavalle). - Now that the OVN agent is in place and the default in gate, it was discussed about removing the OVN metadata agent as it is unnecessary to have both. - CI job reduction: move the ML2/OVS iptables-hybrid jobs to periodic (and experimental) and determine if iptables-hybrid driver can be moved to experimental config space. - TODOs: spend some time addressing the current TODO notes in the code, fixing what is proposed, already started. - Remove the unneeded OVN maintenance tasks, according to the comments in the methods. - Will make sure beginning/end of cycle docs are up-to-date on things like CI jobs, etc. (haleyb) ### Eventlet removal ### The "oslo.service" library will implement two backends (eventlet or threading), that will allow us to test both implementations during the removal. It could be useful to have temporary CI jobs, using both implementations. The testing CI (unit test, functional and fullstack) should start the migration during this cycle, but only once the Neutron service code is migrated. Please see [1] and [2] for more information and meetings notes from the eventlet-specific agenda. ### Migration to SDK (neutronclient removal) ### Etherpad link: https://etherpad.opendev.org/p/python-neutronclient_deprecation During the last cycle a number of Horizon patches merged (thanks Lajos!). Heat patches are still under review (and not attended). Nova patch is WIP: https://review.opendev.org/c/openstack/nova/+/928022 Neutron team will add deprecation warnings in the neutronclient code as there are still a number of places in both in and out-of tree code that is using the neutronclient. The fullstack tests will migrate to SDK during this cycle. ### Migrate the OVN L3 scheduler to use HA_Chassis_Group ### Link: https://bugs.launchpad.net/neutron/+bug/2092271 As recommended by the OVN core team, the usage of ``Gateway_Chassis`` to bind a ``Logical_Router_Port`` is deprecated. Instead of this, ``HA_Chassis_Group`` should be used. This bug tracks this effort that should be done during the next cycle. ### An OVN L3 router tool ### Link: https://bugs.launchpad.net/neutron/+bug/2103521 The goal of this tool is: - To be able to list the current GW LRP assignment, according to the ``HA_Chassis_Group``. It will show the GW chassis assignation level (according to the priority) and the number of routers per chassis. - To be able to reschedule the current assignments. In case of unbalance (chassis deletion, router deletion), this tool will allow to reschedule the GW chassis across the existing LRPs. This is something that is useful to cloud operators that currently must manually try and re-balance LRPs. Status: Approved ### Alembic idempotency ### Link: https://bugs.launchpad.net/neutron/+bug/2100770 This request comes from an issue seen in RHOSO18 with a DB migration back port. It is not possible to change the cycle milestones (last DB migrations of each cycle), thus the D/S migrations (in U/S are forbidden) are done before these milestones. The problem happens when a user, that is already in the last DB migration step, needs to re-execute the DB migration tool to receive the new back ported migration. That will fail because it is not possible to execute a DB migration script twice. This proposal includes: - Implementing a new test class that checks any new DB migration in order to ensure it works, as we found issues recently. - Enforce any new DB migration (code developers and reviewers) to be idempotent. - This would be supported on all existing migrations as well, not just from today forward. - Provide a usage guide on the alembic methods if necessary Status: Approved ### Stop DB drop migrations, with field drop exceptions ### Link: https://bugs.launchpad.net/neutron/+bug/2104160 In a DB migration, developers should add a TODO note to drop anything not used in the next SLURP release. That will prevent the case described in the bug, where a user executed the "expand" phase migration code with the old Neutron API code (as specified by the upgrade guide), resulting in an error due to a missing DB column, which was dropped by a DB migration script. The initial output of this bug is a new policy in the development guide. ### Create a restricted default policy for undefined API calls ### Link: https://bugs.launchpad.net/neutron/+bug/2098737 The goal of this RFE is to define a default restrictive rule for every non-defined policy in the Neutron API, as "oslo.policy" allows us to create a "default" policy that will be used in case the API call is not defined. The "default" Neutron policy is RULE_ADMIN_OR_OWNER, we propose to change this to RULE_ADMIN_ONLY. Any new API not defined in the policies would be executable only by the admin user. This change cannot be done now, due to the high number of missing API rules not defined that are using the default rule, see https://review.opendev.org/c/openstack/neutron/+/945687 - but this rule migration should be a background tasks for any team member that will improve the quality of the RBAC system in Neutron. Status: Approved ### Nova/Cinder cross-project ### We discussed two topics at the Nova/Cinder cross-project meeting. Project-Specific QoS Controls for Granular Resource Management. Driven by Bloomberg. Link: https://bugs.launchpad.net/neutron/+bug/2102184 Despite many questions still existing about the implementation, the Neutron team agreed to accept a spec describing it. The Neutron team agreed to have a per-project QoS policy that will affect to a non-defined set of resources (ports, networks, routers, FIPs). Bloomberg agreed to work on this later this cycle. For live-migration with OVN, Nova currently has a vif-plugged event timer to work-around any missed (or not sent) notifications. Link: https://bugs.launchpad.net/nova/+bug/2073254 The code for the multiple binding is in core OVN (23.09) and Neutron. Nova team will propose a patch to remove the condition in Nova and wait for the vif-plugged event when using the ML2/OVN backend as the condition should not happen any more. Patch link: https://review.opendev.org/c/openstack/nova/+/946950 ### Service role permissions ### The Octavia allowed address pair driver requires new service role permissions. Link: https://bugs.launchpad.net/neutron/+bug/2105502 Three patches proposed: - Add new default policy for device_id field on ports: https://review.opendev.org/c/openstack/neutron/+/861169 - Allow service role to create/update port device_id: https://review.opendev.org/c/openstack/neutron/+/947003 - Allow service role more RBAC access for Octavia: https://review.opendev.org/c/openstack/neutron/+/945329 ### L3/DHCP thread pool resizing ### Link: https://review.opendev.org/c/openstack/neutron/+/938411 This proposal is related to the eventlet removal topic. There is no direct replacement for ``eventlet.GreenPool``. The resizable mechanism does not provide a resource improvement in speed or memory and there is no kernel library that provides this functionality. The default and static maximum number of threads will be 32 (the current maximum). ### VXLAN physical networks ### Link: https://bugs.launchpad.net/neutron/+bug/2105855 The goal is to be able to schedule a VXLAN port depending on the physical mappings as the VTEP interfaces in each compute node could be connected to different physical networks. This would help improve the "networking-generic-switch" back end as it could use this new information. An alternative to this could be to implement a new type driver: l2vni, used for tunneled drivers (VXLAN) with a physical back end. A spec is required to study this proposal further. ### vlan_transparent ### Link: https://bugs.launchpad.net/neutron/+bug/2092174 Proposal to deprecate and remove the vlan_transparent config option. By default, the loaded drivers will determine if the functionality is supported or not. Status: Approved ### OVN "Add-Only" Sync Mode ### Link: https://bugs.launchpad.net/neutron/+bug/2099818 Proposal to add a new OVN sync mode option that will only add things to the OVN database and never remove from either OVN or Neutron. There were a few worries, as turning-off delete might just make things more out of sync, and not address any issues being seen in ovn-controller or ovn-northd. It was also pointed out that we did spend some time over past cycles tagging neutron-owned objects in OVN explicitly, and there might just be some additional edge cases we need to fix. This might address the issue where other objects change unexpectedly. Need to discuss further at future Drivers meeting as submitter did not attend. ### RFE discussions ### On-demand topic to discuss any in-progress or proposed RFE changes, please see etherpad for more information. [0] https://etherpad.opendev.org/p/apr2025-ptg-neutron [1] https://etherpad.opendev.org/p/neutron-eventlet-deprecation [2] https://etherpad.opendev.org/p/apr2025-ptg-eventlet

1 0

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

24 Apr '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 8