May 2025 - openstack-discuss - lists.openstack.org

[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

Inquiry About Cloud applications Deployment Methods and Current Best Practices
by Saranraj M 15 May '25

15 May '25

Dear OpenStack Community, I hope this message finds you well. I am currently exploring OpenStack deployment strategies for our infrastructure and wanted to reach out to the community for guidance. Could you kindly share insights on the different deployment methods commonly used within the OpenStack ecosystem (e.g., DevStack, Kolla-Ansible, TripleO, etc.)? Additionally, I would like to understand which method is currently most preferred or widely adopted in production environments, along with any pros and cons you've experienced. Your input will be highly valuable in helping us choose the right path for our deployment. Looking forward to your recommendations and experiences. Thanks & Regards Associate Software Engineer Saranraj.M Ph No: (+91) 9360409252 Email: mailto:saranraj.m@zybisys.com Zybisys Consulting LLP | NSA Tower, No. 1B Akila Nagar, Thiruvanaikoil, Tamilnadu, Trichy, India-620005 http://zybisys.com/ ReplyReply AllForwardEdit as new Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

3 2

[horizon][memcached]
by Kamil Madac 14 May '25

14 May '25

I have deployed openstack 2024.2 with kolla-ansible in HA setup with 3 control nodes. Everything works without issues, but when I stop memcached node with IP address 192.168.56.12 (or when node goes down), it is not possible to login to Horizon with error message: Something went wrong! An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator. In horizon log I have an error message: 2025-05-12 18:05:37.406588 Internal Server Error: / 2025-05-12 18:05:37.406613 Traceback (most recent call last): 2025-05-12 18:05:37.406615 File "/var/lib/kolla/venv/lib64/python3.9/site-packages/django/core/handlers/exception.py", line 55, in inner 2025-05-12 18:05:37.406617 response = get_response(request) 2025-05-12 18:05:37.406619 File "/var/lib/kolla/venv/lib/python3.9/site-packages/horizon/middleware/simultaneous_sessions.py", line 30, in __call__ 2025-05-12 18:05:37.406621 self._process_request(request) 2025-05-12 18:05:37.406623 File "/var/lib/kolla/venv/lib/python3.9/site-packages/horizon/middleware/simultaneous_sessions.py", line 37, in _process_request 2025-05-12 18:05:37.406625 cache_value = cache.get(cache_key) 2025-05-12 18:05:37.406627 File "/var/lib/kolla/venv/lib64/python3.9/site-packages/django/core/cache/backends/memcached.py", line 75, in get 2025-05-12 18:05:37.406628 return self._cache.get(key, default) 2025-05-12 18:05:37.406630 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 347, in get 2025-05-12 18:05:37.406632 return self._run_cmd("get", key, default, default=default, **kwargs) 2025-05-12 18:05:37.406634 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 322, in _run_cmd 2025-05-12 18:05:37.406636 return self._safely_run_func(client, func, default_val, *args, **kwargs) 2025-05-12 18:05:37.406637 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/hash.py", line 199, in _safely_run_func 2025-05-12 18:05:37.406639 result = func(*args, **kwargs) 2025-05-12 18:05:37.406640 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 687, in get 2025-05-12 18:05:37.406642 return self._fetch_cmd(b"get", [key], False, key_prefix=self.key_prefix).get( 2025-05-12 18:05:37.406644 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 1133, in _fetch_cmd 2025-05-12 18:05:37.406645 self._connect() 2025-05-12 18:05:37.406647 File "/var/lib/kolla/venv/lib/python3.9/site-packages/pymemcache/client/base.py", line 424, in _connect 2025-05-12 18:05:37.406648 sock.connect(sockaddr) 2025-05-12 18:05:37.406650 ConnectionRefusedError: [Errno 111] Connection refused so horizon tries to connect to memcached node which is down. I have default kolla-ansible config with enabled memcached and horizon config is following: SESSION_ENGINE = 'django.contrib.sessions.backends.cache' CACHES['default']['LOCATION'] = ['192.168.56.11:11211','192.168.56.12:11211 ','192.168.56.21:11211'] When I stop any other memcached node, horizon is working without issues. Why is that exact node important for the horizon? Does anyone else have the same experience? Thanks for any advice. -- Kamil Madac

4 6

[nova] os-traits release?
by Michael Still 13 May '25

13 May '25

Hi, I tried on IRC but it didn't work out. I realised the other day that I still need an os-traits release for the sound and USB traits that I added a while ago in support of my VDI work. I need those to land before I can really do much more in Nova with the VDI patches. I looked at proposing a release myself, but I couldn't find any documentation on how to actually run the tools for a release independent release. So... Either are there docs on how to do that thing, or could someone do it for me? Thanks, Michael

2 1

[tempest][swift][ceph][radosgw] debugging intermittent failures of test_upload_too_many_objects
by Michael Sherman 13 May '25

13 May '25

In our clouds, we're using ceph rgw to provide the s3 and swift object store interfaces. Recently, we began running non-admin tempest smoke tests against the live clouds, and observe intermittent failures for the object store test_upload_too_many_objects test, where the rgw seemingly fails to enforce the number of objects quota. Tempest is running on the most recent master commit, cloud deployed via Kolla ansible 2023.1, and ceph currently on Pacific, deployed via cephadm. It's not a critical issue in our case, but I'd like some advice on getting to the bottom of it. Thanks! Mike Sherman

1 0

[oslo] Request to merge the new threading backend in oslo.service.
by Daniel Bengtsson 13 May '25

13 May '25

Hi everyone, Hope you’re all doing well! Just a quick note regarding the current patch for the new threading backend in oslo.service. I have already made a few updates, like: • Adding an issues section to the release note • Renaming the [extras] entry in setup.cfg for clarity For the remaining suggestions, I was wondering if you’d be open to merging the current implementation as-is so the new backend is available and then I can follow up with smaller patches. I’m planning to open a few tickets for: • Merging the common files into one • Adding functional tests • Adding a get_backend_type() helper • And more refinements There doesn’t seem to be anything blocking at this point, and nothing that would impact the API or design significantly. Also, from a functional point of view, we’ve already seen successful results when running this in Nova. Let me know what you think and thanks again for all the feedback and reviews! -- Daniel Bengtsson Software engineer

1 1

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

13 May '25

Hello Stackers, We're at milestone-1 of the 2025.2 "Flamingo" release cycle [1]. This bug-targeting deadline is usually also a good checkpoint to review design specifications, plan feature reviews, and request releases of libraries and clients. In the past week, members of the OpenStack Technical Committee participated in a meeting to review guidelines for the use of Artificial Intelligence to make code/documentation contributions to OpenInfra projects. The meeting [2] focused on improving the current policy for AI-generated content [3], reacting to recent developments. The use of generative/predictive/agentic AI tools is pervasive in our field, and it may be untenable to impose blanket restrictions. So there were some suggestions around situations of use with interesting perspectives. The OpenInfra Board will continue to deliberate this, and your opinions are welcome. TC members also participated in the OpenInfra AI working group [4] meeting where FPT SmartCloud shared their experience running an OpenStack cloud purpose-built for AI workloads. Details regarding this meeting and future meetings are available on the OpenInfra AI WG mailing list [5]—do consider joining. There were no new governance changes merged last week, but several are currently under review. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held simultaneously over video [6] and IRC [7] on 2025-05-06. We discussed follow-ups to the resolution to extend the scope of the OpenStack Vulnerability Management Team [8]. We also continued our discussion about the sustainability of OpenStack Special Interest Groups [9] from the past week. SIGs require far less structure compared to project teams, and this is by design. However, there is a lack of information on how one can join many of the SIGs we have. An obvious way would be to reach out to the chairs listed on the SIG. However, in several cases, the chairs are no longer running the SIGs. There's community interest in several SIGs, so the TC intends to health-check each of the SIGs over this release cycle and brainstorm ways to improve their visibility and onboarding practices. We then moved on to a topic from the PTG about improving the contributor experience. The TC is focusing on improving the asynchronous workflow for a better developer experience. Members identified several pitfalls: - Onboarding to projects is difficult even for experienced contributors new to a repo -Many teams do not hold meetings they advertise - Patches often receive no reviews, and asking for reviews on IRC can be discouraging - Contributors are unsure who to ping for reviews This is an ongoing topic of discussion for us, and we don't have resolutions yet; however, project teams are encouraged to audit their contributor landing pages (we coyly called these "So you want to contribute...") to ensure they are up to date with information on how contributors can work with project maintainers. I'd also like to remind you that Jeremy Stanley (fungi) shared two surveys to this mailing list that could use your input as contributors [10] and project maintainers [11]. Having the information sought in these surveys will be crucial for us to improve the community and keep the OpenStack community sustainable. Please take these surveys and share them! The next weekly meeting of the OpenStack Technical Committee is today, 2025-05-13. This meeting will be held in the #openstack-tc channel on OFTC at 1700 UTC. Please find the agenda and other details on the meeting's wiki page [12]. I hope you're able to join us. === Governance Proposals === === Open for review === - Clarify actions when no elections are required | https://review.opendev.org/c/openstack/governance/+/949431 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-05-13: OpenInfra Board Meeting: https://board.openinfra.org/ - 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 === How to Contact the TC === You can reach the TC in several ways: - Email: send an email with the tag [tc] on this mailing list. - Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1700 UTC [12]. 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] OpenInfra Board AI policy discussion: https://etherpad.opendev.org/p/r.371b1778a41036df1fa609f9d3d777d5 [3] OpenInfra AI policy: https://openinfra.org/legal/ai-policy [4] OpenInfra AI WG etherpad: https://etherpad.opendev.org/p/OpenInfra_AI [5] OpenInfra AI WG Mailing List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] TC Meeting Video Recording, 2025-05-06: https://youtu.be/tBREaHLwp7Y [7] TC Meeting IRC Log 2025-05-06: https://meetings.opendev.org/meetings/tc/2025/tc.2025-05-06-17.00.html [8] TC's VMT scope expansion resolution: https://governance.openstack.org/tc/resolutions/20250317-extend-scope-VMT-c… [9] OpenStack SIGs: https://governance.openstack.org/sigs/ [10] OpenStack Contributor Satisfaction Survey: https://openinfrafoundation.formstack.com/forms/openstack_contributor_satis… [11] OpenStack Maintainer Satisfaction Survey: https://openinfrafoundation.formstack.com/forms/openstack_maintainer_satisf… [12] TC Meeting Agenda, 2025-05-13: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[Neutron] Bug Report May 5 - May 11
by Miro Tomaska 12 May '25

12 May '25

Hello All, I was the bug deputy for the week of May 5. We had a few bugs, some are already triaged and assigned. I have three bugs to discuss with the group on Tuesday. High: https://bugs.launchpad.net/neutron/+bug/2110060 - OVN router flavors create OVN router on Neutron restart . Confirmed Assigned: Miguel Lavalle https://bugs.launchpad.net/neutron/+bug/2110191 - Ubuntu Focal 20.04 support expired Assigned: Rodolfo https://bugs.launchpad.net/neutron/+bug/2110004 - neutron-functional time outs Assigned: Yatin Karel Medium: https://bugs.launchpad.net/neutron/+bug/2110018 - [OVN] FIP QoS and router QoS have the same priority Assigned: Rodolfo Alonso https://bugs.launchpad.net/neutron/+bug/2110094 - OVN AgentCache get_agents method filters agents incorrectly if hostname overlaps Unassigned Further Discussion: https://bugs.launchpad.net/neutron/+bug/2110225 - FIPs associated with VIPs across different routers - The described behavior does not seem like a bug to me but maybe we can discuss it as a feature? https://bugs.launchpad.net/neutron/+bug/2110087 - OVN log plugin merges log records from different log objects across projects. Not sure if bug or maybe just product improvement https://bugs.launchpad.net/neutron/+bug/2110306 - [RFE][OVN] subnet onboarding is not supported -- Miro Tomaska

1 0

[kolla-ansible][openid connect] You are not authorized to perform the requested action
by hobyte＠posteo.de 10 May '25

10 May '25

Hello, I don't know if this is the right place to ask for help - if not, please direct me to the right place. I have setup kolla-ansible on a single node following the quick start guide [0]. It works fine for a first deployment. I used the stable/2024.2 branch of the kolla-ansible and set the openstack version to 2024.2 in my configuration: globals.yml: --- openstack_region_name: "Kolla-1" openstack_release: 2024.2 kolla_base_distro: "ubuntu" kolla_internal_vip_address: "192.168.122.17" network_interface: "enp1s0" neutron_external_interface: "enp7s0" openstack_logging_debug: "True" --- Now I want to configure identity federation with keycloak as the idp, following the kolla-ansible guide [1]. Logging in with keycloak works, but when returning back to openstack, I get stuck at this url with an error 403: http://192.168.122.17:5000/v3/auth/OS-FEDERATION/identity_providers/keycloa… { "error": { "code": 403, "message": "You are not authorized to perform the requested action.", "title": "Forbidden" } } This is my kolla-ansible configuration for oidc: globals.yml: --- keystone_identity_providers: - name: "keycloak" openstack_domain: "federated_domain" protocol: "openid" identifier: "https://key.example.de/realms/master/" public_name: "keycloak" attribute_mapping: "attribute_mapping_keycloak" metadata_folder: "/etc/kolla/openid/meta-idp" keystone_identity_mappings: - name: "attribute_mapping_keycloak" file: "/etc/kolla/openid/attribute_mapping.json" --- attribute_mapping.json: --- [ { "local": [ { "user": { "name": "{0}", "email": "{1}" }, "group": { "domain": { "name": "federated_domain" }, "name": "federated_users" } } ], "remote": [ { "type": "OIDC-preferred_username" }, { "type": "OIDC-email" } ] } ] --- In the keystone logs, I see this error, but It dosn't make any sense to me. The user is not created in openstack. So I think my mapping is wrong. But from the logs I cannot see if this is the case or if the error is somewhere else. Is it possible to check my mapping or increase the log verbosity so I can track down the error? Or do I have an error in my attribute mapping I need to fix? Cheers Simon keystone.log: --- DEBUG keystone.federation.utils [None req-26e43c00-13ef-4528-916b-01f02d913bdd - - - - - -] Environment variables: {'OIDC-exp': '1746908921', 'OIDC-iat': '1746908021', 'OIDC-auth_time': '1746908021', 'OIDC-jti': 'e95091d5-917f-476e-9c3b-a3bc9781273a', 'OIDC-iss': 'https://key.example.de/realms/master', 'OIDC-aud': 'kolla-1', 'OIDC-sub': '66cb0e3b-6f36-4a9a-a3e5-dff3a101c50b', 'OIDC-typ': 'ID', 'OIDC-azp': 'kolla-1', 'OIDC-nonce': 'WLn2ZbbbzEFXMkX_K0A4AtSqzEV34SicOMgQihdnt9w', 'OIDC-sid': '1c6e9a63-aea1-48c9-a88d-9a797c360527', 'OIDC-acr': '1', 'OIDC-s_hash': 'jmyNoQjZObpgJOA4HXGhxg', 'OIDC-email_verified': '1', 'OIDC-name': 'benutzer-eins user', 'OIDC-preferred_username': 'benutzer-eins', 'OIDC-given_name': 'benutzer-eins', 'OIDC-family_name': 'user', 'OIDC-email': 'benutzer-eins(a)example.com', 'GATEWAY_INTERFACE': 'CGI/1.1', 'SERVER_PROTOCOL': 'HTTP/1.1', 'REQUEST_METHOD': 'GET', 'QUERY_STRING': 'origin=http://192.168.122.17/auth/websso/', 'REQUEST_URI': '/v3/auth/OS-FEDERATION/identity_providers/keycloak/protocols/openid/websso?origin=http://192.168.122.17/auth/websso/', 'SCRIPT_NAME': '', 'PATH_INFO': '/v3/auth/OS-FEDERATION/identity_providers/keycloak/protocols/openid/websso', 'PATH_TRANSLATED': '/var/lib/kolla/venv/bin/keystone-wsgi-public/v3/auth/OS-FEDERATION/identity_providers/keycloak/protocols/openid/websso', 'HTTP_HOST': '192.168.122.17:5000', 'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'HTTP_ACCEPT_LANGUAGE': 'de', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', 'HTTP_REFERER': 'http://192.168.122.17:5000/redirect_uri', 'HTTP_DNT': '1', 'HTTP_COOKIE': 'csrftoken=ZQfGrGsm3XmJ3OswG6NApR5a7f9qs3c6; sessionid=7ujqqerc9cqra57j39m089uddll9nxww; mod_auth_openidc_session=1590534026205f6efcb76a27fa26c26b79a7e9c2', 'HTTP_UPGRADE_INSECURE_REQUESTS': '1', 'HTTP_PRIORITY': 'u=0, i', 'HTTP_X_FORWARDED_FOR': '192.168.122.1', 'HTTP_OIDC_EXP': '1746908921', 'HTTP_OIDC_IAT': '1746908021', 'HTTP_OIDC_JTI': 'e95091d5-917f-476e-9c3b-a3bc9781273a', 'HTTP_OIDC_ISS': 'https://key.example.de/realms/master', 'HTTP_OIDC_AUD': 'kolla-1', 'HTTP_OIDC_SUB': '66cb0e3b-6f36-4a9a-a3e5-dff3a101c50b', 'HTTP_OIDC_TYP': 'ID', 'HTTP_OIDC_AZP': 'kolla-1', 'HTTP_OIDC_NONCE': 'WLn2ZbbbzEFXMkX_K0A4AtSqzEV34SicOMgQihdnt9w', 'HTTP_OIDC_SID': '1c6e9a63-aea1-48c9-a88d-9a797c360527', 'HTTP_OIDC_ACR': '1', 'HTTP_OIDC_NAME': 'benutzer-eins user', 'HTTP_OIDC_EMAIL': 'benutzer-eins(a)example.com', 'SERVER_SIGNATURE': '', 'SERVER_SOFTWARE': 'Apache', 'SERVER_NAME': '192.168.122.17', 'SERVER_ADDR': '192.168.122.16', 'SERVER_PORT': '5000', 'REMOTE_ADDR': '192.168.122.1', 'DOCUMENT_ROOT': '/var/www/html', 'REQUEST_SCHEME': 'http', 'CONTEXT_PREFIX': '', 'CONTEXT_DOCUMENT_ROOT': '/var/www/html', 'SERVER_ADMIN': '[no address given]', 'SCRIPT_FILENAME': '/var/lib/kolla/venv/bin/keystone-wsgi-public', 'REMOTE_PORT': '52286', 'REMOTE_USER': '66cb0e3b-6f36-4a9a-a3e5-dff3a101c50b(a)key.example.de/realms/master', 'AUTH_TYPE': 'openid-connect', 'mod_wsgi.script_name': '', 'mod_wsgi.path_info': '/v3/auth/OS-FEDERATION/identity_providers/keycloak/protocols/openid/websso', 'mod_wsgi.process_group': 'keystone-public', 'mod_wsgi.application_group': '', 'mod_wsgi.callable_object': 'application', 'mod_wsgi.request_handler': 'wsgi-script', 'mod_wsgi.handler_script': '', 'mod_wsgi.script_reloading': '1', 'mod_wsgi.listener_host': '192.168.122.16', 'mod_wsgi.listener_port': '5000', 'mod_wsgi.enable_sendfile': '0', 'mod_wsgi.ignore_activity': '0', 'mod_wsgi.request_start': '1746908021678260', 'mod_wsgi.request_id': 'tGAWuHXKmNw', 'mod_wsgi.connection_id': 'UeMTuPXKmNw', 'mod_wsgi.queue_start': '1746908021679103', 'mod_wsgi.daemon_connects': '1', 'mod_wsgi.daemon_restarts': '0', 'mod_wsgi.daemon_start': '1746908021679325', 'mod_wsgi.script_start': '1746908021679510', 'wsgi.version': (1, 0), 'wsgi.multithread': False, 'wsgi.multiprocess': True, 'wsgi.run_once': False, 'wsgi.url_scheme': 'http', 'wsgi.errors': <_io.TextIOWrapper name='<wsgi.errors>' encoding='utf-8'>, 'wsgi.input': <oslo_middleware.sizelimit.LimitingReader object at 0x71e1c5cf85f0>, 'wsgi.input_terminated': True, 'wsgi.file_wrapper': <class 'mod_wsgi.FileWrapper'>, 'apache.version': (2, 4, 58), 'mod_wsgi.version': (5, 0, 0), 'mod_wsgi.total_requests': 54, 'mod_wsgi.thread_id': 1, 'mod_wsgi.thread_requests': 54, 'werkzeug.proxy_fix.orig': {'REMOTE_ADDR': '192.168.122.16', 'wsgi.url_scheme': 'http', 'HTTP_HOST': '192.168.122.17:5000', 'SERVER_NAME': '192.168.122.17', 'SERVER_PORT': '5000', 'SCRIPT_NAME': ''}, 'webob.adhoc_attrs': {'response': <_AuthTokenResponse at 0x71e1c5b5c2f0 200 OK>}, 'webob.is_body_seekable': False, 'openstack.request_id': 'req-26e43c00-13ef-4528-916b-01f02d913bdd', 'keystone.token_auth': <keystonemiddleware.auth_token._user_plugin.UserAuthPlugin object at 0x71e1c5b5efc0>, 'keystone.oslo_request_context': <keystone.common.context.RequestContext object at 0x71e1c5b5e270>, 'werkzeug.request': <Request 'http://192.168.122.17:5000/v3/auth/OS-FEDERATION/identity_providers/keycloa…' [GET]>} get_assertion_params_from_env /var/lib/kolla/venv/lib/python3.12/site-packages/keystone/federation/utils.py:453 ERROR keystone.server.flask.application [None req-26e43c00-13ef-4528-916b-01f02d913bdd - - - - - -] You are not authorized to perform the requested action.: keystone.exception.Forbidden: You are not authorized to perform the requested action. ERROR keystone.server.flask.application Traceback (most recent call last): ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 295, in error_router ERROR keystone.server.flask.application return self.handle_error(e) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 310, in handle_error ERROR keystone.server.flask.application _handle_flask_propagate_exceptions_config(current_app, e) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask/app.py", line 880, in full_dispatch_request ERROR keystone.server.flask.application rv = self.dispatch_request() ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask/app.py", line 865, in dispatch_request ERROR keystone.server.flask.application return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 489, in wrapper ERROR keystone.server.flask.application resp = resource(*args, **kwargs) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask/views.py", line 110, in view ERROR keystone.server.flask.application return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/flask_restful/__init__.py", line 604, in dispatch_request ERROR keystone.server.flask.application resp = meth(*args, **kwargs) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/server/flask/common.py", line 1133, in wrapper ERROR keystone.server.flask.application return f(*args, **kwargs) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/api/auth.py", line 403, in get ERROR keystone.server.flask.application return self._perform_auth(idp_id, protocol_id) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/api/auth.py", line 396, in _perform_auth ERROR keystone.server.flask.application token = authentication.federated_authenticate_for_token( ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/api/_shared/authentication.py", line 276, in federated_authenticate_for_token ERROR keystone.server.flask.application return authenticate_for_token(auth) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/api/_shared/authentication.py", line 201, in authenticate_for_token ERROR keystone.server.flask.application authenticate(auth_info, auth_context) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/api/_shared/authentication.py", line 169, in authenticate ERROR keystone.server.flask.application resp = method.authenticate(auth_info.get_method_data(method_name)) ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/auth/plugins/mapped.py", line 59, in authenticate ERROR keystone.server.flask.application response_data = handle_unscoped_token( ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/auth/plugins/mapped.py", line 273, in handle_unscoped_token ERROR keystone.server.flask.application mapped_properties, mapping_id = apply_mapping_filter( ERROR keystone.server.flask.application ^^^^^^^^^^^^^^^^^^^^^ ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/auth/plugins/mapped.py", line 380, in apply_mapping_filter ERROR keystone.server.flask.application utils.validate_idp(idp, protocol, assertion) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.12/site-packages/keystone/federation/utils.py", line 354, in validate_idp ERROR keystone.server.flask.application raise exception.Forbidden(msg) ERROR keystone.server.flask.application keystone.exception.Forbidden: You are not authorized to perform the requested action. --- [0] https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html [1] https://docs.openstack.org/kolla-ansible/latest/contributor/setup-identity-…

1 0

[release] Release countdown for week R-20, May 12 - May 16
by Elõd Illés 09 May '25

09 May '25

Development Focus ----------------- The Flamingo-1 milestone is next week, on May 15th, 2025! Project team plans for the 2025.2 Flamingo cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the 2025.1 Epoxy release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Flamingo-1 milestone: May 15th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[watcher] Deprecate noisy neighbor strategy
by Douglas Viroel 09 May '25

09 May '25

Hello everyone, As discussed during the Flamingo PTG[1], it was decided to deprecate the noisy neighbor strategy[2] during this cycle. The main issue with this strategy is that it's limited to analyze only Last Level Cache metrics, which are not available anymore, since Nova dropped Intel CMT support in the Victoria release[3]. We still plan to keep the noisy_neighbor goal since some people have interest in developing a new strategy for it. Let us know if there are any objections. A patch to deprecate the strategy is now proposed [4]. [1] https://etherpad.opendev.org/p/apr2025-ptg-watcher#L219 [2] https://docs.openstack.org/watcher/2025.1/strategies/noisy_neighbor.html [3] https://docs.openstack.org/releasenotes/nova/victoria.html#relnotes-22-0-0-… [4] https://review.opendev.org/c/openstack/watcher/+/949065 BR, -- Douglas Viroel - dviroel

1 0

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

09 May '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 10

[skyline-console] Default project
by Michael Knox 08 May '25

08 May '25

Hey folks, I don't seem to see how Skyline-console uses a "default" project. We are use Skyline in our lab, across multiple projects, but when I log in, I always land in "admin" The link to change project works fine, but the "Default" link just brings up the same modal, nothing seems to be session stored if I set knox to be my default. Is there something I am missing or is this a "to be implemented" thing? [image: CleanShot 2025-05-08 at 14.43.30(a)2x.png] Cheers Michael

2 2

[tc][ops][deployment] Bulk removal of wsgi scripts
by Stephen Finucane 08 May '25

08 May '25

o/ As I noted nearly 18 months ago [1], changes in the Python packaging ecosystem are forcing our hand with regards to the necessity of to both add 'pyproject.toml' files and remove support for pbr's 'wsgi_scripts' entrypoint feature. I was out last week and the week prior, but it seems there's been been a burst of activity around both areas owning to some setuptools issues. This is great to see, and the latter in particular will finally fulfil a community goal that was approved over a year ago [2]. Unfortunately, as a result of the delay in service projects addressing this goal, it seems likely (IMO) that we're not going to be able to wait two release cycles (until H, for projects only adding these modules now in F) to drop the wsgi scripts. This is because the setuptools maintainers understandably have little interest in maintaining the easy_install APIs that we had been relying on to date as public APIs, which means it's very likely that this feature will break in pbr sooner rather than later. This being the case, I'd like to suggest that we rip the band aid off, and proceed with both adding new '$service.wsgi' modules and removing the old '$service-wsgi' scripts in the *same release*. To some degree, this ship has already sailed and at least Designate and Octavia have already done this [3][4] (and others like Magnum are planning to do so [5]) but I'd like to at least let deployment tooling folks know that this will be happening en masse. (It would also be nice to be able to plough on and close this effort off in the likes of Nova and Placement, rather than waiting as Sean Mooney is suggesting [6][7] :).) Please let me know if anyone has any concerns. If not, I'll take silence as tacit agreement and (a) keep pursuing this approach in other services that are currently broken (like Masakari [8]) and (b) poke Sean with increasingly sharp sticks until they approve those Nova and Placement patches. Cheers, Stephen [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://review.opendev.org/c/openstack/governance/+/902807 [3] https://review.opendev.org/c/openstack/designate/+/902846 [4] https://review.opendev.org/c/openstack/octavia/+/902812 [5] https://review.opendev.org/c/openstack/magnum/+/949110 [6] https://review.opendev.org/c/openstack/nova/+/902688 [7] https://review.opendev.org/c/openstack/placement/+/919582 [8] https://review.opendev.org/c/openstack/masakari/+/949154

5 7

[OSSA-2025-001] Ironic fails to restrict paths used for file:// image URLs (CVE-2025-44021)
by Jay Faulkner 08 May '25

08 May '25

========================================================================= OSSA-2025-001: Ironic fails to restrict paths used forfile:// image URLs ========================================================================= :Date: May 08, 2024 :CVE: CVE-2025-44021 Affects ~~~~~~~ - Ironic: <24.1.3, >=25.0.0 <26.1.1, >=27.0.0, <29.0.1 Description ~~~~~~~~~~~ Julia Kreger of Red Hat noticed a vulnerability in image handling for Ironic. A malicious project assigned as a node owner can provide a path to any local file readable by the ironic-conductor which may then be written to the target node disk. This is only possible via deployments performed directly via Ironic's API and cannot be triggered via Nova's virt driver. This is difficult to exploit in practice, as a node deployed in this manner should not ever reach ACTIVE state, but it still represents a danger in environments running with non-default, insecure configurations such as with automated cleaning disabled. Patches ~~~~~~~ -https://review.opendev.org/c/openstack/ironic/+/949175 (2024.1/caracal) -https://review.opendev.org/c/openstack/ironic/+/949174 (2024.2/dalmatian) -https://review.opendev.org/c/openstack/ironic/+/949173 (2025.1/epoxy) - Patch attached tohttps://bugs.launchpad.net/ironic/+bug/2107847/comments/47 (Bobcat/2023.2-eol) -https://review.opendev.org/c/openstack/ironic/+/949186 (Bugfix/26.0) -https://review.opendev.org/c/openstack/ironic/+/949185 (Bugfix/27.0) -https://review.opendev.org/c/openstack/ironic/+/949184 (Bugfix/28.0) -https://review.opendev.org/c/openstack/ironic/+/949172 (Master) -https://review.opendev.org/c/openstack/ironic/+/949182 (Unmaintained/2023.1 antelope) -https://review.opendev.org/c/openstack/ironic/+/949179 (Unmaintained/xena) -https://review.opendev.org/c/openstack/ironic/+/949177 (Unmaintained/yoga) -https://review.opendev.org/c/openstack/ironic/+/949176 (Unmaintained/zed) Credits ~~~~~~~ - Julia Kreger from Red Hat (CVE-2025-44021) References ~~~~~~~~~~ -https://launchpad.net/bugs/2107847 -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-44021 Notes ~~~~~ - Patches have been provided for all supported Ironic branches. As a courtesy, we have also provided patches for some unmaintained branches and the recently end-of-life 2023.2/bobcat release. As usual, we will provide updated releases off maintained branches, but will not create new releases off bugfix or unmaintained branches.

1 0

[Glance] Cancelling 2025-05-08 meeting
by Cyril Roelandt 07 May '25

07 May '25

Hello, Tomorrow's meeting is cancelled because we will not have enough members around due to a bank holiday. Cyril Roelandt

1 0

[kolla] Post Flamingo/2025.2 recap during 21st May weekly meeting
by Michał Nasiadka 07 May '25

07 May '25

Hello, As decided during the last PTG - we're going to have post-PTG recap during 21st May 2025 weekly meeting. We're going to extend it to 2 hours - so 13:00 to 15:00 UTC. Meetpad URL: https://meetpad.opendev.org/kolla-flamingo-ptg See you there! -- Michał Nasiadka mnasiadka(a)gmail.com

1 0

[cinder] Weekly meeting canceled today
by Jon Bernard 07 May '25

07 May '25

Hello all, Metallica is playing this afternoon and my entire town is shutting down today, including schools and childcare, so lets meet next week ;) Take care, -- Jon

1 0

[Wallaby] Interface operations not supported for ovn_metadata_agent
by davorin.mikulic＠gmail.com 07 May '25

07 May '25

Dear openstack community, I am trying to get metadata service to work on a TripleO Wallaby Openstack. Upon successful creation of the virtual machine in a geneve type internal network, namespace gets created on the compute node which hosts the VM: [root@overcloud-computesriov-0 ~]# ip netns list ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c (id: 0) [root@overcloud-computesriov-0 ~]# ip netns exec ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: tapfae7b699-31@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether fa:16:3e:d0:d6:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::ac69:a2ff:feb3:89c9/64 scope link valid_lft forever preferred_lft forever The problem is that the VM cannot reach the metadata service IP 169.254.169.254 even though it has the route to it via 10.0.0.2 (DHCP port in the internal network). I can also see ovn_metadata_agent crashing every 6 seconds with the following: 2025-05-05 13:22:39.044 226779 INFO neutron.common.config [-] Logging enabled! 2025-05-05 13:22:39.044 226779 INFO neutron.common.config [-] /usr/bin/networking-ovn-metadata-agent version 18.6.1.dev209 2025-05-05 13:22:39.050 226779 WARNING oslo_config.cfg [-] Deprecated: Option "heartbeat_in_pthread" from group "oslo_messaging_rabbit" is deprecated for removal. Its value may be silently ignored in the future. 2025-05-05 13:22:39.064 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640: connecting... 2025-05-05 13:22:39.064 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640: connected 2025-05-05 13:22:39.095 226779 INFO neutron.agent.ovn.metadata.agent [-] Loaded chassis name 983d11af-8faf-4f85-99c2-62c00ed8165b (UUID: 983d11af-8faf-4f85-99c2-62c00ed8165b) and ovn bridge br-int. 2025-05-05 13:22:39.108 226779 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.108 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.91:6642: connecting... 2025-05-05 13:22:39.109 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.91:6642: connected 2025-05-05 13:22:39.126 226779 INFO oslo_service.service [-] Starting 2 workers 2025-05-05 13:22:39.136 226779 INFO oslo.privsep.daemon [-] Running privsep helper: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'privsep-helper', '--config-file', '/etc/neutron/neutron.conf', '--config-file', '/etc/neutron/plugins/networking-ovn/networking-ovn-metadata-agent.ini', '--privsep_context', 'neutron.privileged.default', '--privsep_sock_path', '/tmp/tmpnbw1fxbg/privsep.sock'] 2025-05-05 13:22:39.171 226809 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.173 226809 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.95:6642: connecting... 2025-05-05 13:22:39.174 226810 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.175 226809 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.95:6642: connected 2025-05-05 13:22:39.176 226810 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.67:6642: connecting... 2025-05-05 13:22:39.178 226810 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.67:6642: connected 2025-05-05 13:22:39.204 226809 INFO eventlet.wsgi.server [-] (226809) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2025-05-05 13:22:39.209 226810 INFO eventlet.wsgi.server [-] (226810) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2025-05-05 13:22:40.270 226779 INFO oslo.privsep.daemon [-] Spawned new privsep daemon via rootwrap 2025-05-05 13:22:40.167 226859 INFO oslo.privsep.daemon [-] privsep daemon starting 2025-05-05 13:22:40.175 226859 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2025-05-05 13:22:40.180 226859 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/none 2025-05-05 13:22:40.180 226859 INFO oslo.privsep.daemon [-] privsep daemon running as pid 226859 2025-05-05 13:22:40.972 226779 INFO neutron.agent.ovn.metadata.agent [-] Provisioning metadata for network fae7b699-3086-4213-bec7-9d91737c934c 2025-05-05 13:22:41.159 226779 CRITICAL neutron [-] Unhandled error: neutron.privileged.agent.linux.ip_lib.InterfaceOperationNotSupported: Operation not supported on interface tapfae7b699-31, namespace ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c. 2025-05-05 13:22:41.159 226779 ERROR neutron Traceback (most recent call last): 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/bin/networking-ovn-metadata-agent", line 10, in <module> 2025-05-05 13:22:41.159 226779 ERROR neutron sys.exit(main()) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/cmd/eventlet/agents/ovn_metadata.py", line 24, in main 2025-05-05 13:22:41.159 226779 ERROR neutron metadata_agent.main() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata_agent.py", line 41, in main 2025-05-05 13:22:41.159 226779 ERROR neutron agt.start() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 278, in start 2025-05-05 13:22:41.159 226779 ERROR neutron self.sync() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 61, in wrapped 2025-05-05 13:22:41.159 226779 ERROR neutron return f(*args, **kwargs) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 357, in sync 2025-05-05 13:22:41.159 226779 ERROR neutron self.provision_datapath(datapath) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 585, in provision_datapath 2025-05-05 13:22:41.159 226779 ERROR neutron ip2.addr.delete(cidr) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 544, in delete 2025-05-05 13:22:41.159 226779 ERROR neutron delete_ip_address(cidr, self.name, self._parent.namespace) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 842, in delete_ip_address 2025-05-05 13:22:41.159 226779 ERROR neutron net.version, str(net.ip), net.prefixlen, device, namespace) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap 2025-05-05 13:22:41.159 226779 ERROR neutron return self.channel.remote_call(name, args, kwargs) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 224, in remote_call 2025-05-05 13:22:41.159 226779 ERROR neutron raise exc_type(*result[2]) 2025-05-05 13:22:41.159 226779 ERROR neutron neutron.privileged.agent.linux.ip_lib.InterfaceOperationNotSupported: Operation not supported on interface tapfae7b699-31, namespace ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c. 2025-05-05 13:22:41.159 226779 ERROR neutron 2025-05-05 13:22:41.592 226810 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2025-05-05 13:22:41.592 226809 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2025-05-05 13:22:41.593 226810 INFO eventlet.wsgi.server [-] (226810) wsgi exited, is_accepting=True 2025-05-05 13:22:41.593 226809 INFO eventlet.wsgi.server [-] (226809) wsgi exited, is_accepting=True I can confirm that I tried assigning and deleting the IP to the interface tapfae7b699-31 from the host and from the container (podman exec -it --user root container-id bash) and succeeded. I didn't succeed to assign IP to the interface with a regular neutron user (podman exec -it container-id bash). Also, nova metadata service hosted on the controller is accessible from the compute node: [root@overcloud-computesriov-0 ~]# curl http://10.100.22.127:8775 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 Did anyone come across anything like this? Best regards, Davorin

3 8

[OVN][Neurton] Help in capturing metrics part of scale testing in OVN
by keerthi vassan 06 May '25

06 May '25

Hello Team Myself new to OVN with Openstack ( provider network based model) , as part of this I am trying to perform an iperf based network test to understand how traffic flow is happening. As part of that, how to validate how much time took for logical flow computation by services in hypervisor. For specific tests, looking for a way to figure out, how much services like ovn-controller, vswitchd & ovsdb server are contributing to it . Do we have any specific tooling to capture these metrics ? Can you please help with this ? Regards, Keerthivasan

2 1