- openstack-discuss - lists.openstack.org

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

14 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 12 May '25

12 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

[neutron] OVS Hardware Offloading Performance Issues
by Serhat Rıfat Demircan 06 May '25

06 May '25

Hello everyone, I've been testing OVS hardware offloaded ports for a while. I have ConnectX-5 and ConnectX-6 cards in my lab. Iperf tests are looking promising, but when I try to use hardware offloaded ports for krbd traffic, after some time, traffic falls back to the software path. Another interesting thing for me is without changing anything, it can also switch back to the hardware path. This issue mostly occurs while I am doing this test with 3 virtual machines on the same hypervisor. I'm not sure if this is a configuration issue or I'm hitting to cards limit. If any of you guys are experienced with this all ideas are more than welcome. Openstack version: Caracal Operation System: Ubuntu 22.04 Thank you, Serhat

1 2

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

05 May '25

Hello Stackers, Next week is milestone-1 of the 2025.2 ("Flamingo") release cycle [1]. This is typically a bug-targeting milestone across OpenStack project teams. During the last week, the OpenStack Technical Committee adopted a resolution to extend the purview of the OpenStack Vulnerability Management Team (VMT) to cover all OpenStack project teams [2]. This means that all of the user- and operator-facing deliverables within OpenStack will follow the Vulnerability Management process [3] consistently, and project teams no longer need to explicitly opt-in. To make this work in reality, project teams must ensure that their bug trackers are configured to explicitly share private security bugs with the VMT, and ensure that core security contacts are up to date. I'll share more on this in a dedicated post to this mailing list. Alongside this resolution, the TC also approved the creation of "grain-ui" as an OpenStack project under the telemetry team, and approved the retirement of the "openstack-helm-infra" project because the code is now part of the "openstack-helm" project. As you are aware, the OpenInfra Summit is coming to France this October [4]. The call for papers is open until 2025-06-13. Funding exists through the OpenInfra Foundation's Travel Support Program. If you're interested in applying, please do so by the deadline: 2025-07-09 [5]. === Weekly Meeting === The TC held its weekly meeting on 2025-04-29 in OFTC's #openstack-tc IRC channel [6]. We noted a change in affiliation with regard to Ghanshyam Maan (gmaan), who is now employed at Red Hat. This change does not negatively affect the TC's affiliation diversity requirement [7]. The TC caught up on several prior action items. It was noted that the base upgrade test jobs have been modified to now test upgrading from the 2025.1 ("Epoxy") release to the current release, and this change should have been reflected in all project-specific test jobs. SLURP (N-2→N upgrade) jobs are configured as voting by default but can be opted out of by projects, since the release under development, 2025.2 ("Flamingo"), isn't a SLURP release. We agreed that Sylvain Bauza (bauzas) and myself will serve as the VMT's TC liaisons. Our role will be to bridge communication between the VMT and project teams to coordinate security fixes. Discussing the i18n SIG's challenges with translation infrastructure provided us with a segue into OpenStack Special Interest Groups (SIG) Activity & Maintenance Processes. SIGs do not maintain any OpenStack deliverables; however, several of them maintain code repositories on OpenDev [8] that could be useful. In many cases, there isn't a clear process to onboard new contributors or maintainers, and communication breaks down if existing SIG chairs are unresponsive. We concluded that SIGs should have better documented succession and onboarding paths to avoid stagnation. We would like to do a health check of SIGs over the release and embrace any new ways to make SIGs sustainable. The next meeting of the OpenStack TC is today, 2025-05-06. This will be our monthly Video+IRC meeting. You're welcome to join any medium that you prefer. We'll take notes as usual and upload the meeting's recording to the TC's channel on YouTube [9]. Please find important meeting information such as the venue or the agenda on the meeting's wiki page [10]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Retire openstack-helm-infra repo | https://review.opendev.org/c/openstack/governance/+/947611 - Add openstack/grain-ui | https://review.opendev.org/c/openstack/governance/+/948252 - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 === Upcoming Events === - 2025-05-06: (Informal) OpenInfra Board discussion on AI policy: https://etherpad.opendev.org/p/board-informal-ai-contribution - 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-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] TC Resolution to extend the VMT's scope: https://governance.openstack.org/tc/resolutions/20250317-extend-scope-VMT-c… [3] VMT process: https://security.openstack.org/vmt-process.html [4] OpenInfra Summit 2025, Paris-Saclay: https://summit2025.openinfra.org/ [5] OpenInfra Summit Travel Support Program Application: https://openinfrafoundation.formstack.com/forms/openinfra_tsp [6] TC Meeting IRC Log 2025-04-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-29-17.00.html [7] OpenStack TC Affiliation Diversity Requirement: https://governance.openstack.org/tc/reference/charter.html#tc-diversity-req… [8] Repositories maintained by OpenStack SIGs: https://governance.openstack.org/tc/reference/sig-repos.html [9] OpenStack TC on YouTube: https://www.youtube.com/@openstack-tc [10] TC Meeting Agenda, 2025-05-06: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[Cinder] : Group API query
by Harsh Ailani 05 May '25

05 May '25

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

3 9

Student Opportunity - CMU Summer Semester 2025
by Kendall Nelson 05 May '25

05 May '25

Hello All! Are any of you interested in mentoring students to work on any projects you have on the backlog? This is what I have from one of the Profs of the course: ------- To remind you of the ask from last year (and *call out differences for this year*): - We are looking for projects that a team of 4-5 students could tackle together with at least two mentors for each project. As we saw last year, mentors can certainly overlap projects if appropriate and they have the time. (Life happens and having the built-in mentor redundancy helps. I’ve had mentors get laid off, change jobs, and take summer vacation.) - Mentors are expected to meet student teams once a week for an hour (via any video conference setup folks want to use), and to be available by email during the rest of the week to answer any urgent questions. - *This summer we are running the class from 13 May to 31 July (11 weeks)*. - *We want to try teaching concurrently in both campuses Doha, Qatar (GMT+3) and Pittsburgh (GMT-5), USA. The entire course will be taught virtually this year, without a classroom.* I certainly did something similar a few years ago when I was teaching at Hopkins (20 students) with another group in Galway (16 students). The morning class in Pitt will be the afternoon in Doha. - *We likely have 15-20 students in each location, so if you had on the order of 4-5 team projects with mentors that fit the format, like last year, that would be fantastic. * - *We are considering going so far as to choose the teams across time zones to get them working remotely from the start.* Last year, after six weeks together in class and daily stand-ups, the students scattered home away from Doha, and all of them worked remotely the last four weeks. They proved they could work remotely together. Of course, the relationships with mentors have always been remote. The profs in Doha and Pitt want to try remote from the beginning. (I have a few concerns but I’m also always up to experiment on students.) - We post the projects on the first day of class and will organize the teams in that first couple of days, so student teams are introduced to their mentors in the first week of class and expected to organize that first meeting to begin the project learning curve. That’s when mentors point students at any tutorials and bootstrap materials, recommended getting started materials, etc. - We have set the expectations with the students that they will be spending 20-40 hours of time per week on the project. It is an internship-like experience. - *Two co-teachers run classes on three days a week for 50 minutes, and I will guest lecture a collection of classes. *(Last year, there was just the real professor and I.) - The three of us will provide a coaching session with each team to ensure they are working with the mentors well. - Students generally have Windows or Mac laptops, but we have teaching assistants on each site that we can start to prep any other access to resources they might need. - As with last year, mentors have a lot of freedom to experiment. Some have run joint sessions if they are mentoring more students for learning curves. Some have run Slack or Discord channels. ------ So, who is interested in working with students? Please let me know if you have any additional questions. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 1

[barbican] Weekly meeting canceled 5-5-2025
by Grzegorz Grasza 05 May '25

05 May '25

Hi all, Due to conflicts and time off, we have to cancel the Barbican weekly meeting today (5-5-2025). Please reach out via IRC if you need anything. Thanks! / Greg

1 0

[kolla][OpenStackAnsible] 2025.1 Epoxy release for cycle-trailing projects
by Elõd Illés 05 May '25

05 May '25

Hi teams, This is a gentle reminder that the following projects with cycle trailing release model haven't done their 2025.1 Epoxy release yet: [kolla] ansible-collection-kolla kayobe kolla-ansible kolla [OpenStackAnsible] openstack-ansible-roles openstack-ansible Note, that next week we'll ask for cutting stable/2025.1 branches, as kind of a Feature Freeze, 3 weeks prior the 2025.1 Epoxy Cycle-Trailing Release Deadline on June 5th, 2025 [1] (exactly one month away). [1] https://releases.openstack.org/flamingo/schedule.html#f-cycle-trail Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

1 0

[tacker] Skip next IRC meeting
by Yasufumi Ogawa 04 May '25

04 May '25

Hi Tacker team, Due to a holiday in Japan and most of us will not join, I would like to skip IRC meeting tomorrow. Thanks, Yasufumi

1 0

[manila] Share Encryption Collab Review meeting on 2025-05-08
by Goutham Pacha Ravi 02 May '25

02 May '25

Hello Zorillas and interested stackers, We're hosting a discussion on meetpad during the weekly Manila Team meeting slot [1][2] next week, 2025-05-08 (Thursday) to further discuss the design of share encryption. The discussion will follow a proposed specification [3], and seeks to align a number of folks that are implementing the API/UX portions, back end storage driver pieces and functional tests. The meetpad discussion will be at 15:30 UTC. We'll have our weekly IRC meeting as usual at 1500 UTC. Thanks, and hope to see you there, Goutham Pacha Ravi (gouthamr) [1] Manila Team Meeting: https://meetings.opendev.org/#Manila_Team_Meeting [2] ICS for this collab review: https://gist.github.com/gouthampacha/0eaaad7bb2eec343dd56cf15f2f87f9a [3] Design Spec for share encryption:

1 0

OVN Routers don't seem to be highly available
by Ryan Belgrave 02 May '25

02 May '25

I have Openstack dalmatian deployed with OVN. All networking seems to work as expected, however OVN routers don't seem to be highly available. I've followed this guide https://docs.openstack.org/neutron/latest/install/ovn/manual_install.html and have enable-chassis-as-gw set on all the compute nodes. I have a very simple network setup with 1 self-service network connected to a router and that router connected to a provider network. Looking in the OVN SB database at the port_binding for the router, it has 1 chassis listed and a ha_chassis_group. There are multiple compute nodes listed in the ha_chassis_group when I lookup that ID in the table. When I fail the server that is listed as the chassis for the port binding it never gets assigned to a different chassis and the instances in the self-service network stop being able to connect to things in the provider network. I've tried various different ways to fail the server, unplugging the self-service nic makes the port_binding chassis show as "[]" and it never gets assigned to another, hard powering off the server keeps the chassis as the old one and it never gets assigned to another. Waiting multiple minutes to 1+ it never gets reassigned. As soon as I bring back the failed compute node, it gets assigned back to that one and everything works. The only way I can seem to get a failover to another compute node is to stop the ovn-controller service on the server that is listed as the chassis for the port binding. In that case another chassis does get assigned and routing works as expected. According to https://docs.openstack.org/neutron/latest/admin/ovn/routing.html under Failover (detected by BFD) this should "just work". I did check the tunnels and BFD status and BFD does show as down as expected, but nothing else happens. Any ideas? I'm not too sure what to look at to debug this, all my configs seem fine as everything else works as expected.

2 2

[cinder][nova][rbd]instance cannot boot when using qos
by Nguyễn Hữu Khôi 02 May '25

02 May '25

Hello. I create a volume type with qos which uses frontend consumer then I create an instance which booted from a volume, however, It stucked it booting from hardisk. What could will be? Pls give me some ideas on this? Thank you. Env: Openstack 2025.1 KollaAnsible 2025.1 master Ubuntu 2024.02 Nguyen Huu Khoi

3 7

[manila] Removal of the Standalone CephFS NFS protocol helper in Epoxy
by Ashley Rodriguez 02 May '25

02 May '25

Hi zorillas! As per subject line, we will be deprecating the standalone CephFS NFS protocol helper in this cycle. This is following our deprecation warning we put out in 2024.1 / Caracal [1] [2]. We've supported using a clustered Ceph NFS service since the Zed release. We've also added upgrade helpers to migrate from a standalone NFS-Ganesha service to the ceph-orch-deployed clustered NFS service; this code was backported to stable/2023.1 (Antelope). Although the upgrade path is disruptive, there is a UX improvement in Manila to ease this migration through surfacing “preferred” export paths. Moving forward, deployments must have “cephfs_nfs_cluster_id” in your configuration, otherwise the driver will fail to start. Manila will not make any export changes to NFS-Ganesha, so upgrading manila without an NFS cluster will mean that only the control plane is not going to work; but, data plane will remain unaffected. To assist migration, admins can also configure "cephfs_ganesha_export_ips" (or alternatively, "cephfs_ganesha_server_ip") alongside "cephfs_nfs_cluster_id". Setting these options will allow the CephFS driver to report additional export paths. These additional export paths will have the "preferred" metadata key set to False. Best, Manila team [1] https://review.opendev.org/c/openstack/manila/+/912648 [2] https://docs.openstack.org/manila/2024.2/configuration/shared-file-systems/…

5 7

RDO Epoxy 2025.1 Release - Important Note at Bottom
by Amy Marrich 01 May '25

01 May '25

RDO Epoxy 2025.1 Release - Important Note at Bottom The RDO community is pleased to announce the general availability of RDO builds for OpenStack 2025.1 Epoxy for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public and hybrid clouds. Epoxy is the 31st release of the OpenStack project, backed by over 1,000 contributors worldwide. This release is already available on CentOS Stream 9 on the CentOS mirror network: https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ The RDO community project curates, packages, builds, tests, and maintains a complete set of OpenStack components for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain on-premise, public, or hybrid clouds. All work on RDO and its downstream release, Red Hat OpenStack Services on OpenShift, is 100% open source, with all code changes going into it's related upstream first. You can read the broader upstream OpenStack project highlights at https://releases.openstack.org/epoxy/highlights.html, but here are some highlights: - Notably, active/active support for Dell PowerStore, Dell PowerStore QoS support, NetApp adding support for active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool adding support for pool-to-pool cloning. - To address OSSN-0090 and OSSN-0065, support was added for a new add/get location API that replaces the image update (old location-add) mechanism for consumers such as cinder and nova. - Ironic includes multiple security improvements: - All supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, and the first phase of deprecation of the eventlet library is complete. - Instances with UEFI can now boot in stateless pending if the image has the hw_firmware_statelessproperty and the compute service has libvirt 8.6.0 or later. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) upgrades will only be supported from the Caracal 2024.1 release to the next SLURP release (phase Epoxy). RDO Epoxy 202 5.1 has been published by the CentOS Storage SIG in the official CentOS repository and has been built and tested with the latest released Ceph 18.2.0 Reef version ( https://docs.ceph.com/en/latest/releases/reef/) *Note:* Follow the instructions in the [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services on the same host. During Epoxy cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Epoxy 2025.1 release: - python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) - puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) - python-oauth2client (dependency https://review.rdoproject.org/r/c/rdoinfo/+/54115) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: - During the Epoxy cycle, we saw the following new RDO contributors: - Ashish Gupta - Dmitriy Chubinidze - Francisco Seruca Salgado - Ivan Anfimov - Lilach Avraham - Manoj Katari - Saurabh Agarwal - Sofer Athlan-Guyot - Viji Candappa Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 51 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Alan Pevec - Alfredo Moralejo - Amy Marrich - Ananya Banerjee - Artom Lifshitz - Ashish Gupta - Bogdan Dobrelya - Chandan Kumar - Daniel Pawlik - Dmitriy Chubinidze - Douglas Viroel - Eduardo Olivares - Fiorella Yanac - Francesco Pantano - Francisco Seruca Salgado - Harald Jensås - Ivan Anfimov - Jakub Libosvar - Jaromír Wysoglad - Joan Francesc Gilabert - Joel Capitao - Karolina Kula - Lewis Denny - Lilach Avraham - Luigi Toscano - Manoj Katari - Maor Blaustein - Martin Kopec - Matthias Runge - Matthieu Huin - Miguel Garcia - Mikołaj Ciecierski - Pablo Rodríguez Nava - Pooja Jadhav - Rabi Mishra - Radomir Dopieralsk - iRodolfo Alonso - Ronelle Landy - Saurabh Agarwal - Sergii Golovatiuk - Shreshtha Joshi - Sławek Kapłoński - Sofer Athlan-Guyot - Takashi Kajinami - Tobias Urdin - Tony Breeds - Viji Candappa - Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Epoxy. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://www.rdoproject.org/community/mailing-lists/. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Join us in #rdo and on the OFTC IRC network. You can also find us on Facebook and YouTube. *Important Note!* We had a thriving, if small, group of community members maintaining packages prior to COVID and we need to return to those days of having folks participate in this effort. The OpenStack RPM packaging effort is in need of package maintainers in order to continue having RPMs. The current maintainers have moved on to new opportunities, so while we have folks continuing to contribute, we currently have no folks to build and maintain packages. Please check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Please reach out if you can help!

1 0

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

30 Apr '25

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

4 8

[all][rbac] Changing policy popup team meeting schedule
by Ghanshyam Maan 30 Apr '25

30 Apr '25

Hello Everyone, As discussion topics are less during biweekly meetings (most of the time it's just me), I am updating the RBAC policy pop-up meeting to occur monthly on the first Monday of each month. The next meeting will be on May 5th. NOTE: We still have many projects to complete the RBAC goal, and you do not need to wait for the meeting to ask RBAC-related help/queries, feel free to reach out to me on IRC/ML. - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… - https://review.opendev.org/c/opendev/irc-meetings/+/948569 -gmann

1 0

[Neurton][OVN] Not able to remove geneve tunnel
by keerthivassan86＠gmail.com 30 Apr '25

30 Apr '25

As part of openstack-ansible deployment, removed geneve tunnel config as you mentioned, now we have only below on neutron server [ml2] type_drivers = vlan tenant_network_types = vlan mechanism_drivers = ovn Same config for neutron in compute node as well, under ovn external_id external_ids : {hostname=xxxx ovn-bridge-mappings="vlan:br-ex", ovn-cms-options="availability-zones=nova", ovn-remote="tcp:xxxx:6642,tcp:xxxxx:6642", rundir="/var/run/openvswitch", system-id="01a70eda-59bb-4e8b-870d-08eba09abae3"} With above config, we do see below error in ovn-controller & not able to connect to SB DB ovn-controller.log: 2025-04-29T17:38:48.508Z|00012|main|INFO|OVN internal version is : [24.03.2-20.33.0-72.6] 2025-04-29T17:38:55.206Z|00026|chassis|INFO|Need to specify an encap type and ip 2025-04-29T17:38:55.206Z|00027|chassis|INFO|Need to specify an encap type and ip 2025-04-29T17:38:55.206Z|00028|chassis|INFO|Need to specify an encap type and ip can you please share your inputs on this ? Ideally we don't want to have ovn-*** ports to be created

2 3

[Glance] No meeting on May, 1st
by Cyril Roelandt 30 Apr '25

30 Apr '25

Hello, Thursday is International Workers' Day and most of the Glance team will be away from keyboard. The meeting will therefore be cancelled. Happy Hacking anyway! Cyril Roelandt

1 0

[keystone] Weekly meeting canceled 30-Apr-2025
by Dave Wilde 30 Apr '25

30 Apr '25

Greetings, Due to conflicts and travels we have to cancel this Keystone weekly meeting for this week (30-Apr-2025). Please reach out via the mailing list or IRC if you need anything from us. Thank you! /Dave

1 0

[Docs][I18n] Re: Deployment Guide translation of OSA
by Ian Y. Choi 29 Apr '25

29 Apr '25

(Adding: openstack-discuss(a)lists.openstack.org and openstack-i18n(a)lists.openstack.org) Hi, Thank you for reaching out. I've noticed that the "deploy-guide" is not located in the /doc/source folder of the repository. This suggests that there may currently be no direct support from the OpenStack Docs team (now under the TC) or the I18n SIG for this documentation. To align with the Project Team Integration (PTI) structure, I recommend discussing with the core team members of the repository about reorganizing the documentation accordingly. For your reference, I am sharing some additional documents below like [2] - [4], which I hope will help clarify the process and requirements. If you have further questions or need support from the I18n SIG, please feel free to reach out via the openstack-i18n mailing list or the #openstack-i18n IRC channel. This ensures that your queries are visible to all community members and can be addressed more efficiently, rather than contacting me directly. Thank you, /Ian [1] https://docs.openstack.org/doc-contrib-guide/team-structure.html [2] https://docs.openstack.org/i18n/latest/infra.html [3] https://docs.openstack.org/doc-contrib-guide/project-guides.html [4] https://governance.openstack.org/tc/reference/project-testing-interface.html On Tue, Apr 29, 2025 at 12:09 AM Dmitry <dcu995(a)gmail.com> wrote: > Hello, Ian. > > We are currently working on adding the OpenStack-Ansible deployment guide ( > https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/) to > translation server. However, we've encountered a challenge: we are not sure > how to start a job to gather the documents and upload them to Zanata ( > https://review.opendev.org/c/openstack/openstack-ansible/+/947634) > > Could you please guide us on what steps we should take to initiate this > process? > > Thank you very much. >

2 1

Bitergia dashboard outage due to maintenance
by Ildiko Vancsa 29 Apr '25

29 Apr '25

Hi OpenStack community, I’m reaching out to let you know that the OpenStack Bitergia metrics dashboard[1] will be unavailable for a short period of time due to scheduled maintenance, where the underlying OpenSearch cluster will be updated. Details of the downtime: * Start Date: Monday, April 28th at 9:00 AM CEST (12:00 AM PDT) * End Date: Tuesday, April 29th at 4:00 PM CEST (7:00 AM PDT) __During this maintenance window, the dashboard will be inaccessible. Please also note that data updates will not resume until Wednesday.__ Thank you for your understanding. Best Regards, Ildikó [1] https://openstack.biterg.io/app/dashboards#/view/Overview

1 1

[glance] Manually creating an image
by Francesco Di Nucci 29 Apr '25

29 Apr '25

Hi all, I am experimenting with manual creation of images, so I am trying to update the documentation example about a CentOS Stream image creation (https://review.opendev.org/c/openstack/openstack-manuals/+/928128) Is there anyone that could review the steps I wrote? It seems to work but I think there is room for improvement/more best practices to be followed Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

1 0

[kolla-ansible][rabbitmq] Change to quorum queue
by Winicius Allan 29 Apr '25

29 Apr '25

Hi community o/ I've got a little confused about the procedure[1] to change the type of queues to quorum queues. The documentation says that it is needed to stop the services that use Rabbit, but in some tasks in `genconfig` step, some APIs must be up, for example, in[2]. I think the documentation is not too clear, or I just missed something. So, I need to stop services and turn on the APIs? Will it affect the procedure of changing the queue type from classic to quorum? Another question is: when upgrading from Antelope to Caracal, is this procedure mandatory? [1] https://docs.openstack.org/kolla-ansible/latest/reference/message-queues/ra… [2] https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/octavi…

2 2

[neutron] Bug Deputy Report Apr 21 - Apr 27
by Yatin Karel 29 Apr '25

29 Apr '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ==== - https://bugs.launchpad.net/neutron/+bug/2109592 - [master][periodic] oslo master jobs broken with ImportError: cannot import name 'format_inspector' from 'oslo_utils.imageutils' Unassigned - https://bugs.launchpad.net/neutron/+bug/2109591 - master periodic job running with centos 9-stream broken with py39 constraint drop https://review.opendev.org/c/openstack/requirements/+/948285 Unassigned - https://bugs.launchpad.net/neutron/+bug/2109456 - AttributeError occurs when querying ports immediately after starting neutron-server Assigned to Gwangseok Jeon - https://bugs.launchpad.net/neutron/+bug/2107925 - [ovn] neutron_pg_drop deleted when using network log Assigned to Elvira García Ruiz - https://bugs.launchpad.net/neutron/+bug/2109326 - test_release_for_ipv6_lease_no_dhcp_release6 unit tests fails randomly Assigned to Yatin Karel Medium ====== - https://bugs.launchpad.net/neutron/+bug/2109354 - Incorrect behavior when filtering networks by provider:network_type with a limit parameter Unassigned Wishlist ======== - https://bugs.launchpad.net/neutron/+bug/2108952 - [RFE][ml2][ovs] distributed DHCP extends supports for DPU baremetal Unassigned Incomplete ========= - https://bugs.launchpad.net/neutron/+bug/2108985 - [BGP DVR] Incorrect /32 Fixed IP Route Advertisement Logic Asked for more input -- Thanks and Regards Yatin Karel

1 1

[tacker] Skip next IRC meeting
by Yasufumi Ogawa 28 Apr '25

28 Apr '25

Hi team, Due to holidays in Japan this week, I would like to skip today's IRC meeting. Thanks, Yasufumi

1 0

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

28 Apr '25

Hello Stackers, We're a couple of weeks away from milestone-1 of the 2025.2 ("Flamingo") release cycle [1]. A few project teams have added team-specific deadlines to the release schedule. If you're thinking about team-specific events, please propose a change to the "openstack/releases" repository with the details, e.g., like the Nova team is doing [2]. We're looking for volunteers to serve as election officials [3] for the next combined elections for the OpenStack Technical Committee and Project Team Leads. This election will be held between August and September 2025 and will allow us to elect 2026.1's project team leads across the community, alongside 4 TC members. If you're interested, please reach out to me off-list or chime in within the #openstack-election IRC channel on OFTC. In the last week, the TC approved the deprecation of "openstack-ansible-tests". The project team has been working hard to replace all their testing with molecule-based testing that will significantly improve CI jobs. The TC is working on a resolution to amend the Vulnerability Management Team's purview [4] and will follow that up by working with project teams to ensure a streamlined security process. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held over IRC in OFTC's #openstack-tc channel on 2025-04-22 [5]. The meeting was well attended, and we discussed several action items from the Flamingo PTG that was held earlier this month. Some of these concerned the i18n SIG. We briefly discussed how one could obtain visitor statistics that might inform how the documentation websites were being accessed from around the world. We don't publish this information on any website, and we were not keen on involving proprietary, third-party tools to track and report this data. The "goaccess" data is published in Zuul with a short retention (~6 weeks) and may yet answer some questions. A word of warning was shared that the statistics may be influenced by bots and LLM crawlers of late. You may be aware that the SIG has been migrating translation infrastructure from Zanata to Weblate. We recalled the work that happened to set up a hosted Weblate service a few years ago and took action items to follow up offline to investigate changes that are now required. Finally, we intend to follow up on discussions that didn't find room at the PTG in future weekly meetings. The next weekly meeting of the OpenStack TC is today, 2025-04-29. It will be hosted over IRC in OFTC's #openstack-tc channel. This meeting is open to any community member to propose governance discussions. Please find the agenda on the meeting's wiki page [6]. I hope you'll be able to join us! === Governance Proposals === ==== Merged ==== - Fix gmaan's email address | https://review.opendev.org/c/openstack/governance/+/948342 - Deprecate openstack-ansible-tests repo | https://review.opendev.org/c/openstack/governance/+/947622 ==== Open for Review ==== - Updating Ghanshyam email/irc name | https://review.opendev.org/c/openstack/governance/+/948354 - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 - Add openstack/grian-ui | https://review.opendev.org/c/openstack/governance/+/948252 - Retire openstack-helm-infra repo | https://review.opendev.org/c/openstack/governance/+/947611 - Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 === Upcoming Events === - 2025-04-29: StackConf https://stackconf.eu/ - 2025-04-29: SCS Hackathon / OpenStack Birthday: https://events.sovereigncloudstack.org/hackathon5-2025/ - 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/ 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] Add Nova deadlines to the official schedule | https://review.opendev.org/c/openstack/releases/+/948077 [3] OpenStack election officials: https://governance.openstack.org/election/#election-officials [4] Extend scope of VMT to cover all project teams: https://review.opendev.org/c/openstack/governance/+/944817 [5] TC Meeting IRC Log 2025-04-22: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-22-17.01.log.html [6] TC Meeting Agenda, 2025-04-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Request to Join as GSoC 2025 Mentor for OpenStack
by anjali 28 Apr '25

28 Apr '25

Hi OpenInfra GSoC Team, I’m Anjali Dhanuka, currently working as MTS at Salesforce with backend and cloud engineering experience (JavaScript, AWS, distributed systems). I am very interested in joining OpenStack as a mentor for GSoC 2025. I have prior experience building scalable cloud systems and I am passionate about helping students grow their skills through real-world backend projects. I would love to assist in proposal reviews and mentoring one or more students this summer. Please let me know the next steps or any information you need from me. Looking forward to contributing to OpenInfra’s GSoC journey! Thanks and Regards, Anjali Dhanuka

1 0

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

28 Apr '25

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

2 3

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

28 Apr '25

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

2 5

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

28 Apr '25

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

1 0

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

24 Apr '25

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

1 0

[watcher] Cancelling May 1st weekly meeting
by Douglas Viroel 24 Apr '25

24 Apr '25

Hi all, Since most participants will be out on May 1st, due to local holidays, we agree[1] to cancel next week's meeting. We will meet again on May 8th. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-04-24-12.00… BR, -- Douglas Viroel - dviroel

1 0

[openstack-ansible]: Operating system upgrade procedure Ubuntu 20.04 to 22.04
by Rambo Rambo 24 Apr '25

24 Apr '25

Hi Team We are currently on below release of Openstack: Openstack Release: Zed OS Release: Ubuntu 20.04.2 LTS I am looking for the tested procedure/suggestions/experience for doing the operating system upgrade from 20.04 to 22.04 on this openstack release. Regards Rambo

2 5