July 2024 - openstack-discuss - lists.openstack.org

[swift] Weird log corruption or something more serious?
by Sam Morrison 15 Jul '24

15 Jul '24

Hi, We are debugging a weird issue with our swift cluster (currently running 2.29.2) We got a report from a user that they were getting upload failures and then sent us this from their logs: 2024-06-25 23:30:06,829 | swiftclient.service | ERROR | Object PUT failed: https://swift-host/v1/PROJECT_ID_A/prod_result/195e5e8e-334a-11ef-ba70-0a58… 401 Unauthorized [first 60 chars of response] b'<html><h1>Unauthorized</h1><p>This server could not verify t' (txn: txab25fcfcf3354bbbaf105-00667b52fe) Searching our logs for that transaction ID I found: 203.101.227.241 127.0.0.1 25/Jun/2024/23/30/06 PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/blobs/default/content/vol-27/chap-25/6bc30bae-4f5e-40a8-bc63-096679af1a58.bytes HTTP/1.0 401 - rclone/v1.59.0%2Cpython-swiftclient-4.2.0 gAAAAABme1L7tlfE... - 131 - txab25fcfcf3354bbbaf105-00667b52fe - 0.0440 - - 1719358206.765954018 1719358206.809994936 0 Note this is a completely different project ID from our side, timestamp is correct too. We also have this: ERROR WSGI: code 400, message Bad request syntax ('\x89PNG') (txn: txab25fcfcf3354bbbaf105-00667b52fe) (client_ip: XX.XX.XX.XX) Upon further analysis we see this quite a lot, mostly from attempted hackers but lots from real users and lots seem to be related to rclone. Eg. Jun 27 08:24:46 swift-host proxy-server[70043]: ERROR WSGI: code 400, message Bad request syntax ('PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/elasticsearch/nexus/nodes/0/indices/42b6a6a76dae683a647546ac02a6883108ac7df5/0/index/segments_4PUT /v1/AUTH_PROJECT_ID_B/nexus-migration/nexus-data/elasticsearch/nexus/nodes/0/indices/4db62ff1327dfe236d85b1dd1a6a9e8139e7e4cf/0/index/_67t.cfs HTTP/1.1') (txn: txd57a3d00bb1942c6a390e-00667c952a) (client_ip: XX.XX.XX.XX) Anyone know what is going on here? Thanks, Sam

1 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-11)
by Goutham Pacha Ravi 15 Jul '24

15 Jul '24

Hello Stackers, The 2024.2 release train is chugging along, and its final stop is 11 weeks away [1]. In the past week, the OpenStack Technical Committee updated its charter to enforce its affiliation diversity requirements during TC elections [2]. If an election results in over 50% of the TC being affiliated with the same organization, we've adopted a rule to vacate the least favored candidate elected from that organization and accommodate a non-elected candidate with a different affiliation, if one exists. We're also ideating on how to handle situations where there are no candidates from other organizations [3]. Your views are greatly appreciated. Nominations for the TC (and PTL) elections for 2025.2 open on 2024-08-14. You'll begin to receive election-specific emails soon. In other news, Jeremy Stanley (fungi) shared the OpenInfra Foundation's Diversity and Inclusion Working Group updates on this list recently [4]. I encourage you to participate in the survey that the group has put together [5]. It's open year-round, and the feedback gathered will be incorporated continuously. === Weekly Meeting === Last week's Technical Committee meeting was well attended, and the meeting was logged to eavesdrop [6]. We discussed project activity and gate issues in Monasca, Freezer, Skyline, Tacker, Masakari, Zaqar, and Adjutant. We're very glad to see the project teams' responsiveness to the concerns raised. Monasca and Freezer teams have expressed their desire to remain "inactive" through this release cycle. A proposal has been made to move Skyline from the list of "Emerging" projects. The TC will review these proposals in the coming week. The retirement of the "kuryr-kubernetes" repository was held off temporarily to address dependencies within Tacker. The next Technical Committee meeting is tomorrow, 2024-07-16! The meeting will be hosted on OFTC's #openstack-tc channel, and the agenda has been posted to the Meetings Wiki Page [7]. Please consider joining us! === Governance Proposals === ==== Merged ==== Adding a rule to manage the affiliation diversity requirement in the TC | https://review.opendev.org/c/openstack/governance/+/922512 ==== Open for review/discussion ==== Follow up on the affiliation diversity handling | https://review.opendev.org/c/openstack/governance/+/923876 Move Skyline out from the "Emerging Projects" list | https://review.opendev.org/c/openstack/governance/+/924109 Transition Watcher project to DPL | https://review.opendev.org/c/openstack/governance/+/923583 Inactive state extensions: Monasca | https://review.opendev.org/c/openstack/governance/+/923919 Update to include docs and miscellaneous repos for AC status | https://review.opendev.org/c/openstack/governance/+/915021 Update criteria for the inactive projects to become active again | https://review.opendev.org/c/openstack/governance/+/921500 Inactive state extensions: Freezer | https://review.opendev.org/c/openstack/governance/+/923441 Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 Remove Eventlet From OpenStack | https://review.opendev.org/c/openstack/governance/+/902585 The OpenStack Technical Committee serves you! We're always willing to chat with you and would love feedback: === How to contact the TC === You can reach out to the TC in multiple ways: 1. Email: you can send the email with the tag [tc] on this email list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel 3. Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [7] === Upcoming Events === 2024-08-14: Nominations open for 2025.1 OpenStack PTL+TC elections 2024-08-24: OpenInfra Days, Vietnam: https://2024.vietopeninfra.org/ 2024-08-29: Dalmatian-3 milestone Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] TC Diversity Requirement: https://governance.openstack.org/tc/reference/charter.html#tc-diversity-req… [3] Following up on affiliation diversity: https://review.opendev.org/c/openstack/governance/+/923876 [4] OpenInfra D&I initiatives and survey: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] D&I survey: https://openinfrafoundation.formstack.com/forms/openinfra_diversity_inclusi… [6] TC Meeting IRC Logs, 2024-07-09: https://meetings.opendev.org/meetings/tc/2024/tc.2024-07-09-18.00.log.html [7] TC Meeting, 2024-07-16: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Restricting User Deletion to Project Owners
by Thamanna Farhath 15 Jul '24

15 Jul '24

Hi OpenStack Community, I am working on a policy configuration to ensure that only owners of a project can delete users within their own project. Below is my current setup and the policy rules I have defined. Current Setup OpenStack deployment using Kolla Ansible 2023.1. Created an owner role with permissions to create, delete, and manage users and projects. But it allows you to delete users from other projects as well. So, I need to achieve the below scenario. Policy Rules yaml "admin_required": "role:admin" "admin_or_owner": "rule:admin_required or (role:owner and project_id:%(target.user.project_id)s)" "identity:delete_user": "rule:admin_or_owner" Scenario User demo with owner role of project X creates users newuser1 and newuser2 assigned to project X. User tester with owner role of project Y creates users myuser1 and myuser2 assigned to project Y. With the above configuration, I aim to ensure that: User demo can only delete newuser1 and newuser2 within project X. User tester can only delete myuser1 and myuser2 within project Y. Thank you for your support. 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."

2 3

[keystone] Keystone Single Sign-On for REST API Access
by leon.amtmann＠ibm.com 15 Jul '24

15 Jul '24

Hello OpenStack Community, and greetings especially to the Keystone experts among you. I'm currently co-administering an OpenStack 17.1.3 cluster with a few compute nodes and three controllers. For a better user experience, we've enabled Single Sign-On using OIDC for Horizon, which is working fabulously. To do that, the [mod_auth_openidc module](https://github.com/OpenIDC/mod_auth_openidc) is configured for httpd on the controller nodes. However, we're now facing a novel scenario for us. Basically, we want to interact with the OpenStack REST APIs - but not using a usual token request to `/v3/auth/tokens`, but using Single Sign-On. We've looked at the authentication request that Horizon makes to Keystone after successful authentication with the SSO provider. As far as we can tell: 1. After successful authentication with the SSO identity provider, Keystone redirects back to the redirect URI with a grant_id, id_token and state in the URL fragments (after # in the URL). 2. The redirect URI is `/v3/auth/OS-FEDERATION/websso/openid`, which contains HTML that will read the fragments and POST them as form data to somewhere. 3. Those fragments get POSTed to `/v3/auth/OS-FEDERATION/websso/openid`. 4. The response from Keystone is an HTML document containing an auth token, rigged to get POSTed to Horizon at `/dashboard/auth/websso/` (presumably to start a fresh session). So far, so good. The [Keystone federation documentation](https://docs.openstack.org/keystone/latest/admin/federation/… does show the [Horizon flow](https://docs.openstack.org/keystone/latest/admin/federation/introduct… in action. I can replicate it in part using cURL, by doing the same requests to the same endpoints that my browser does. However, I do not understand or see a request to `/v3/auth/OS-FEDERATION/websso/mapped` where Keystone actually issues a token. Instead, after the `id_token`, `grant_id`, etc. are POSTed to `/v3/auth/OS-FEDERATION/websso/openid`, Keystone responds with an HTML document containing the token (see step 4. in my earlier list). I've only seen this working for Horizon in an actual browser, though. Am I misunderstanding the documentation? Right above that in the documentation, there is a section about an unrelated [OpenID Connect Authentication Flow](https://docs.openstack.org/keystone/latest/admin/federation/introduct…. It contains a graphic in which the first request made is a GET request to `/secure`. A direct GET request yields a `404`, so I assume this is a placeholder for any protected resource. However, if I request any protected resource without a valid token, I do not receive a 302 as the graphic would seem to suggest. Is this a behavior that would need to be configured, first? In short: How does one end up with an unscoped token when trying to SSO against Keystone from something that is not Horizon? I'm just wondering if I am on the correct path in trying to modify the `10-keystone.wsgi` in `/etc/httpd/conf.d/` to use [multiple providers](https://github.com/OpenIDC/mod_auth_openidc/wiki/Multiple-Provid…. If, after starting the SSO process, I end up with a `grant_id` and an `id_token`, where do I post this to to get a Keystone token in return? After going through the documentation, I am still at a loss. I would appreciate any help. Thank you for your time.

4 3

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 15 Jul '24

15 Jul '24

Hi team, I'd like to skip IRC meeting this week since I'll be out of office. Thanks, Yasufumi

1 0

[barbican] Weekly meeting canceled Jul 15th
by Grzegorz Grasza 15 Jul '24

15 Jul '24

Hi all, I'll be traveling during our usual meeting hour, so I'm cancelling it this week. / Greg

1 0

[neutron] Bug Deputy Report July 8 - July 14
by Yatin Karel 14 Jul '24

14 Jul '24

Hi Neutrinos, Below is the bug deputy report for last week:- High ------ - https://bugs.launchpad.net/neutron/+bug/2072754 - Restarting octavia breaks IPv4 Load Balancers with health checks Assigned to Pavlo Shchelokovskyy - https://bugs.launchpad.net/neutron/+bug/2072567 - neutron-ovn-tempest-postgres-full job fails as oslo_db.exception.DBError: (psycopg2.errors.GroupingError) column "standardattributes_1.id" must appear in the GROUP BY clause or be used in an aggregate function Assigned to Rodolfo Alonso Medium ---------- - https://bugs.launchpad.net/neutron/+bug/2072978 - Show some error in logs when failing to load nb connection certificate Assigned to Chris Buggy Wishlist ---------- - https://bugs.launchpad.net/neutron/+bug/2072505 - [RFE] "External network not reachable from subnet" could take static routes into account Unassigned -- Thanks and Regards Yatin Karel

1 0

Making stestr scheduler smarter with a lot of threads
by Thomas Goirand 14 Jul '24

14 Jul '24

Hi, Currently, it looks like stestr calculate which thread should run which test at the beginning, by calculating some partition, and then launch all tests at once. With a lot of threads, the result is, at the end, only a few cores are in use, with all the others being idle. Would there be a way to have a pool of available threads instead, and have stestr to give threads something to eat when they are available, instead of the current way? How much work would that be? Cheers, Thomas Goirand (zigo)

4 3

Tenacity 8.4.2 breaking at least 4 OpenStack projects
by Thomas Goirand 14 Jul '24

14 Jul '24

Hi, It looks like Tenacity 8.4.2 broke a number of projects: - heat - ironic - octavia - python-octavia-lib I filed this for Octavia: https://bugs.launchpad.net/octavia/+bug/2073044 though I should probably do the same for the other projects. Unfortunately, someone uploaded Tenacity 8.4.2 to Debian unstable, so the packages are currently broken. :/ I'll see if the upload can be temporarily reverted, but the more long term solution is to fix the above projects and up the global requirements. Cheers, Thomas Goirand (zigo)

2 2

Subject: Assistance Needed: Restricting Owner Role to Manage Users and Projects Within Their Own Project
by Thamanna Farhath 13 Jul '24

13 Jul '24

Hi OpenStack Community, I am currently using openstack kolla ansible 2023.1, now facing an issue with the role-based access control in my OpenStack deployment.Could you please assist me in achieving my requirements for proper role configuration and access management? I have created a custom role named "owner" with permissions to create, delete, and manage users and projects, and also to assign users to projects. However, I want to restrict the "owner" role to manage only the users and projects within their own project, and not across other projects. Here is the policy file configuration(/etc/kolla/keystone/policy.yaml) I am using: yaml # Custom rule to allow users with the 'owner' role to manage users and projects identity:create_project: "role:owner or role:admin" admin_or_owner: "rule:admin_required or project_id:%(target.project.id)s" identity:delete_project: "rule:admin_or_owner" identity:delete_user: "rule:admin_or_owner" identity:create_user: "role:owner or role:admin" identity:get_user: "role:owner or role:admin or role:member or role:user" identity:list_users: "role:owner or role:admin" identity:update_user: "role:owner or role:admin" identity:create_grant: "role:owner or role:admin" identity:list_grants: "role:owner or role:admin" I have the following questions: Is the above policy configuration correct for achieving the desired restrictions? Are there any other possibilities or best practices to ensure that the "owner" role can only delete users and projects within their own project? How can I improve or adjust the policy rules to meet these requirements effectively? Thank you in advance for your assistance. ---- On Fri, 12 Jul 2024 10:49:22 +0530 Artem Goncharov <artem.goncharov(a)gmail.com> wrote --- Hi, 1) in Keystone we are currently working on implementing domain manager persona that allows certain person on a "customer" side to do project and user operations. This includes explicit listing of users in a domain 2) this is conceptually wrong to talk about users in a project, since users are owned by domains and can get access to multiple projects within the domain (and with some tricks to other domains). So you are partially right that role assignments is the way of figuring out access of users to projects. One more challenge though is that such access can be granted using user groups. In this case you actually should also resolve groups access to the desired project. Hope this helps, Artem ---- typed from mobile, auto-correct typos assumed ---- On Thu, Jul 11, 2024, 20:34 Thamanna Farhath <mailto:thamanna.f@zybisys.com> wrote: Hello openstack community, I am currently working on an OpenStack kolla ansible 2023.1. I have created a custom role " owner " Objective: Users with the owner role can only list users within their project. Avoid additional API calls for filtering users by project. Current Challenge: Using direct API calls, the list users API currently returns all users without any project-specific filtering. While additional API calls to the role_assignments endpoint can achieve the desired filtering, this approach is not efficient and doesn't restrict access at the API level. I am considering defining custom Keystone policies to achieve this restriction. However, I am unsure how to properly configure these policies to enforce project-specific access control effectively. Thanks in advance 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." 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."

1 0