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

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

11 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 09 May '25

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

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

09 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