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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
