Open Stack

On 05/27/2016 04:23 AM, Dario Vianello wrote:
> 
>> On 25 May 2016, at 17:31, Tim Bell <Tim.Bell at cern.ch
>> <mailto:Tim.Bell at cern.ch>> wrote:
>>
>>
>> On 25/05/16 17:36, "Sean Dague" <sean at dague.net
>> <mailto: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.
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>> The Nova team is currently lacking information about the minimum number
>>> of user_id supporting policy points are needed. Because supporting
>>> user_id everywhere is definitely not going to be an option.
>>>
>>> We really need very detailed lists of which actions are required, and
>>> why. And for all server actions why "lock" action is not sufficient. And
>>> we need all of that by N1, which is in a week. With that we can evaluate
>>> what can be added to the API stack. Especially because this all needs
>>> tests so it doesn't regress. So if we can keep it at a small number of
>>> operations, it is way more likely to happen. If this grows to
>>> "everything", it definitely won't.
>>>
>>> It would honestly be great if people affected by this could also
>>> prioritize top to bottom what operations are most important. Detailed
>>> use case and priority is really needed to figure out what can be done.
>>>
>>
>> Thanks for looking into this. The current set of activities that our
>> developers want to do for their VMs (and do not want other doing to
>> their instances ☺ are
>>
>> - power off/power on/restart
>> - VNC console (since this also allows the above with appropriate SysRq)
>> - delete VM
>>
>> I think in the longer term, we’ll can work together to find a way to
>> do this with nested projects and some kind of automatic project
>> creation but without nested quotas and image sharing in the hierarchy
>> being priorities, these are not yet at functional parity compared to
>> the current Nova V2 implementation.
>>
>> Tim
> 
> Here at EMBL-EBI we are touched by this possible change in several ways:
> - to properly federate our OpenStack to the EGI FedCloud, which requires
> this feature. More on this coming, I hope somebody from the EGI will
> post here soon.
> - to support the same activities mentioned by Tim (power off/on/restart,
> console, VM deletion) in our about-to-come dev platform
> - to effectively support the long term of science scenario, where a
> single tenancy is shared by different independent researches to do their
> computation. 
> 
> I do agree that all this can be tackled by leveraging the nested
> projects, but especially for the FedCloud we are committed to deliver
> soon. Strip this feature out of Nova 2.1 would thus be an issue for us. 

Ok, but these are not the level of detail that we need to be actionable.
We realistically need an ordered list of every policy rule changed in
the importance of how that impacts things.

What is listed above is way too high level to understand any of that.
>From Tim we got a small list of actions, we can probably work with that.

And to be clear, this feature already doesn't exist in master as it went
away in the default implementation 2 releases ago. We're talking about
new feature development here, which is real work. And this feature will
be marked as deprecated when should it go in, so other alternatives are
going to need to be considered here.

	-Sean

-- 
Sean Dague
http://dague.net