Open Stack

On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague" <sean at dague.net> wrote:
> 
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>  
>>>
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for limiting actions by user. According to 
>>> https://bugs.launchpad.net/nova/+bug/1539351, this behavior was
>>> apparently not intended according to the bug report feedback. The
>>> behavior has changed from v2 to v2.1 and the old syntax no longer works.
>>
>> Well, the behavior changes with the backend code base. By mitaka the
>> default backend code for both is the same. And the legacy code base is
>> about to be removed.
>>
>> This feature (policy enforcement by user_id) was 100% untested, which is
>> why it never ended up in the new API stack. Being untested setting
>> owner: 'user_id: %(user_id)s' might have some really unexpected results
>> because not everything has a user_id.
>>
> 
> There are several hints given in the documentation regarding this sort of feature. 
> 
> Examples are such as http://docs.openstack.org/developer/oslo.policy/api.html and http://docs.openstack.org/mitaka/config-reference/policy-json-file.html#examples

Ok, so those are good points of documentation to bring back in line with
whatever reality we feel is the one to land on. Keeping user_id support
in Nova policy is going to require someone to write a lot of tests to
verify it, because it's never been in the current stack, again, because
it was never really implemented, because there were never any tests for
this scenario anywhere.

>>> There can be security implications also so I’d recommend those using
>>> this current v2 feature to review the bug to understand the potential
>>> impacts as clouds enable v2.1.
>>
>> While I understand from the bug report what your use case is now, I'm
>> kind of wondering what the shared resources / actions of these 150
>> people are in this project. Are they all in the same project for other
>> reasons?
> 
> The resource pool (i.e. quota) is shared between all of the developers.
> A smaller team is responsible for maintaining the image set for the project
> and also providing 2nd line support (such as reboot/problem diagnosis…).

Ok, so Bob can take up all the instances and go on vacation, and it's a
2nd line support call to handle shutting them down? It definitely
creates some weird situations where you can all pull from the pool, and
once pulled only you can give back.

What's the current policy patch look like? (i.e. which operations are
you changing to user_id).

> I do not know the EMBL-EBI use case or the EGI Federated Cloud scenarios
> which are also mentioned in the review.

Those would be good. I honestly think we need someone to start capturing
these in a spec, because a huge part of the disconnect here was this was
a backdoor feature that no one on the development side really understood
existed, was never tested, and didn't think it was the way things were
supposed to be working. And if we are bringing it back we really need to
capture the use cases a lot more clearly so in 5 years we don't do the
same thing again.

	-Sean

-- 
Sean Dague
http://dague.net