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