[openstack-dev] [Nova] support for multiple active scheduler policies/drivers
GLIKSON at il.ibm.com
Tue Jul 23 20:24:09 UTC 2013
Russell Bryant <rbryant at redhat.com> wrote on 23/07/2013 07:19:48 PM:
> I understand the use case, but can't it just be achieved with 2 flavors
> and without this new aggreagte-policy mapping?
> flavor 1 with extra specs to say aggregate A and policy Y
> flavor 2 with extra specs to say aggregate B and policy Z
I agree that this approach is simpler to implement. One of the differences
is the level of enforcement that instances within an aggregate are managed
under the same policy. For example, nothing would prevent the admin to
define 2 flavors with conflicting policies that can be applied to the same
aggregate. Another aspect of the same problem is the case when admin wants
to apply 2 different policies in 2 aggregates with same
capabilities/properties. A natural way to distinguish between the two
would be to add an artificial property that would be different between the
two -- but then just specifying the policy would make most sense.
> > Well, I can think of few use-cases when the selection approach might
> > different. For example, it could be based on tenant properties
> > from some kind of SLA associated with the tenant, determining the
> > over-commit levels), or image properties (e.g., I want to determine
> > placement of Windows instances taking into account Windows licensing
> > considerations), etc
> Well, you can define tenant specific flavors that could have different
> policy configurations.
Would it possible to express something like 'I want CPU over-commit of 2.0
for tenants with SLA=GOLD, and 4.0 for tenants with SLA=SILVER'?
> I think I'd rather hold off on the extra complexity until there is a
> concrete implementation of something that requires and justifies it.
The extra complexity is actually not that huge.. we reuse the existing
mechanism of generic filters.
Regarding both suggestions -- I think the value of this blueprint will be
somewhat limited if we keep just the simplest version. But if people think
that it makes a lot of sense to do it in small increments -- we can
probably split the patch into smaller pieces.
> Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev