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

[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

[keystone] Weekly Meeting Canceled 17-Jul-2024
by Dave Wilde 12 Jul '24

12 Jul '24

Hello, I'm canceling the Keystone weekly meeting for 17-Jul-2024 as I'll be on PTO. Please reach out to the mailing list or #openstack-keystone on IRC for assistance. Thanks, /Dave

1 0

Assistance Needed: Restricting User List API Access Based on Project Context
by Artem Goncharov 11 Jul '24

11 Jul '24

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 <thamanna.f(a)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:* > > 1. Users with the owner role can only list users within their project. > 2. 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."* > >

1 0

[ironic] SNMP hardware type
by Julia Kreger 11 Jul '24

11 Jul '24

Greetings folks, For those that are unaware of it, Ironic has an snmp[0] hardware type which allows for the remote control of power ports on an PDU, which makes Ironic powerful for a variety of non-traditional computing hardware to be leveraged with Ironic. If you are aware of this hardware type and happen to use it, you may want to engage with the Upstream community. Historically we've used a tool called virtualpdu[1] to facilitate testing, and we're facing some challenges with newer pysnmp[2] versions. These challenges have us wondering if there is value for us to fix virtualpdu and continue upstream testing. Realistically, if nobody steps forward to help maintain virtualpdu and the snmp hardware type, upstream testing may become limited or be discontinued for the snmp hardware type entirely, which is likely to impact users of this hardware type. If you're interested in helping maintain the hardware type and its testing, please reach out to the Ironic team via the weekly team meeting[3]. Thanks, -Julia [0]: https://docs.openstack.org/ironic/latest/admin/drivers/snmp.html [1]: https://opendev.org/openstack/virtualpdu [2]: https://pypi.org/project/pysnmp-lextudio/#history [3]: https://wiki.openstack.org/wiki/Meetings/Ironic

1 0

Assistance Needed: Restricting User List API Access Based on Project Context
by Thamanna Farhath 11 Jul '24

11 Jul '24

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."

2 1

[nova] "failure domain" scheduler
by Mohammed Naser 11 Jul '24

11 Jul '24

Hi everyone I had a discussion a few days ago in the #openstack-nova about the possibility of introducing the concept of different failure domains, which would be a component inside of an availability zone. The concept is similar to Azure’s availability set feature: https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-o… I’ve built a very similar nova scheduler filter which leverages server groups + another scheduler hint called `different_failure_domain` then it will actually build them inside different failure domains. The failure domains are built similar to AZs in terms of being modeled are using aggregates, so it would use a `failure_domain` aggregate metadata. I’ve managed to build and validate this functionality with my team here: https://github.com/vexxhost/nova-scheduler-filters Now, based on that, I’m wondering if: 1. Is this the best approach to take based on this? 2. Is this something we can upstream into Nova easily as an extra filter? I think this is helpful for a lot of the “VMware” world people. 😊 Thanks, Mohammed

2 1

numa filtering
by Gk Gk 11 Jul '24

11 Jul '24

How does the scheduler check the numa nodes availability in the background ? Does it use any db like placement to calculate the allocation, resource etc for numa ? I need just the logic in the scheduler for this check ? Thanks Y.G

2 1