Open Stack

Hi,

thanks a lot to all who have responded already!

Joe, thanks a lot for those comments. See below.


On 01.01.2014 01:14, Joe Gordon wrote:
>
>
>
>
>
> This sounds like what I would imagine should be a very common use 
> case, so it would be really great if we can support this. And as 
> always support means tested in gate.
Yes, I can imagine that this is a very common use case for large 
installations indeed. Fully agree.
>
> To put this in other terms, it sounds like you want one role to set 
> per project quota's, and another role to set user quotas for that 
> specific project 
> (https://blueprints.launchpad.net/nova/+spec/per-user-quotas).
>
> Both of those quota mechanisms exist today, but the roles you desire 
> do not exist by default.  So I think all that is needed to support 
> your use case is make sure nova works with your desired roles. That 
> involves fixing any issues and writing a test we can gate on.
>
> So I think the outcome of this work will consist of:
>
> * Changing the default policy.json file we use
> * An easy upgrade path
> * Documentation explaining the new default roles
> * Some small changes to nova to understand the new roles, along with 
> unit tests.
> * Tempest tests
>
>     I'd like to ask people for their opinion on how such a schema
>     should be implemented. There are several aspects which need to be
>     taken into account here:
>     - There are people with different roles in this game:
>       +- the main resource manager role is a super user role which can
>     but does not have to be identical to the cloud manager.
>          Persons with this role should be able to change all numbers
>     down in the tree. In general, the cloud manager and the resource
>     manager role are
>          not identical in my opinion. Persons with this role should
>     also be able to nominate other resource managers and give them a
>     fraction of the resources
>      +- a normal resource manager is a bit like the main resource
>     manager, with the exception that he can only manage the fraction
>     of the resources he was allocated by a person "above" him
>      +- a normal user: persons with this role can only consume resources
>
>
> This can be supported via our policy logic 
> (http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json). 
> By default we don't define that many roles by default.
Great! So maybe the roles issue is a much more easy one than we though 
initially.
>
>
>     - several people can have the same role. This is necessary to be
>     able to cover eg. holiday season or sick leave periods where one
>     manager is not available. Maybe introducing a group concept here
>     would be appropriate, in a way that roles are assigned to groups
>     and people are assigned to the groups instead of assigning roles
>     directly to individuals.
>
>
> I think keystone supports this today.
OK
>
>
>     - When I say "Quota" what I'm talking about is actually just a
>     number, eventually assigned with some unit. It could be a static
>     limit on a specific resource like number of VMs or the amount of
>     memory or disk space, or it could be something different like
>     computing performance or even something like a currency at the
>     longer term
>
>     - What is the right place to store such "groups" or "roles" ? What
>     do people think ?
>
>     We are currently only interested in limit settings for Nova. The
>     described ideas could be implemented as part of Nova, or as an
>     entirely independent external tool (which might be incorporated
>     later). IMO the latter approach has some advantages but I'd like
>     to hear peoples opinion about this.
>
>
> I think this should be directly in nova.
Yes. This will cover our main use case.


Keep in touch!
Ulrich

>
>     We'll have some man power available to work on the design and the
>     implementation of this so I'd expect to see some rapid progress if
>     everbody agrees that this is a useful thing to do.
>
>
>
> Great!
>
>
>     Thanks a lot for your comments/opinions!
>
>     Kind regards,
>     Ulrich
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140103/7776cda5/attachment.html>