- openstack-discuss - lists.openstack.org

[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 03 Jun '25

03 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 03 Jun '25

03 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 02 Jun '25

02 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

Create image error
by BEDDA Fadhel 31 May '25

31 May '25

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

[ops] Matrix room created #openstack-ops:opendev.org
by Jeremy Stanley 30 May '25

30 May '25

Discussion during today's Ops Radio Hour at one point led to talking about real-time/synchronous chat platforms. Consensus seemed to be that it was worth starting a Matrix room on the OpenDev Collaboratory's homeserver for OpenStack Ops discussions, and see how it works out for everyone. Visit https://matrix.to/#/#openstack-ops:opendev.org if you want to check it out. If you're already logged into your Matrix account then the "Continue" button should take you right to the room. If you're not logged in then it should prompt you to pick a client (choose Element and continue in your browser if you don't feel like installing a client right now) and then to sign in or create an account. If you choose to create an account at that point, it painlessly walks you through creating one on matrix.org (though you can join with an account from any other homeserver instead, if you prefer). -- Jeremy Stanley

1 0

Create image
by BEDDA Fadhel 30 May '25

30 May '25

Aidez moi svp HttpException: 502: Server Error for url: http://192.168.30.10/image/v2/images/2440ca4f-7a35-4fd1-88b2-5e4f269ef5d8/f…, 502 Bad Gateway: Bad Gateway: The proxy server received an invalid: response from an upstream server.: Apache/2.4.58 (Ubuntu) Server at 192.168.30.10 Port 80 Cdt

1 0

[ops] ops radio May 30 2025
by Chris Morgan 30 May '25

30 May '25

Hey Folks, Tomorrow the openstack ops meetups team (such as it is) would like to try something different, we're calling it "ops radio" a bit like talk radio. I posted a little about it here https://fosstodon.org/@osopsmeetup/114585889262579171 Time : 14:00 UTC which is 10am here (NYC). Just an hour free-form meeting on openinfra's jitsi so it's quite like just another zoom meeting. The jitsi link and agenda link are here on the ops meetups wiki: https://wiki.openstack.org/wiki/Operations/Meetups The idea is if people like this we could aim to do it regularly since in-person meetups have become much rarer and harder to do and since the community seems to be somewhat distributed across reddit, linkedin, mastodon, irc, mailing lists, bluesky, matrix, slack etc. technical topics will include the usual things like architecture. tools, upgrades, pain points depending on what people who attend want to discuss. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 1

some operations are available only to the administrator, regardless of the policies?
by sluge＠mail.ru 29 May '25

29 May '25

Hi everyone, I'm currently writing a custom nova's policy for my new role myrole. The current task is to create a role for a user with member role already assigned to see servers from other project. For example, I got a token for my user in project1, but want to see servers on project2, where my user has a member and myrole roles also. I added to nova's policy.json line: "os_compute_api:servers:show": "rule:project_reader_or_admin or role:myrole" I already assigned to my user roles member and myrole in the project1 and project2. But I always got a 404 error when I want to show servers from project2. I get 404 even when I use "os_compute_api:servers:show": "" i.e. always true. It only works if I use token of admin user or my user has admin role in project2. It looks like some operations are available for admins only?

3 3

[openstack-helm][loci] Retire Centos based images
by Vladimir Kozhukalov 28 May '25

28 May '25

Hi team, We have a bunch of Centos related stuff in the Loci repo. However we've not been building and testing centos based images for quite some time. Is anybody still interested in having/maintaining this stuff? I am talking about [1] - [5]. [1] https://opendev.org/openstack/loci/src/branch/master/dockerfiles/centos [2] https://opendev.org/openstack/loci/src/branch/master/scripts/install.sh#L37… [3] https://opendev.org/openstack/loci/src/branch/master/scripts/collect_info.s… [4] https://opendev.org/openstack/loci/src/branch/master/scripts/install_packag… [5] https://opendev.org/openstack/loci/src/branch/master/scripts/cleanup.sh#L14… -- Best regards, Kozhukalov Vladimir

1 1

Re: [neutron] Switching the ML2 driver in-place from linuxbridge to OVN for an existing Cloud
by Ohnsorge Borys 28 May '25

28 May '25

Hi James, I know this topic is old, but have you had the time/opportunity to describe the migration process based on openstack-ansible You mentioned? __ Best regards Borys Ohnsorge

2 1

[largescale-sig] Next meeting: May 28, 15utc
by Thierry Carrez 28 May '25

28 May '25

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

1 1

[openstack-ansible] [Antelope]operating upgrade from ubuntu 20 to ubuntu 22 on infra nodes
by Danish Khan 27 May '25

27 May '25

Dear Team, I am trying to upgrade Operating system of Infra node from ubuntu 20 to ubuntu 22. And I am following below docs for same: https://docs.openstack.org/openstack-ansible/2023.1/admin/upgrades/distribu… When I run: openstack-ansible setup-hosts.yml --limit localhost,reinstalled_host* I thought it would upgrade OS of LXC containers as well. I can see ubuntu-22-amd64 in /var/lib/lxc/ and /var/lib/machines/ I can see ubuntu-22-amd64 even when I run lxc-ls command. Should I destroy and recreate lxc containers one by one to upgrade it to ubuntu 22? or is there any playbook which can take care of this? Regards, Danish Khan

2 1

[OpenStack Kolla] Unable to upload image from Horizon
by ankit1999raikwar＠gmail.com 26 May '25

26 May '25

Hello All, We have deployed the latest version of the OpenStack using the Kolla-ansible deployment. Issue description: When we are uploading image from the horizon dashboard using the with the privilege of admin or any other normal user getting below error. we are using the ceph storage as the backend. Error: Type Error: response is undefined and Unable to create Image Details: 1. From CLI I'm able to Upload the image 2. From Horizon getting Error Command Line Interface openstack image create cirros-01 --disk-format qcow2 --file cirros-0.6.2-x86_64-disk.img Output: +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | checksum | c8fc807773e5354afe61636071771906 | | container_format | bare | | created_at | 2025-05-26T05:03:04Z | | disk_format | qcow2 | | file | /v2/images/f4bba9a3-8640-4162-b9de-0b7e29d32dcf/file | | id | f4bba9a3-8640-4162-b9de-0b7e29d32dcf | | min_disk | 0 | | min_ram | 0 | | name | cirros-01 | | owner | 302edafdf0114b41acad32725668cd13 | | properties | os_hash_algo='sha512', | | | os_hash_value='1103b92ce8ad966e41235a4de260deb791ff571670c0342666c8582fbb9caefe6af07ebb11d34f44f8414b609b29c1bdf1d72ffa6faa39c88e8721d09847952b', | | | os_hidden='False', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros-01', owner_specified.openstack.sha256='', stores='rbd' | | protected | False | | schema | /v2/schemas/image | | size | 21430272 | | status | active | | tags | | | updated_at | 2025-05-26T05:03:05Z | | virtual_size | 117440512 | | visibility | shared | +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ openstack image list +--------------------------------------+-----------+--------+ | ID | Name | Status | +--------------------------------------+-----------+--------+ | 6b92f1ae-9726-469b-a350-f116c36e61d7 | cirros | active | | f4bba9a3-8640-4162-b9de-0b7e29d32dcf | cirros-01 | active | +--------------------------------------+-----------+--------+ From CLI images getting created from cli but we have notice from horizon we are getting error but also in the backend image getting queued. (kolla-venv) root@controller-01:~# openstack image list +--------------------------------------+-----------+--------+ | ID | Name | Status | +--------------------------------------+-----------+--------+ | 5f030764-af42-437d-b6ee-670218a0c4e4 | ankit | queued | | 0195c152-f2b7-42f1-91b4-5e65f7588889 | ankit | queued | | 6b92f1ae-9726-469b-a350-f116c36e61d7 | cirros | active | | f4bba9a3-8640-4162-b9de-0b7e29d32dcf | cirros-01 | active | +--------------------------------------+-----------+--------+ Queued Image (kolla-venv) root@controller-01:~# openstack image show 5f030764-af42-437d-b6ee-670218a0c4e4 +------------------+------------------------------------------------------+ | Field | Value | +------------------+------------------------------------------------------+ | container_format | bare | | created_at | 2025-05-26T05:45:02Z | | disk_format | qcow2 | | file | /v2/images/5f030764-af42-437d-b6ee-670218a0c4e4/file | | id | 5f030764-af42-437d-b6ee-670218a0c4e4 | | min_disk | 0 | | min_ram | 0 | | name | ankit | | owner | 302edafdf0114b41acad32725668cd13 | | properties | os_hidden='False' | | protected | False | | schema | /v2/schemas/image | | status | queued | | tags | | | updated_at | 2025-05-26T05:45:02Z | | visibility | shared | +------------------+------------------------------------------------------+ Active Image (kolla-venv) root@controller-01:~# openstack image show 6b92f1ae-9726-469b-a350-f116c36e61d7 +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | checksum | c8fc807773e5354afe61636071771906 | | container_format | bare | | created_at | 2025-05-26T05:02:02Z | | disk_format | qcow2 | | file | /v2/images/6b92f1ae-9726-469b-a350-f116c36e61d7/file | | id | 6b92f1ae-9726-469b-a350-f116c36e61d7 | | min_disk | 0 | | min_ram | 0 | | name | cirros | | owner | 302edafdf0114b41acad32725668cd13 | | properties | os_hash_algo='sha512', | | | os_hash_value='1103b92ce8ad966e41235a4de260deb791ff571670c0342666c8582fbb9caefe6af07ebb11d34f44f8414b609b29c1bdf1d72ffa6faa39c88e8721d09847952b', | | | os_hidden='False', owner_specified.openstack.md5='', owner_specified.openstack.object='images/cirros', owner_specified.openstack.sha256='', stores='rbd' | | protected | False | | schema | /v2/schemas/image | | size | 21430272 | | status | active | | tags | | | updated_at | 2025-05-26T05:02:03Z | | virtual_size | 117440512 | | visibility | shared | +------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Please find the horizon logs also 2025-05-26 04:53:24.723082 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "modify_image": "rule:context_is_admin or (role:member and project_id:%(project_id)s)" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:53:24.723167 warnings.warn(msg) 2025-05-26 04:53:24.732065 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "reactivate": "rule:context_is_admin or (role:member and project_id:%(project_id)s)" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:53:24.732130 warnings.warn(msg) 2025-05-26 04:53:34.669166 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "os_compute_api:os-simple-tenant-usage:show": "rule:project_reader_or_admin" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:53:34.669253 warnings.warn(msg) 2025-05-26 04:53:34.670620 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "os_compute_api:os-quota-sets:update": "rule:context_is_admin" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:53:34.670653 warnings.warn(msg) 2025-05-26 04:54:01.749398 /var/lib/kolla/venv/lib/python3.12/site-packages/openstack_dashboard/api/keystone.py:408: DeprecationWarning: Using the 'project' argument is deprecated in version '1.7.0' and will be removed in version '2.0.0', please use the 'default_project' argument instead 2025-05-26 04:54:01.749516 users = keystoneclient(request, admin=True).users.list(**kwargs) 2025-05-26 04:54:28.131860 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "deactivate": "rule:context_is_admin or (role:member and project_id:%(project_id)s)" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:54:28.131939 warnings.warn(msg) 2025-05-26 04:54:33.886717 Project switch successful for user "admin". 2025-05-26 04:54:44.853694 Forbidden: /api/glance/images/4b2517db-1352-45ed-ae87-5a6179bc3422/actions/reactivate 2025-05-26 04:54:51.522777 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "deactivate": "rule:context_is_admin or (role:member and project_id:%(project_id)s)" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 04:54:51.522876 warnings.warn(msg) 2025-05-26 04:55:07.647877 Project switch successful for user "admin". 2025-05-26 04:55:09.798541 OPENSTACK_IMAGE_BACKEND has a format "" unsupported by glance 2025-05-26 04:55:09.798708 OPENSTACK_IMAGE_BACKEND has a format "docker" unsupported by glance 2025-05-26 04:55:09.798760 OPENSTACK_IMAGE_BACKEND has a format "ova" unsupported by glance 2025-05-26 05:03:59.763647 /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_policy/policy.py:1133: UserWarning: Policy "communitize_image": "rule:context_is_admin or (role:member and project_id:%(project_id)s)" failed scope check. The token used to make the request was domain scoped but the policy requires ['project'] scope. This behavior may change in the future where using the intended scope is required 2025-05-26 05:03:59.763801 warnings.warn(msg) Please help to solve this issue. also I don't see any issue or error in the glance api logs

2 2

[neutron] Bug deputy report (week starting on May 19)
by Elvira Garcia Ruiz 26 May '25

26 May '25

Hi folks! Here you have the list of bugs reported for Neutron during last week. It’s been a busy week. There are a couple of them that I left undecided since I don’t feel knowledgeable enough about the issue. We can discuss them at the team meeting if that's ok. (19 May - 25 May) Critical --------- - https://bugs.launchpad.net/neutron/+bug/2111262 [wntp] test_attach_qos_port_to_vm_with_another_port should create VMs on different computes Fix merged by Eduardo Olivares https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/950296 High ------ - https://bugs.launchpad.net/neutron/+bug/2111272 security group delete fails with PgDelCommand.*exceeded timeout 180 seconds, cause: Result queue is empty Unassigned - https://bugs.launchpad.net/neutron/+bug/2111414 [eventlet-removal] Remove the usage of eventlet in unit tests Fix proposed by Rodolfo https://review.opendev.org/c/openstack/neutron/+/950502 - https://bugs.launchpad.net/neutron/+bug/2111417 [eventlet-removal] Remove the usage of eventlet in functional tests Fix proposed by Rodolfo https://review.opendev.org/c/openstack/neutron/+/950521 - https://bugs.launchpad.net/neutron/+bug/2111422 [eventlet-removal] Remove the usage of eventlet in fullstack tests Unassigned - https://bugs.launchpad.net/neutron/+bug/2111498 [OVN] Mechanism driver fails to fix router_ports: KeyError 'neutron:provnet-network-type' Unassigned. Set this as high but I would like to have someone else take a look at this one. - https://bugs.launchpad.net/neutron/+bug/2111593 [ovn] Race between FIP NAT entry creation and OVN port status update Fix proposed by Dmitrii Shcherbakov https://review.opendev.org/c/openstack/neutron/+/950757 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2111475 openstack network agent list cannot return new added metadata agent Fix proposed https://review.opendev.org/c/openstack/neutron/+/950624 (needs to be proposed on master) - https://bugs.launchpad.net/neutron/+bug/2111572 [OVN] OVN ML2 mech driver forces port update to networking generic switch (NGS) on OVS restart Unassigned - https://bugs.launchpad.net/neutron/+bug/2111584 Failed to get list of ports due to removed network Unassigned. I set it as low hanging fruit since the issue is quite spotted already. Low ------ - https://bugs.launchpad.net/neutron/+bug/2111330 [FT] Error in ``test_pb_type_empty`` test Unassigned Wishlist ----------- - https://bugs.launchpad.net/neutron/+bug/2111276 [RFE] Integrate OVN BGP capabilities into Neutron OVN driver Unassigned. Should be discussed in the drivers meeting. Undecided --------------- - https://bugs.launchpad.net/neutron/+bug/2111254 [ovn] distributed fip missing external_mac Unassigned. I asked froyo if he could take a look at this since the reporter encountered this on an env with octavia. - https://bugs.launchpad.net/neutron/+bug/2111496 Neutron port stuck in DOWN state after update router external connectivity Unassigned - https://bugs.launchpad.net/neutron/+bug/2111660 OVN_AGENT_NEUTRON_SB_CFG_KEY doesn't set when Neutron OVN Agent starts Unassigned Best regards, Elvira

1 0

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

26 May '25

Hello Stackers, We're 18 weeks away from the release date for OpenStack 2025.2 "Flamingo" [1]. Next week is the deadline for "cycle-trailing" [2] projects to tag their 2025.1 "Epoxy" deliverables. Elsewhere, service project teams are busy wrapping up design specifications for features expected to be implemented in this release cycle. A call to action regarding the cross-community goal on "eventlet removal" was made to this mailing list [3]. Please join the #openstack-eventlet-removal channel on OFTC and participate in the effort. Several OpenStack governance changes are currently underway. A major proposal among them is a transition [4] from the Contributor License Agreement (CLA) [5] to the Developer Certificate of Origin [6]. This change will affect every OpenStack contributor. The OpenStack Technical Committee is working with the OpenInfra Foundation and the OpenDev Infrastructure teams to enforce DCO compliance starting 2025-07-01. Please take some time to consider its implications and provide your opinions on the TC resolution [4]. Project maintainers are not expected to reject patches with DCO compliance today. If you spot a "Signed-off-by" in the commit message, there's a good chance reviewers have just looked past this, as it wasn't required so far. It's a good time to review what may be necessary and be prepared for the upcoming change [7]. === Weekly Meeting === The weekly IRC meeting of the OpenStack Technical Committee occurred on 2025-05-20 [8]. An action item regarding relinquishing the "quantum" name on PyPI was discussed. The resolution in this regard was acknowledged by the requester and merged shortly after. The OpenDev infra administrators deleted OpenStack artifacts and handed over the project namespace. The majority of the meeting later focused on the transition from CLA (Contributor License Agreement) to DCO (Developer Certificate of Origin). This move is part of a broader transition into the Linux Foundation, with an effective date of June 1, 2025. The TC needed to reconfirm its desire to move to DCO, preferably within the next two weeks, as the previous resolution on this topic was from 2014. A new resolution confirming the board's recommendation was deemed helpful for community feedback. We discussed many aspects of this transition—a key concern being the smoothness of the transition for contributors. While the technical implementation (Gerrit enforcing Signed-Off-By in commit messages and turning off CLA enforcement) is relatively simple, the human and organizational impact is not trivial. The short timeline for the switchover was a major point of contention, as downstream organizations may need to re-engage legal teams and update internal contribution policies. The possibility of having multiple CLAs active in Gerrit (allowing existing contributors to continue under the old CLA while new contributors use a new CLA for the new entity) was raised as a potential solution to mitigate the immediate impact of the short deadline. However, mixing CLA and DCO enforcement was generally seen as undesirable and hard to implement. Post-meeting, the resolution was proposed [4], and the timeline for implementation has been pushed out by a month to allow the community time to prepare and react accordingly. Please expect more communication regarding this in the next few days. The next meeting of the OpenStack TC is on 2025-05-27 at 1700 UTC. This meeting will be held over IRC on the #openstack-tc channel on OFTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us there! === Governance Proposals === ==== Merged ==== - [resolution] Relinquish "quantum" project on PyPI | https://review.opendev.org/c/openstack/governance/+/949783 ==== 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 - Fix outdated info on the tc-guide | https://review.opendev.org/c/openstack/governance/+/950446 === 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] "eventlet-removal" status: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] TC resolution to replace CLA with DCO for all contributions: https://review.opendev.org/c/openstack/governance/+/950463 [5] OpenStack CLA: https://docs.openstack.org/contributors/common/setup-gerrit.html#individual… [6] Developer Certificate of Origin: https://developercertificate.org/ [7] DCO documentation draft: https://review.opendev.org/c/openstack/contributor-guide/+/950839 [8] TC Meeting IRC Log 2025-05-20: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-20-17.00.log.html [9] TC Meeting Agenda, 2025-05-27: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

#eventlet-removal - Progress & Updates - Flamingo milestone 1
by Herve Beraud 26 May '25

26 May '25

TL;DR: We just passed the milestone 1 of Flamingo and at this point big fishes like Neutron, Nova, Glance, and Mistral demonstrated awesome progress in their migration. Oslo.service's new backend is now usable in real life use cases. Eventlet still suffers from a new version of Python. If you have not yet started your migration yet, then, please consider starting ASAP before the aircraft crash. ## OpenStack Updates Neutron's L3 agent is well on its way to running its WSGI features without using Eventlet and activating the new oslo.service threading backend at runtime. Allowing to decouple a bit more the needs of Eventlet at runtime. Nova scheduler is now able to start in threading mode without requiring any usage of Eventlet at runtime. This was possible by also shifting nova-scheduler to the threading backend of oslo.service. More details are available here https://gibizer.github.io/categories/eventlet/ Activating the new threading backend of oslo.service required devstack adaptation to allow having jobs running this execution mode. https://review.opendev.org/c/openstack/devstack/+/948436. Everybody will be able to benefit from these adaptations. Glance continues its adaptation journey by migrating its functional jobs to reduce its needs of Eventlet and to allow it to run jobs in threading mode. oslo.service's new backend is on the way to be landed soon, and is waiting for additional reviews. https://review.opendev.org/c/openstack/oslo.service/+/945720 ## Eventlet Updates Our CI was failing for almost 2 months, we were able to unlock this failing CI and hence we were able to merge several blocked reviews. Last week Eventlet 0.40.0 was released. This new version provides fixes around OpenSSL 3.5+. The support of Python 3.8 and of PyPy were removed. The Python 3.13 issues are still not solved and require further work. ## Call to Action Flamingo is a crucial series in the realization of global migration of OpenStack. We need your involvement to accelerate the progress of this initiative! If your project is affected by Eventlet, now is the time to start your migration. Teams are invited to read the migration guide available at https://removal.eventlet.org/ and are encouraged to join the #openstack-eventlet-removal IRC channel to get help. You'll benefit quickly from the advantages of running your deliverables without using Eventlet. ## Final Thoughts Postponing the beginning of the migration will put additional pressure related to growing runtime failures of Eventlet. We want to prevent this from happening to you. We are now going straight to milestone 2 meaning that we will soon be in the middle of Flamingo. The migration path is now well cleared by all the previous actions and changes applied into OpenStack. Do not be afraid by the migration and take advantage of the collected experience. Your journey start here https://removal.eventlet.org/ Thanks for reading. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 5

[tc][all] Moving from CLA to DCO for OpenInfra Contributions
by Jonathan Bryce 23 May '25

23 May '25

Hi everyone, I wanted to flag a recent message on the Foundation mailing list about the possibility to move OpenInfra projects from using the Contributor License Agreement (CLA) to the Developer Certificate of Origin (DCO) [1]. This change would be part of the broader transition into the Linux Foundation and could take effect starting June 1, 2025. It’s something the Board has supported for newer projects, and now existing projects like OpenStack have the opportunity to make the switch as well. I’m happy to join the TC meeting this week to discuss. Thanks, Jonathan 1. https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/th…

8 16

[manila] Manila Bugsquash: Focusing on Reviews
by Carlos Silva 22 May '25

22 May '25

Hello zorillas and interested stackers, Next week, the Manila team will have the first bugsquash of the Flamingo cycle. We have plenty of "In Progress" bugs, so we are planning to focus on reviews for this bugsquash. Vida (vhari) groomed the list for the bugsquash [1]. If there's a change you'd like to have some eyes on over the course of the next week, please add that to the list of changes. We will have a kick-off meeting where we'll get some reviewers to share their tricks while reviewing changes with the whole team. More details to join are available on the ICS [2]. [1] https://etherpad.opendev.org/p/manila-flamingo-m1-bugsquash [2] https://gist.github.com/silvacarloss/5a3d3a548b5a92a5425f88b086855568 Looking forward to it, carloss

1 0

[neutron] Drivers meeting canceled Friday, May 23rd
by Brian Haley 22 May '25

22 May '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as it does not look like we will have quorum. Please add things to the wiki [0] to discuss next week, we currently have one agenda item planned: * Integrate OVN BGP capabilities into Neutron OVN driver https://bugs.launchpad.net/neutron/+bug/2111276 Have a nice weekend! -Brian [0] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

[barbican] Cancel Weekly Meeting
by Mauricio Harley 22 May '25

22 May '25

Hi, guys! We need to cancel the weekly meeting that would happen on Monday the 26th. This is necessary since I'll be on PTO that day. Looking forward to meeting you all on the Monday following: June the 2nd. Best regards, Mauricio

1 0

#eventlet-removal - Announcing the New Threading Backend of oslo.service
by Herve Beraud 22 May '25

22 May '25

I'm happy to announce the new version of oslo.service is out! [1] This new version came out with the new Threading backend [2]. OpenStack Upper constraints are on the way to be upgraded to this new version [3]. You can start using the new threading backend by following the steps below: ``` import oslo_service.backend as service service.init_backend(service.BackendType.THREADING) ``` Ideally this backend selection should be made in your patcher module. Almost all OpenStack services own a household patcher. Neutron and Nova already demonstrated a successful adoption of this new backend on Nova scheduler and Neutron L3 agent: - https://review.opendev.org/c/openstack/neutron/+/938404 - https://review.opendev.org/c/openstack/nova/+/948450/17 Devstack is on the way to be adapted to allow you to set up `SYSTEMD_ENV_VARS`. [4] This will allow passing environment variables from zuul job definitions to systemd service files via the local conf. During the Eventlet removal effort this will allow teams to have separate jobs testing the same service in different concurrency modes. The first use case of this is to implement scenarios like passing variable `OS_NOVA_DISABLE_EVENTLET_PATCHING=true` to nova services that already supports running in native threading mode instead of with Eventlet. To get a more concrete integration example, you can take inspiration from Nova patches [5][6] to see how to implement your backend switch on your deliverables. A comprehensive guide is currently under creation. [7] Next steps will be to address a couple of remaining comments, to introduce functional tests, and to democratize the usages of this new backend. Thank you to Daniel for his hard work and all his efforts on this topic. Also I wanted to specially thank Gibi and Rodolfo for their close collaborations on this new backend implementation. Please join me to warmfully thank them. Our mission is to equip the community with everything it needs to leave Eventlet behind. This backend is only a tiny piece of this giant puzzle. Your turn to place your piece: https://removal.eventlet.org Cheers, [1] https://review.opendev.org/c/openstack/releases/+/950646 [2] https://review.opendev.org/c/openstack/oslo.service/+/945720 [3] https://review.opendev.org/c/openstack/requirements/+/950653 [4] https://review.opendev.org/c/openstack/devstack/+/948436 [5] https://review.opendev.org/c/openstack/nova/+/948311 [6] https://review.opendev.org/c/openstack/nova/+/948450 [7] https://review.opendev.org/c/openstack/oslo.service/+/940664 -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

"quantum" package name on pypi
by JDK Phoenix 21 May '25

21 May '25

Dear Openstack-Team, I am the creator and maintainer of the programming language "qb" (qb · PyPI <https://pypi.org/project/qb/>, qb <https://lschreiber.eu/qb/>) and I wanted to implement a package manager similar to how Maven, Cargo or Poetry works. I picked the name "quantum" for this program and noticed that this name was already in use on pypi for a package developed by you. This program has only a singular contribution in 2012 and seems to be inactive since then. I wanted to ask if it would be possible for you to transfer the quantum-package name on pypi to my user (Leander420). I would be very grateful if this could be possible. I thank you for your time and consideration Kind regards Leander S. Schreiber

6 6

Issue on IP Assignment on newly created VM after deleting old one
by sudeb ghosh 21 May '25

21 May '25

Hi Team, We are operating an OpenStack environment managed by Ansible. Openstack Version: Ussuri(21.2.1) OS: CentOS8 We had a volume backed VM named VM01 with IP of 10.10.10.10 for example. We required to delete the VM01 & recreate a VM named VM02 using the same volume. We used the same project & same network what we used for VM01 earlier. VM02 is getting any one available IPs from the given network. Manually i am able to detach the existing IP & attached the specific IP but its not pinging. Query: i) What is the option if i need the same IP(10.10.10.10) will be assigned to VM02 as well autometically? ii) What is fix to get the said old IP(10.10.10.10) working if i do attach manually in GUI through newtwork-interface? BR// Sudeb Ghosh 7044064878 9332034788

3 3

[watcher] Call for maintainers - MAAS integration
by Douglas Viroel 20 May '25

20 May '25

Hi everyone, At the last watcher's weekly meeting[1], the team discussed the impacts of the eventlet removal in Watcher's code, and it was brought up that the integration with MAAS (Metal As a Service) support is affected. At the moment, we do not have any active members in Watcher that have any experience with MAAS. CI also doesn't have any job running and testing this integration, and we don't have documentation of how it works. This is a call for maintainers interested in supporting MAAS in Watcher to help fill these gaps. It is worth mentioning that, as discussed in the PTG[2], we also plan to mark this integration as *experimental* once it does not provide minimal testing and documentation (this is also the case of other integrations). But we will cover this topic in a different thread. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-05-15-12.01… [2] https://etherpad.opendev.org/p/apr2025-ptg-watcher#L71 Thanks and regards, -- Douglas Viroel - dviroel

1 0

[ops][neutron] Neutron-db-manage upgrade from Antelope to Bobcat fails with "foreign key constraint 'porthints_ibfk_1' are incompatible" error
by federica fanzago 20 May '25

20 May '25

Dear all, we are running an OpenStack deployment Yoga on AlmaLinux 9.5 and we are attempting the upgrade Openstack up to Caracal release, one release at time (Zed--Antelope--Bobcat--Caracal) The procedure we are following is to shut down all openstack services, to remove the "old" openstack release and to install the new one, upgrading all service databases. This procedure works well for Zed and Antelope, but during the installation of the Bobcat release, the Neutron database upgrade fails when creating the new "porthints" table. The command we are using is su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron and the error message we receive is ... File "/usr/lib/python3.9/site-packages/pymysql/err.py", line 107, in raise_mysql_exception raise errorclass(errno, errval) sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (3780, "Referencing column 'port_id' and referenced column 'id' in foreign key constraint 'porthints_ibfk_1' are incompatible.") [SQL: CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB ... Our "ports" table uses the collation utf8mb3_general_ci mysql> SHOW FULL COLUMNS FROM ports; +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | project_id | varchar(255) | utf8mb3_general_ci | YES | MUL | NULL | | select,insert,update,references | | | id | varchar(36) | utf8mb3_general_ci | NO | PRI | NULL | | select,insert,update,references | | | name | varchar(255) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | | network_id | varchar(36) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | mac_address | varchar(32) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | admin_state_up | tinyint(1) | NULL | NO | | NULL | | select,insert,update,references | | | status | varchar(16) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | device_id | varchar(255) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | device_owner | varchar(255) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | standard_attr_id | bigint | NULL | NO | UNI | NULL | | select,insert,update,references | | | ip_allocation | varchar(16) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ in Bobcat the collation required for the new "porthints" table is latin1_swedish_ci MariaDB [neutron]> show create table porthints; +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | porthints | CREATE TABLE `porthints` ( `port_id` varchar(36) NOT NULL, `hints` varchar(4095) NOT NULL, PRIMARY KEY (`port_id`), CONSTRAINT `porthints_ibfk_1` FOREIGN KEY (`port_id`) REFERENCES `ports` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci | So, we have tried to create the porthints table in mysql, forcing the collation to utf8mb3_general_ci mysql> CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB DEFAULT CHARSET=utf8 DEFAULT COLLATE utf8mb3_general_ci; and commenting out the creation of the new table in the neutron code /usr/lib/python3.9/site-packages/neutron/db/migration/alembic_migrations/versions/2023.2/expand/6f1145bff34c_port_hints.py. In this way, the upgrade works, but we encounter the same kind of problem during the upgrade to Caracal, specifically with the creation of the new table porthardwareoffloadtype. Have you already encountered this issue during the Neutron upgrade? Do you have any suggestions on how to upgrade the neutron DB, without manually creating new tables? Thanks a lot, cheers, Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

4 8

Osprofiler and nova
by engineer2024 20 May '25

20 May '25

Team, I am facing an issue with osprofiler in nova, where the 'trace show' is failing. I have filed a bug at https://bugs.launchpad.net/osprofiler/+bug/2111345 But I don't see any recent activity there. Is the osprofiler project active ? Please guide me as per the issue mentioned there... Thanks elinux

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - May 21st at 0700 UTC
by Felix Kronlage-Dammers 20 May '25

20 May '25

Hi everyone, This upcoming Wednesday (May 21st - 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 See you tomorrow! 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

CEPH deployment method: cephadm vs puppet
by Francesco Di Nucci 20 May '25

20 May '25

Hi all, we're planning (finally) to setup a CEPH cluster to be used as OpenStack backend. The cloud is actually set up with Foreman+Puppet, to setup CEPH what would you advice? cephadm as it's the preferred method in the CEPH docs or Puppet with the puppet-ceph module, as it's part of openstack? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

6 14

[Patch Management] [Openstack-2024.1 (caracal)]
by Shalini Srivastava 20 May '25

20 May '25

Hello Sir/Ma'am, I need to implement Security update that is Patch management, Vulnerability Management to my Openstack environment that is 2024.1 (Caracal release). The services needs to upgrade as well as update according to the upper constraints available for the given release. Please guide me the steps/procedure for the same. Hope to hear from you soon. Thanks & Regards, Shalini Srivastava Project Associate /प्रोजेक्ट एसोसिएट Centre for Development of Advanced Computing(C-DAC) / प्रगत संगणन विकास केन्द्र(सी-डैक) Tidel Park”, 8th Floor, “D” Block, (North &South) / “टाइडल पार्क”,8वीं मंजिल, “डी” ब्लॉक, (उत्तर और दक्षिण) No.4, Rajiv Gandhi Salai / नं.4, राजीव गांधी सलाई Taramani / तारामणि Chennai / चेन्नई – 600113 Ph.No.:044-22542226/27 Fax No.: 044-22542294 ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------

1 0

Guidance related to [Patch Management] [Openstack-2024.1 (caracal)]
by Shalini Srivastava 20 May '25

20 May '25

Hello Sir/Ma'am, I need to implement a Security update that is Patch management, Vulnerability Management to my Openstack environment that is 2024.1 (Caracal release). The services need to upgrade as well as update according to the upper constraints available for the given release. Please guide me the steps/procedure for the same. Hope to hear from you soon. Thanks & Regards, *Shalini Srivastava* Project Associate /प्रोजेक्ट एसोसिएट Centre for Development of Advanced Computing(C-DAC) / प्रगत संगणन विकास केन्द्र(सी-डैक) Tidel Park”, 8th Floor, “D” Block, (North &South) / “टाइडल पार्क”,8वीं मंजिल, “डी” ब्लॉक, (उत्तर और दक्षिण) No.4, Rajiv Gandhi Salai / नं.4, राजीव गांधी सलाई Taramani / तारामणि Chennai / चेन्नई – 600113 Ph.No.:044-22542226/27 Fax No.: 044-22542294

1 0

[magnum] April vPTG summary and Magnum meeting time change
by Dale Smith 20 May '25

20 May '25

Hello all, I wanted to post a short summary to this list of the vPTG[1] the Magnum team held on April 8th and 9th 2025. These are the topics and a summary of my notes from the discussions. If I missed key details please add these to the etherpad and/or reply here. Thank you all for attending. Please get in touch if the timing of the vPTG did not work for you, as we could propose multiple timezone slots in future. * Heat driver deprecation. o This driver is marked deprecated in Dalmation 2025.1, being replaced by either of the Cluster API drivers, and we discussed when and how we will remove it from Magnum codebase. o We are now looking at removing the Heat driver in this (Flamingo 2025.2) cycle, as waiting longer may imply waiting until 2026.2 due to SLURP release expectations. We would like to hear any feedback on this plan from users of Magnum - either in the mailing list or join one of our IRC meetings[2]. o One option is to move the driver out of tree into its own codebase (perhaps in `x/`), to allow deployers to keep their existing clusters functional and addressable by Magnum while transitioning to a Cluster API driver. This initiative needs effort and a champion to drive it. * Helm charts (magnum-capi-helm driver) o While the driver code is now in opendev the Helm charts live in azimuth-cloud's github. These are a major component of the driver and we discussed the reasoning behind keeping them in github and stability of the Magnum-capi-helm driver. o The current proposal is to snapshot the upstream repo at regular intervals into the opendev repo. This avoids maintenance of a complete fork, but keeps the Magnum-capi-helm driver with a stable internal reference of the helm charts. * CI for the Magnum project was discussed o One big implication of the Heat driver being removed is what we test against. o Including the CAPI drivers (initially non-voting) would give stability, provided external changes wouldn't break the CI. * Normalised labels proposal o Dale has a proposal for Normalised labels[3], aiming for Mutable labels. The video format discussion of the vPTG was very helpful to give context and move the idea forward to cover API backwards compatibility requirements and a better way to implement support labels for different drivers. o The proposal as it stands should be re-worked to look at covering a similar extension pattern that Nova has with drivers, and possibly look to replace labels. * TC initiatives o We discussed the upcoming Eventlet removal and as we are a small team we will wait for guidance and examples to follow before implementing, but we remain aware of this initiative. Finally, I wanted to announce to the list that at last weeks Magnum IRC meeting we proposed and agreed on a new time slot. This is on alternate (every second) Tuesday at 8am UTC starting on the 27th May[2]. See the meeting notes for a full transcript and discussion[4]. Links and references: [1] Magnum vPTG topics and notes can be found on https://etherpad.opendev.org/p/apr2025-ptg-magnum [2] Magnum weekly meeting times and agenda, https://etherpad.openstack.org/p/magnum-weekly-meeting [3] Normalisation of labels proposal, https://review.opendev.org/c/openstack/magnum-specs/+/943358 [4] Magnum meeting 2025-05-14, https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-14-09.00.l… Thank you for reading! (or skim reading!) Dale Smith Magnum PTL for Epoxy cycle.

1 0

[adjutant] Adding Callum Dickinson to core group
by Dale Smith 19 May '25

19 May '25

Hello all, The project Adjutant is adding Callum Dickinson to the core group. Callum has contributed features, bugfixes and reviews code in the Adjutant project. I want to note that both of us are from the same company, Catalyst Cloud, and keeping the project alive by using it internally. We will always welcome other contributors, and don't want to keep this project exclusive. regards, Dale, Adjutant PTL -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 0

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

19 May '25

Hello Stackers, We are 19 weeks away from the release date for OpenStack 2025.2 "Flamingo" [1]. Last week, election officials published the combined TC and PTL election schedule targeting the next release cycle [2]. We are setting up our election configuration early to ensure that community members have adequate time to propose and deliberate nominations. The elections themselves will occur in August 2025, and the official nominations window opens on 2025-08-06 (week R-8). However, you are welcome to submit your candidacy early in case you anticipate being away. Please note that your nomination will not be merged until the nomination window opens. This election is also an opportunity for OpenStack project teams to modify their leadership model if they choose. All project teams with "distributed" project leadership will be required to update their liaisons or assert that no change is necessary by week R-8. Please await changes from the TC on Gerrit to do so. No further governance changes were made last week; however, a few proposals are open for review. === Weekly Meeting === The weekly IRC meeting of the OpenStack Technical Committee occurred on 2025-05-13 [3]. A lot of progress was made in the past few weeks with regard to action items that we were tracking from our Project Team Gathering in April. We discussed a proposal [4] to require a declaration of affiliation when contesting TC elections and how that would apply to current TC members. The proposal seeks to enhance transparency and allow voters to make more informed choices since the TC has an affiliation diversity requirement [5] that is enforced when adopting the results of an election. Concerns were raised about potential misinterpretations regarding company influence and the perception of OpenStack's governance. It was recommended that we add specific disclaimers as to why the affiliation is declared on our governance pages after this proposal has been adopted. We also socialized the kick-off for the 2026.1 elections. I will be serving as the TC's election liaison and helping our election officials Slawek Kaplonski (slaweq) and Ian Y Choi (ianychoi). We discussed the state of the CI, bringing the TC up to speed on several cross-community CI efforts. The next meeting of the OpenStack TC is on 2025-05-20 at 1700 UTC. This meeting will be held over IRC on the #openstack-tc channel on OFTC. Please find the agenda and other details in the meeting's wiki page [6]. I hope you will be able to join us there! === Governance Proposals === === Open for review === - [resolution] Relinquish "quantum" project on PyPI | https://review.opendev.org/c/openstack/governance/+/949783 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Clarify actions when no elections are required | https://review.opendev.org/c/openstack/governance/+/949431 === Upcoming Events === - 2025-05-22: OpenInfra UG Meetup, Sweden: https://www.meetup.com/openinfra-user-group-sweden/events/306139678/ - 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] 2026.1 TC+PTL Elections: https://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-05-13: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-13-17.00.html [4] Require declaration of affiliation from TC Candidates: https://review.opendev.org/c/openstack/governance/+/949432 [5] OpenStack TC's affiliation diversity requirement: https://governance.openstack.org/tc/reference/charter.html#tc-diversity-req… [6] TC Meeting Agenda, 2025-05-20: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic] No meeting May 26, 2025
by Jay Faulkner 19 May '25

19 May '25

Hi all, We're cancelling the meeting for next Monday, May 26, due to it overlapping with the US Memorial Day holiday. Thanks, Jay Faulkner Ironic Security Liason

1 0

Guidance related to Patch Management in Openstack-2024.1 (caracal)
by Shalini Srivastava 19 May '25

19 May '25

Hello Sir, I need to implement Security update that is Patch management, Vulnerability Management to my Openstack environment that is 2024.1 (Caracal release). The services needs to upgrade as well as update according to the upper constraints available for the given release. Please guide me the steps/procedure for the same. Hope to hear from you soon. Thanks & Regards, Shalini Srivastava Project Associate /प्रोजेक्ट एसोसिएट Centre for Development of Advanced Computing(C-DAC) / प्रगत संगणन विकास केन्द्र(सी-डैक) Tidel Park”, 8th Floor, “D” Block, (North &South) / “टाइडल पार्क”,8वीं मंजिल, “डी” ब्लॉक, (उत्तर और दक्षिण) No.4, Rajiv Gandhi Salai / नं.4, राजीव गांधी सलाई Taramani / तारामणि Chennai / चेन्नई – 600113 Ph.No.:044-22542226/27 Fax No.: 044-22542294 ------------------------------------------------------------------------------------------------------------ [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------------------------------------------------------------------------------------

1 0

[neutron] Bug deputy report (week starting on May 12)
by Bernard Cafarelli 19 May '25

19 May '25

Hey neutrinos, here is the list of bugs reported last week Overall a quiet week, bugs are assigned with proposed (or merged already) patch, except a CI failure report (no immediate action needed, mostly for tracking if the failure reappears) High * Neutron endpoint options are not applied - https://bugs.launchpad.net/neutron/+bug/2110488 ovn-octavia-provider similar to a fixed Octavia issue, proposed updated patch by priteau: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/925893 * "neutron-tempest-plugin-designate-scenario-zed" job failing - https://bugs.launchpad.net/neutron/+bug/2110550 Needed to pin the tempest plugin to zed-last, fix by ralonsoh merged: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/949643 Medium * occasional functional test failure: neutron.tests.functional.privileged.agent.linux.test_utils.FindListenPidsNamespaceTestCase.test_find_listen_pids_namespace - https://bugs.launchpad.net/neutron/+bug/2110878 CI failure but seen once in gate for now * ovs-agent: Leftover tpi/spi interfaces after VM boot/delete with trunk port(s) - https://bugs.launchpad.net/neutron/+bug/2095152 Trunk ports leftover for ML2/OVS following a change for ML2/OVN, see bug for details (reproducer) Patch proposed by rubasov: https://review.opendev.org/c/openstack/neutron/+/949217 -- Bernard Cafarelli

1 0

[openstack-helm] Are there any real users of the umbrella chart?
by Vladimir Kozhukalov 17 May '25

17 May '25

Hi team, This is to start the discussion about the future of the Openstack super (umbrella) chart [1]. My personal impression (maybe I am wrong) is that this chart is of extremely little interest. We continue to maintain this code (and spend testing resources) but maybe there are no real users of it. The chart deploys a compute-kit scheme but the same result can be achieved if one deploys multiple separate charts one-by-one. It seems convenient to have this single super chart that deploys Openstack with a single command, but IMO even small operators prefer using separate charts. Having said that, I would suggest removing this chart if it is not needed. [1] https://opendev.org/openstack/openstack-helm/src/branch/master/openstack -- Best regards, Kozhukalov Vladimir

3 4

[nova] Auto-convergence but for I/O
by Winicius Allan 17 May '25

17 May '25

Is there any option for disk I/O auto-convergence like conf.libvirt.live_migration_permit_auto_converg for memory-intensive instances? The use case is for an I/O intensive VM, so the disk cannot be migrated. Instead, it is necessary to change the max IO with `$ virsh blkdeviotune` then, migrate the instance and replace the current value with the old using the same command. regards.

2 1

[release] Release countdown for week R-19
by Thierry Carrez 16 May '25

16 May '25

Development Focus ----------------- We are now past the Flamingo-1 milestone. Teams should now be focused on feature development and completion of goals [0]. [0] https://governance.openstack.org/tc/goals/selected/index.html General Information ------------------- Our next milestone in this development cycle will be Flamingo-2, on July 3rd, 2025. This milestone is when we freeze the list of deliverables that will be included in the 2025.2 Flamingo final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/flamingo directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Flamingo-2 Milestone: July 3rd, 2025 -- Thierry Carrez (ttx)

1 0

[Kolla-Ansible][DockerImages] - Failing at start
by Victor Sartori 16 May '25

16 May '25

Hello All, Some containers are failing to start. All of them exhibit the same behavior: ``` + echo 'Running command: '\''uwsgi /etc/nova/nova-api-uwsgi.ini'\''' Running command: 'uwsgi /etc/nova/nova-api-uwsgi.ini' + exec uwsgi /etc/nova/nova-api-uwsgi.ini /usr/local/bin/kolla_start: line 27: exec: uwsgi: not found ``` Could this issue be related to a message posted in the OpenStack IRC? ``` -opendevstatus/#openstack- NOTICE: Setuptools 80.7.0 broke python package installs for many, affecting CI jobs. That release has been yanked, and it should be safe to recheck failed changes. ``` I see errors in the following containers: - quay.io/openstack.kolla/nova-scheduler:2024.2-ubuntu-noble - quay.io/openstack.kolla/placement-api:2024.2-ubuntu-noble - quay.io/openstack.kolla/cinder-volume:2024.2-ubuntu-noble It's likely that any container relying on uwsgi will fail. Environment: Ubuntu 24.04.2 Kernel 6.8.0-59-generic Docker CE 28.1.1 Kolla version: kolla-ansible 20.1.0.dev10 Any help?

1 0

[Kolla-Ansible][Magnum] Vexxhost CAPI no longer working
by Oliver Weinmann 16 May '25

16 May '25

Hi all, a couple of weeks ago I updated the containers in my 2023.2 release. kolla-ansible pull kolla-ansible deploy since then the Vexxhost driver in Magnum is no longer working. I have clusters stuck in provisioning and deleting: $ kubectl get cluster -A NAMESPACE NAME CLUSTERCLASS PHASE AGE VERSION magnum-system kube-6r0du magnum-v0.26.0 Provisioning 20d v1.26.7 magnum-system kube-7ljg3 magnum-v0.26.0 Provisioning 18d v1.26.7 magnum-system kube-csf6s magnum-v0.13.4 Deleting 71d v1.26.7 I believe this is due to a versionn mismatch. Many different tools are involved here. All pods in the KIND Management cluster are running: $ kubectl -n kube-system get pods NAME READY STATUS RESTARTS AGE coredns-76f75df574-lfckv 1/1 Running 5 (2d23h ago) 71d coredns-76f75df574-n85fv 1/1 Running 5 (2d23h ago) 71d etcd-magnumcapi-control-plane 1/1 Running 5 (2d23h ago) 71d kindnet-jtdtm 1/1 Running 5 (2d23h ago) 71d kube-apiserver-magnumcapi-control-plane 1/1 Running 5 (2d23h ago) 71d kube-controller-manager-magnumcapi-control-plane 1/1 Running 10 (2d23h ago) 71d kube-proxy-qwjc8 1/1 Running 5 (2d23h ago) 71d kube-scheduler-magnumcapi-control-plane 1/1 Running 9 (2d23h ago) 71d There is nothing obvious in the capi or capo logs. Is there someone that is currently running 2023.2 or newer with the Vexxhost CAPI driver? Would be great if you could share the versions of: Management Cluster $ kind --version kind version 0.22.0 $ export KUBECONFIG=~/config $ kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME magnumcapi-control-plane Ready control-plane 71d v1.29.2 172.18.0.2 <none> Debian GNU/Linux 12 (bookworm) 5.14.0-503.38.1.el9_5.x86_64 containerd://1.7.13 $ kubectl get provider -A NAMESPACE NAME AGE TYPE PROVIDER VERSION capi-kubeadm-bootstrap-system bootstrap-kubeadm 71d BootstrapProvider kubeadm v1.9.5 capi-kubeadm-control-plane-system control-plane-kubeadm 71d ControlPlaneProvider kubeadm v1.9.5 capi-system cluster-api 71d CoreProvider cluster-api v1.9.5 capo-system infrastructure-openstack 71d InfrastructureProvider openstack v0.10.8 The magnum pods: ~]# podman exec -it magnum_conductor bash ()[ /]$ pip list | grep api magnum-cluster-api 0.26.0 ()[ /]$ helm version version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.20.10"} ~]# podman exec -it magnum_api bash ()[ /]$ pip list | grep api magnum-cluster-api 0.26.0 ()[ /]$ helm version version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.20.10"} ()[ /]$ Cheers, Oliver

1 0

[neutron] Neutron drivers meeting cancelled today
by Rodolfo Alonso Hernandez 16 May '25

16 May '25

Hello Neutrinos: Due to the lack of agenda [1], today's meeting is cancelled. Have a nice weekend! [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda

1 0

[openstack][neutron] Using external network for another project
by Nguyễn Hữu Khôi 15 May '25

15 May '25

Hello. I created an external network for a specified project but I cannot create instances with the external network on this tenant. I must create RBAC Policies with shared and external policies then my instances can get IP addresses and run properly. Is it normal? Pls correct me if I am wrong Thank you. Nguyen Huu Khoi

6 19

[neutron][ml2/ovn] unintended changes in trunk status ACTIVE
by Bence Romsics 15 May '25

15 May '25

Hi Neutron Team, A heads up to OVN folks: We believe we have a problem in Neutron that we move a trunk to ACTIVE status too early (changing the meaning of status=ACTIVE) - already after its parent port is updated to ACTIVE instead of waiting for all of its ports (parent and sub) to be processed. We discovered this while working on this bug: https://bugs.launchpad.net/neutron/+bug/2095152 The problem was introduced by this patch: https://review.opendev.org/c/openstack/neutron/+/853779 Which was intended to be a fix for ml2/ovn leaving a trunk in DOWN after live migration. However that patch affected all backends. And affected not just live migration, but create too. We have proposed the following patch to limit the effect to ml2/ovn (but did not yet find a way to avoid affecting create): https://review.opendev.org/c/openstack/neutron/+/949217 However due to ml2/ovn's handling of trunk subports (not cascading the parent's binding:host update to all subports in the neutron api layer) I don't know how this should be fixed for ml2/ovn. Maybe a clever wait in the OVN databases could solve this. People with better OVN knowledge may want look into this. You're also welcome to review our proposed patches, including this os-vif change to prevent a resource leak in ml2/ovs when a trunk is already deleted on server side when the agent is still processing its create: https://review.opendev.org/c/openstack/os-vif/+/949736 Thanks, Bence (rubasov)

1 0