<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Another use case where per flavour quotas would be helpful is bare metal provisioning:</div><div class="">since the flavors are tied via the resource class to specific classes of physical machines,</div><div class="">the usual instance/cores/RAM quotas do not help the user to see how many instances</div><div class="">of which type can still be created.</div><div class=""><br class=""></div><div class="">Having per flavor (resource class, h/w type) projects is what we do for larger chunks of</div><div class="">identical hardware, but this is less practical for users with access to fewer machines of</div><div class="">many different types.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""> Arne</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 30 Oct 2019, at 06:36, Massimo Sgaravatto <<a href="mailto:massimo.sgaravatto@gmail.com" class="">massimo.sgaravatto@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="">Thanks a lot for your feedbacks</div><div class="">The possibility to quota flavours would indeed address also my use case.</div><div class=""><br class=""></div><div class="">Cheers, Massimo</div><div class=""><br class=""></div><br class=""><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" class="">Tim.Bell@cern.ch</a>> wrote:<br class=""></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 class="">
<br class="">
Tim<br class="">
<br class="">
> On 29 Oct 2019, at 17:17, Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank" class="">smooney@redhat.com</a>> wrote:<br class="">
> <br class="">
> the normal way to achive this in the past would have been to create host aggreate and then <br class="">
> use the AggregateTypeAffinityFilter to map flavor to specific host aggrates.<br class="">
> <br class="">
> so you can have a 2xOvercommit and a 4xOvercommit and map them to different host aggrates that have different over<br class="">
> commit ratios set on the compute nodes.<br class="">
> <br class="">
> On Tue, 2019-10-29 at 10:45 -0500, Eric Fried wrote:<br class="">
>> Massimo-<br class="">
>> <br class="">
>>> To decide if an instance should go to a compute node with or without<br class="">
>>> overcommitment is easy; e.g. it could be done with host aggregates +<br class="">
>>> setting metadata to the relevant flavors/images.<br class="">
> ya that basicaly the same as what i said above<br class="">
>> <br class="">
>> You could also use custom traits.<br class="">
> traits would work yes it woudl be effectivly the same but would have the advatage of having placment<br class="">
> do most of the filtering so it should perform better.<br class="">
>> <br class="">
>>> But is it in some way possible to decide that a certain project has a<br class="">
>>> quota of x VCPUs without overcommitment, and y VCPUs with overcommitments ?<br class="">
>> <br class="">
>> I'm not sure whether this helps, but it's easy to detect the allocation<br class="">
>> ratio of a compute node's VCPU resource via placement with GET<br class="">
>> /resource_providers/$cn_uuid/inventories/VCPU [1].<br class="">
>> <br class="">
>> But breaking down a VCPU quota into different "classes" of VCPU<br class="">
>> sounds... impossible to me.<br class="">
> this is something that is not intended to be supported with unified limits at least not initially? ever?<br class="">
>> <br class="">
>> But since you said<br class="">
>> <br class="">
>>> In particular I would like to use some compute nodes without<br class="">
>>> overcommitments<br class="">
>> <br class="">
>> ...perhaps it would help you to use PCPUs instead of VCPUs for these. We<br class="">
>> started reporting PCPUs in Train [2].<br class="">
> ya pcpus are a good choice for the nova over commit case for cpus.<br class="">
> hugepages are the equivalent for memory.<br class="">
> idealy you should avoid disk over commit but if you have to do it use cinder when you<br class="">
> need over commit and local storage whne you do not.<br class="">
>> <br class="">
>> efried<br class="">
>> <br class="">
>> [1]<br class="">
>> <br class="">
> <a href="https://docs.openstack.org/api-ref/placement/?expanded=show-resource-provider-inventory-detail#show-resource-provider-inventory" rel="noreferrer" target="_blank" class="">https://docs.openstack.org/api-ref/placement/?expanded=show-resource-provider-inventory-detail#show-resource-provider-inventory</a><br class="">
>> [2]<br class="">
>> <a href="http://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-resources.html" rel="noreferrer" target="_blank" class="">http://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-resources.html</a><br class="">
>> <br class="">
> <br class="">
> <br class="">
<br class="">
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>