Open Stack

On 05/24/2016 02:22 AM, Jerome Pansanel wrote:
> Hi,
> 
> Le 23/05/2016 18:23, Sean Dague a écrit :
>> 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:
>>>>>  
>>>>>
> [...]
>>>>> 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.
> 
> The EGI Federated Cloud scenarios is almost the same. We have tenants
> for several projects and a "catch-all" tenant for small projects (1 or 2
> person per project). Therefore, it is important to be sure that a user
> from one project does not interact with VMs from another one.

Ok, but the catch-all project is just to have less "projects" allocated
in keystone right? Are these users using shared resources. I get there
is a convenience that no one is allocating projects... and this just
falls back to AD and people get in dynamically, but that seems like we
could solve project on demand differently.

I think part of the challenge here is that fundamentally project is
intended to be the unit of sharing. Because policy is so open ending
people did a bunch of things which effectively made nested projects,
which work in some cases, but might have some really odd edge conditions
based on what actions are enforced where. It also really breaks the
construct of

GET /servers

Being the list of servers you can do things to. Which... is a pretty
fundamental contract point in Nova. And confusing that point across
clouds makes it really hard for people to build software against the API
that your users can just use.

	-Sean

-- 
Sean Dague
http://dague.net