Bug 1342601 - Major change in functionality between Nova API v2.0 and v2.1
Summary: Major change in functionality between Nova API v2.0 and v2.1
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 8.0 (Liberty)
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Sylvain Bauza
QA Contact: Prasanth Anbalagan
Depends On: 1342596
TreeView+ depends on / blocked
Reported: 2016-06-03 16:07 UTC by Irina Petrova
Modified: 2019-11-14 08:16 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1342596
Last Closed: 2016-06-14 12:20:17 UTC
Target Upstream Version:

Attachments (Terms of Use)

Comment 7 Irina Petrova 2016-06-14 11:20:14 UTC
Hey Sylvain,

Whenever you have the time, could you please say a word or two on what are your thoughts about this? If you are aware of us having any way to implement authorization based on user_id, now or in the future?

Thanks in advance.


Comment 8 Sylvain Bauza 2016-06-14 12:20:17 UTC
So, the upstream consensus is that the policy modification using user_id was not something Nova was supporting because it was not verified (even not known, only by operators).

When the API version was bumped to v2.1, we then haven't checked if the non-supported features were yet fine. That's not something we can call it a regression if the non-supported feature was no longer working, as also it's not a API modification but rather only a fluke of the policy engine.

That said, the Nova upstream community understands it can be a feature for operators (at least for deleting instances only) and that's why the consensus was also to create a new blueprint (and a spec) for now supporting it in Newton (for v2.1 only since v2.0 is only stable/supported).

Given the above is not yet something merged upstream (even not yet accepted), I think we should WONTFIX the behaviour here for OSP8 (Liberty) and rather change the documentation to explicitly remove any comment about modifying the policy file for that, and rather tell to users that they can use the lock operation for making sure other users (from the same project) can't delete their own instances.

Comment 9 Irina Petrova 2016-06-14 12:59:55 UTC
(In reply to Sylvain Bauza from comment #8)

Awesome, thanks for the link, Sylvain.

Note You need to log in before you can comment on or make changes to this bug.