Another use case where per flavour quotas would be helpful is bare metal provisioning: since the flavors are tied via the resource class to specific classes of physical machines, the usual instance/cores/RAM quotas do not help the user to see how many instances of which type can still be created.
Having per flavor (resource class, h/w type) projects is what we do for larger chunks of identical hardware, but this is less practical for users with access to fewer machines of many different types.
Cheers, Arne
On 30 Oct 2019, at 06:36, Massimo Sgaravatto massimo.sgaravatto@gmail.com wrote:
Thanks a lot for your feedbacks The possibility to quota flavours would indeed address also my use case.
Cheers, Massimo
On Tue, Oct 29, 2019 at 6:14 PM Tim Bell <Tim.Bell@cern.ch mailto:Tim.Bell@cern.ch> wrote: 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@redhat.com mailto:smooney@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-provide... 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-res... http://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-resources.html