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