[ops][nova] Different quotas for different SLAs ?
Thanks a lot for your feedbacks
The possibility to quota flavours would indeed address also my use case.
On Tue, Oct 29, 2019 at 6:14 PM Tim Bell <Tim.Bell at 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.
> > 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
> > 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 .
> >> 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 .
> > 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
> >> 
> >> 
-------------- next part --------------
An HTML attachment was scrubbed...