Open Stack

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 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.
>
> 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
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191030/677a4f01/attachment-0001.html>