Open Stack

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 
be
> > different. For example, it could be based on tenant properties 
(derived
> > 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.

Regards,
Alex

> -- 
> Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/931345c8/attachment.html>