- openstack-discuss - lists.openstack.org

Custom Role Configuration for Admin Activities in OpenStack
by Thamanna Farhath 24 Jun '25

24 Jun '25

Hi Team, As part of enhancing our OpenStack RBAC policy management, we are in the process of setting up custom roles for various admin-related activities. Custom Roles Used: admin_instance_read,admin_volume_read,admin_network_read,admin_glance_read Policy Customizations: # Compute - List all instances across tenants "os_compute_api:servers:index:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" "os_compute_api:servers:detail:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" # Network - Get networks (shared/external/own project) "get_network": "(rule:admin_only) or (role:reader and project_id:%(project_id)s) or rule:shared or rule:external or rule:context_is_advsvc or role:admin_network_read" # Volume - List all volumes and snapshots across projects "volume:get_all": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" "volume:get_all_snapshots": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" # Image - List all images including shared/community/public "get_image": "role:admin or (role:reader and project_id:%(project_id)s) or project_id:%(member_id)s or 'community':%(visibility)s or 'public':%(visibility)s or 'shared':%(visibility)s or role:admin_glance_read" "get_images": "role:admin or (role:reader and project_id:%(project_id)s) or role:admin_glance_read" Issue: Despite the above configurations, listing all instances, images, volumes, and networks across all projects still only works for the admin role. The custom roles (e.g., admin_instance_read, etc.) are not taking effect for cross-project visibility as expected. Request: I would appreciate any suggestions or insights on: Whether additional policy bindings or role scopes are required. If any service-specific constraints might be overriding the custom roles. Any known limitations regarding get_all_tenants behavior with custom roles. Thanks & Regards Thamanna Farhath N Associate engineer - R&D Zybisys IT consulting 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."

5 17

[nova] Information Sharing for Arm CCA Feature (Following 4/8 PTG)
by taketani.ryo＠fujitsu.com 23 Jun '25

23 Jun '25

Thank you for the productive discussion about Arm CCA feature [1] at the PTG on April 8th. > The use case for Arm CCA looks ok. But it is a bit early. It is wise to wait at least libvirt / qemu release to have a "stable" code. > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature The above information is quoted from the PTG Etherpad [2](L316) summary. I'd like to follow up on these points. I'd like to share relevant information about Arm CCA surrounding components (libvirt, QEMU, OS Distributions(e.g., Ubuntu xx.xx), hardware) as it becomes available, and proceed with the discussion step by step.. I'm starting with this email, but if there's a more appropriate method for sharing this type of information, please let me know. Here's the Arm CCA software components information I can share at this time: * Linux Kernel: The roadmap is outlined on the fifth page of the third attachment in this link [3]. The initial commits I've proposed to OpenStack are focused on RMM 1.0. KVM host support for RMM 1.0 will be available in H2 2025. * QEMU Upstream Status: The development is in-progress, awaiting the Linux Kernel merge * libvirt Upstream Status: The development is in-progress, awaiting the QEMU merge * OS Distribution Support: The road map is not clear now > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature I have a question regarding the above. For design discussions leading to spec approval, I understand that upstream QEMU/libvirt stable release is necessary. Is a specific OS distribution release (e.g., Ubuntu xx.xx) also required for spec approval? [1] https://review.opendev.org/c/openstack/nova-specs/+/938276 [2] https://etherpad.opendev.org/p/nova-2025.2-ptg [3] https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o… Regards, Ryo Taketani

3 10

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

23 Jun '25

Hello Stackers, We're fourteen weeks away from the coordinated 2025.2 "Flamingo" release of OpenStack [1], and Milestone-2 for this release is on 2025-07-03. In the past week, the Call for Papers for the upcoming OpenInfra Summit in Paris-Saclay ended; however, the deadline to propose Forum sessions and Project Updates sessions is 2025-07-08 at 23:59 PST [2]. This time at the summit, there's also a "New Contributor Showcase" inviting presentations on projects that leverage or support open infrastructure. Whether it’s your first contribution, an open source tool, or a collaboration with a community, we want to hear about it, so please consider applying [3]. In the past week, the OpenStack Technical Committee did not merge any new governance changes. A few change proposals are open for the community's input. OpenDev Infra administrators and OpenStack's Release Management team have posted several changes to begin enforcing the Developer Certificate of Origin in lieu of the Contributor License Agreement from July 1, 2025 [4]. If you haven't already begun using "git commit -s" to sign off your commits in adherence to the DCO, please do so. As a reminder, from July 1st, OpenDev's Gerrit system (https://review.opendev.org) will reject any changes that do not include a "Signed-off-by" line in the commit message. Simultaneously, the existing CLAs will no longer be available for new contributors to sign. === Weekly Meeting === The OpenStack Technical Committee met on OFTC's #openstack-tc channel on 2025-06-17 [5]. The team confirmed plans to transition to DCO (Developer Certificate of Origin) by July 1st, approving updates to the contributor guide and discussing the ongoing process of integrating DCO across tools and translations. We then focused on improving the contributor experience, with analyses of review metrics being shared with various project teams like Nova and Cinder through weekly IRC meetings. This data collection aims to identify pain points and best practices to inform future strategies. We plan to drive collective attention to this effort during the PTG in October. We also discussed the level of activity in the Cyborg project. We have had issues contacting the core maintainers to get some critical fixes merged, and the TC agreed to begin the process to mark the project "inactive." This decision aligns with the upcoming M-2 release deadline. The discussion also prompted a health check on several project teams. We'll be discussing this in further detail on proposals directly on Gerrit, or in a future weekly meeting. OpenDev Infra administrators completed a transition from Nodepool to Zuul-launcher and pleasantly have not seen any negative impact on the CI. During an Open Discussion, concerns were raised about the timeline specified by the Eventlet Removal TC goal [6]. Nova maintainers, in particular, expressed the need for more time to ensure a stable transition to threading and adequate operator testing, suggesting a revised target of 2028.1 for full Eventlet removal, a point that will be further debated on the mailing list [7] and a Gerrit proposal [8]. The next meeting of the OpenStack Technical Committee is on 2025-06-24. It will be hosted over IRC in OFTC's #openstack-tc channel at 1700 UTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Mark Cyborg inactive | https://review.opendev.org/c/openstack/governance/+/952798 === Upcoming Events === - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair

1 1

[neutron] Neutron CI meeting cancelled for today
by Yatin Karel 23 Jun '25

23 Jun '25

Hello Neutron Team !! Sorry for the last minute change as I got it conflicting with an internal meeting. We have some known intermittent issues as mentioned in https://etherpad.opendev.org/p/neutron-ci-meetings#L83. Will report the issues for those tomorrow. -- Thanks and Regards Yatin Karel

1 0

[horizon] Change option to delete volume when deleting instance
by Winicius Allan 23 Jun '25

23 Jun '25

Hello folks, Is there any option to change the default value to delete the volume when deleting the instance on Horizon? In the configuration reference[1], I only found this topic, but nothing about volume deletion [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#launc… Best regards.

2 1

[neutron] Bug deputy report for week 25 of 2025 (June 16th)
by Miguel Lavalle 22 Jun '25

22 Jun '25

I was the Neutron bug deputy last week. Following is a brief summary of the reported bugs: High bugs -------------- https://bugs.launchpad.net/neutron/+bug/2114732 grenade-skip-level-always job fails with: Security Group None cannot perform precommit_delete due to Callback. No owner https://bugs.launchpad.net/neutron/+bug/2115026 test_direct_route_for_address_scope and test_fip_connection_for_address_scope Functional test randomly fails. Assignee Yatin Karel. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952958 Medium ---------- https://bugs.launchpad.net/neutron/+bug/2114819 "tag" plugin is not case sensitive. Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952819 https://bugs.launchpad.net/neutron/+bug/2114919 dhcp_ready_on_ports() + fwaas might fail due to open transaction. Assignee Sebastian Lohff. Proposed fix https://review.opendev.org/c/openstack/neutron-fwaas/+/952852 merged https://bugs.launchpad.net/neutron/+bug/2115053 conntrack flow created for stateless SG rule. No owner Low ----- https://bugs.launchpad.net/neutron/+bug/2114832 [FT] ``test_agent_show_real_heartbeat_timestamp`` should check the timestamp in UTC timezone. Assignee Rodolfo Alonso. https://bugs.launchpad.net/neutron/+bug/2114909 [FT] Random errors in ``test_create_bridges`` . Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952828 merged

1 0

Inquiry on Integrating Ansible with Vendor-Specific Cinder Driver Code
by Sumit Gupta 21 Jun '25

21 Jun '25

Hello Moderators, We maintain a substantial body of open-source Ansible code (certified by Red Hat as a collection) for IBM Storage Virtualize, which we believe could directly benefit the Cinder driver roadmap. I’d like to understand whether it is technically and architecturally acceptable to invoke Ansible scripts from within a vendor-specific Cinder driver. Specifically: * Are there any guidelines or constraints on integrating external automation tools (like Ansible) within a Cinder driver implementation? * Is there any official documentation on the acceptance of such cross-language or framework integrations (e.g., calling Ansible from Python)? Your guidance would be greatly appreciated to ensure any contributions align with community standards and best practices. Thank you! Sumit K Gupta sumit.gupta16(a)ibm.com Senior Storage Leader, IBM

2 1

[eventlet-removal]When to drop eventlet support
by Balazs Gibizer 19 Jun '25

19 Jun '25

Hi Stackers! I would like to sync about the planned timeline of dropping eventlet support from OpenStack / Oslo. Nova definitely needs at least the full 2026.1 cycle to have a chance to transform the nova-compute service. But this plan already feels stretched based on the progress in the current cycle. So being conservative means we need the 2026.2 cycle as a buffer. Nova would like to keep a release where we support both eventlet and threading in parallel. So that operators can do the switching from eventlet to threading outside of the upgrade procedure. (This was an explicit request from them during the PTG). So 2026.2 could be that version where nova fully supports both concurrency mode, while eventlet can be marked deprecated. Then the 2027.1 release could be the first release dropping eventlet. However we need to align with the SLURP upgrade as well. 2026.1 is a SLURP. But in that release Nova might not be ready to have all services running in threading mode. So the 2026.1 - 2027.1 SLURP upgrade would force the operators to change the concurrency mode during the upgrade itself. I see two ways forward: * A) We say that operators who want to do the concurrency mode change outside of an upgrade could not skip the 2026.2 release, i.e. they cannot do SLURP directly from 2026.1. to 2027.1. * B) We keep supporting the eventlet mode in the 2027.1 release as well and only dropping support in 2028.1. What do you think? Cheers gibi

10 22

[Cinder] SystemReader & all_tenants filter issue
by skryhin＠godaddy.com 19 Jun '25

19 Jun '25

Hey Cinder team, We're running into a problem where our SystemReader role can't use the all_tenants filter when listing Cinder volumes (e.g., via `openstack volume list --all-projects`). The filter is getting stripped at the API layer here<https://github.com/openstack/cinder/blob/stable/2024.1/cinder/volume/api.py…>. This is a blocker for auditability and integrating with third-party CMDB systems, as granting full admin access for these tools isn't a secure option. We’ve seen similar functionality handled in other services like Nova (e.g., `os_compute_api:servers:index:get_all_tenants` for SystemReader), as well as in Keystone and Neutron via policy tuning. Is there a particular reason this pattern hasn’t been implemented yet in Cinder? And would it make sense to consider making this configurable via the `volume:get_all_tenants_filter` policy rule? Appreciate any insights! Best regards, Serhii K.

1 0

The Placement API endpoint was not found
by mitku.bade＠mitm-tech.com 18 Jun '25

18 Jun '25

I was trying to setup a three node (controller, compute, and neutron)openstack environment manually using ubuntu 22.04 and the openstack caracal 2024.1 release. Every instance that I have created went into cell0 ,while I expect it to went into cell1 .Plus, the cells and the hots mapping are correctly configured and are working without error .But, I face an error which related to the Placement API endpoint. Running nova-status upgrade check returns the Placement API with Failure , while the other checks such as cellV2 are successful. Also running the nova-scheduler log returns The placement API endpoint was not found :keystoneauth1.exceptions.catalog.endpointnotfound:couldnot find the requested endpoint in service catalog. I validated the [placement],[keystone_Authtoken],[DEFAULT]],[database] settings, the endpoint,service,role of placement to be correct .It has been many days .Any one to stretch his/her support on this ?

2 2