> On 27 May 2016, at 16:11, Sean Dague <[email protected]> wrote: > > On 05/27/2016 04:23 AM, Dario Vianello wrote: >> >>> On 25 May 2016, at 17:31, Tim Bell <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> On 25/05/16 17:36, "Sean Dague" <[email protected] >>> <mailto:[email protected]>> 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 > [email protected] > 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: [email protected] <mailto:[email protected]>
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
