Open Stack

> On 25 May 2016, at 17:31, Tim Bell <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. 

Dario
> - 
>> 	-Sean
>> 
>> -- 
>> Sean Dague
>> http://dague.net <http://dague.net/>
>> 
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
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/20160527/c4730248/attachment.html>