Open Stack

> On 27 May 2016, at 16:11, Sean Dague <sean at dague.net> wrote:
> 
> 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.
> 
Hi Sean,

yep, I agree that what Tim listed is a good staring point (also for us). 



> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Cheers,
Dario Vianello

Cloud Bioinformatics Application Architect
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Email: dario at ebi.ac.uk <mailto:dario at ebi.ac.uk>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160531/d8db6fff/attachment.html>