---- On Fri, 20 Jun 2025 06:13:08 -0700 Sean Mooney <smooney@redhat.com> wrote ---
On 20/06/2025 13:17, Andriy Kurilin wrote:
This sounds like something that ideally should be handled at the `nova.compute.api.API` level. That said, would you be open to aligning with best practices from the servers list API - specifically, elevating context when the user passes the |servers:detail:all_tenants| policy? Something like https://review.opendev.org/c/openstack/nova/+/952896
Would this be considered a low-impact API change, since it reuses already established logic? Or would it require a blueprint, broader discussion, a separate API microversion?
so this is a grey area
techinally all api change requrie a spec but we don tgenerally consider policy chagne to be api changes.
here you care not intoducting a new poilicy you are just applying it to an addtional endpoint.
list vs show.
if you were suggesting adding ajn all_tenatns query arg (which you are not) that woudl require a new api microversion.
issues related to using custom policy are only consider upstream bugs if they also happen with default policy, i.e. if this was broken for an admin then it woudl be a bug but if its only broken for your custom role its not. This would be a blueprint not a bug as a result but im unsure if we would require a spec or not for this specific case. If you wanted to do this more broadly i think we would want a spec to describe all the rest api impact and fully assess what if any upgrade impact those change would have and the possible security implications.
if you want to get more guidance on that i woudl suggest rasign it at next week irc meeting or seeing if others responed
I spent some time by checking history when it was made configurable for list APIs and not for Show (12 years back https://review.opendev.org/c/openstack/nova/+/16160) and why we should not enable it now for server show API. I could not find a solid reason not to do. Considering the below factors, I do not consider this a spec/microversion bump requried API change: * Backward compatibility: OK New policy default to 'Admin' keep it backward compatible. - With default policies (new policy default to Admin), nothing changed here for existing use case where admin query other projects or project query their own instance. - If anyone overridden 'servers:show' policy then it continue working same way for the above use case. new policy is not in effect for existing use cases. - There is difference in response from list detail vs show API so we are not going to expose any new info to non-admin users which they can do currently. I am ok to fix this as a bug fix but as Sean mentioned, let's put this in next week IRC meeting agenad to get more opinion on this. One thing I commented below about achieving the same via list detail and knowing why user do not want to do that can be a good things to consider this a bug fix.
you can work aroudn this by doing a server detail list with uuid=<vm uuid> and that will effectivly be the same as server show.
it will also be almost as efficient at the db level too.
The CLI does not support this filter, and even if it did, such behavior would break the expected user flow - i.e., users expect it to work with 'openstack server show'.
You can do this withbelow args in CLI, that will give the server detail of specified server from oterhr project. This is the common way to list single server from other project. "openstack server list --all-projects --project <project>" - https://docs.openstack.org/python-openstackclient/latest/cli/command-objects... Can you check if that works for user or if they want to do it with 'openstack server show' only then it will be good to know the reason and use case for that which can be a conviencing factor to add this ability in server show API also. This is something I would like to know to consider it a worth bug fix or we leave it as it is because there is way to do via other API. -gmaan
right so there you kind of hinting a fundamental mismatch between what the goals of the cli are and your goals in general we do not encourage operators to modify policy at all from upstream.
custom policy is support because we know in some environment it safe to allow some operation to have a difent policy then upstream each time you do that, you create an interop and documentation problem for users of your cloud but if an entirly private cloud that can be ok. on the tooling side the clinets are not allowed to have arguments that only work with non default policy alhtough they are alowed ot suprpot admin only apis. semantically the client shoudl call the show api not the list api when you do server show so osc is doign the corect thing today.
i provided this example because if your going to hevialy customerise your api policy you shoudl not expect to be abel to fully use those customization via horizon or the openstack client without writing your own plugings.