Open Stack

Do you think this new blueprint could help on this scenario?

https://blueprints.launchpad.net/nova/+spec/per-flavor-quotas

So you create the flavors with all the extra-specs that you need and then you could define quotas based on these flavors.


-----Original Message-----
From: Jay Pipes [mailto:jaypipes at gmail.com] 
Sent: Saturday, April 05, 2014 6:41 PM
To: Joe Topjian
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] Quota Templates

On Sat, 2014-04-05 at 14:56 -0600, Joe Topjian wrote:
> Hi Jay,
> 
>         The only problem with this is that what happens if an instance
>         type's
>         underlying resource allocation changes? Quotas and
>         reservations
>         generally need to be on the actual resources that are
>         consumed, not on
>         an abstract representation of those resources like an instance
>         type, due
>         to the fact that the abstract representation can changes over
>         time.
>         
>         My idea about the UI above works nicely with the idea of
>         changeable
>         instance types. The UI can do simple real-time calculations
>         about what a
>         quota allocation represents in terms of the actual resources
>         used by an
>         instance type.
> 
> 
> Yes, but there is nothing limiting a user to only a set amount of a 
> certain resource in a certain environment.
> 
> Perhaps I am misunderstanding this discussion, but here is an example 
> scenario of how I see it:
> 
> I have a small set of compute nodes that are configured in such a way 
> that make them "special" (SSD, GPU, etc). I can put those compute 
> nodes in a host aggregate and tie a series of flavors to that host 
> aggregate.
> 
> But since there is only one quota that the user has, there is nothing 
> that is preventing a user from hogging a large majority of the those 
> "special" nodes. For example, if a user has a quota of 500 cpus and 
> 800gb of memory, and if the "special" nodes collectively only have
> 1500 cpus and 2400gb of memory, the user could consume 1/3rd of the 
> special resources.
> 
> However, if I was able to tie a separate quota to that host aggregate, 
> I could give the user a quota of 50 cpus and 80gb of memory alongside 
> his standard quota of 500/800 for the rest of the cloud.
> 
> I greatly apologize if this scenario is *not* what Narayan was talking 
> about. In addition, this is not a feature that I'm personally in 
> desperate need for, but would definitely implement it if it was 
> available -- much more than a quota template.

Yes, the above scenario indeed is an interesting use case. Part of the issue is that with the addition of the "extra specs" part of the instance type, the instance type no longer represents just the dedicated resources that the a single instance of that type consumes, but also a free-form set of "capabilities" that the instance has -- GPU, SSD, etc.

The trick really is going to be about quantifying what those free-form qualitative "tags" like GPU actually represent when it comes to the consumption of resources in Nova. As it stands now, quota management has no real way of differentiating one CPU unit from another. I imagine that one solution to this would be to attach a "weighting factor" to each free-form instance type extra spec that would effectively multiply the actual resource that is consumed by the instance of that type by the factor, thereby producing a quantifiable value.

For example, let's say you had these two instance types:

 m1.small
  - 2GB memory
  - 10GB disk
  - 1 CPU

 g1.small
  - 2GB memory
  - 10GB disk
  - 1 CPU
  - extra_specs:
    - gpu
    - ssd

An admin might assign the "gpu" extra spec a weighting factor of "cpu:1.5" and the "ssd" extra spec a weighting factor of "disk:10.0".
This could be used by the quota management system to effectively give the g1.small instance type the following adjusted resource allocation:

 - 2GB memory
 - 1.5 CPU
 - 100GB disk

Make sense?

-jay




_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators