Open Stack

We’ve had similar difficulties with a need to quota flavours .. cinder has a nice feature for this but with nova, I think we ended up creating two distinct projects and exposing the different flavours to the different projects, each with the related quota… from a user interface perspective, it means they’re switching projects more often than is ideal but it does control the limits.

Tim

> On 29 Oct 2019, at 17:17, Sean Mooney <smooney at redhat.com> wrote:
> 
> the normal way to achive this in the past would have been to create host aggreate and then 
> use the AggregateTypeAffinityFilter to map flavor to specific host aggrates.
> 
> so you can have a 2xOvercommit and a 4xOvercommit and map them to different host aggrates that have different over
> commit ratios set on the compute nodes.
> 
> On Tue, 2019-10-29 at 10:45 -0500, Eric Fried wrote:
>> Massimo-
>> 
>>> To decide if an instance should go to a compute node with or without
>>> overcommitment is easy; e.g. it could be done with host aggregates +
>>> setting metadata to the relevant flavors/images.
> ya that basicaly the same as what i said above
>> 
>> You could also use custom traits.
> traits would work yes it woudl be effectivly the same but would have the advatage of  having placment
> do most of the filtering so it should perform better.
>> 
>>> But is it in some  way possible to decide that a certain project has a
>>> quota of  x VCPUs without overcommitment, and y VCPUs with overcommitments ?
>> 
>> I'm not sure whether this helps, but it's easy to detect the allocation
>> ratio of a compute node's VCPU resource via placement with GET
>> /resource_providers/$cn_uuid/inventories/VCPU [1].
>> 
>> But breaking down a VCPU quota into different "classes" of VCPU
>> sounds... impossible to me.
> this is something that is not intended to be supported with unified limits at least not initially? ever?
>> 
>> But since you said
>> 
>>> In particular I would like to use some compute nodes without
>>> overcommitments
>> 
>> ...perhaps it would help you to use PCPUs instead of VCPUs for these. We
>> started reporting PCPUs in Train [2].
> ya pcpus are a good choice for the nova over commit case for cpus.
> hugepages are the equivalent for memory.
> idealy you should avoid disk over commit but if you have to do it use cinder when you
> need over commit and local storage whne you do not.
>> 
>> efried
>> 
>> [1]
>> 
> https://docs.openstack.org/api-ref/placement/?expanded=show-resource-provider-inventory-detail#show-resource-provider-inventory
>> [2]
>> http://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-resources.html
>> 
> 
>