<tt><font size=2>Russell Bryant <rbryant@redhat.com> wrote on 23/07/2013
07:19:48 PM:<br>
<br>
> I understand the use case, but can't it just be achieved with 2 flavors<br>
> and without this new aggreagte-policy mapping?<br>
> <br>
> flavor 1 with extra specs to say aggregate A and policy Y<br>
> flavor 2 with extra specs to say aggregate B and policy Z</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>> > Well, I can think of few use-cases when
the selection approach might be<br>
> > different. For example, it could be based on tenant properties
(derived<br>
> > from some kind of SLA associated with the tenant, determining
the<br>
> > over-commit levels), or image properties (e.g., I want to determine<br>
> > placement of Windows instances taking into account Windows licensing<br>
> > considerations), etc<br>
> <br>
> Well, you can define tenant specific flavors that could have different<br>
> policy configurations.</font></tt>
<br>
<br><tt><font size=2>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'?</font></tt>
<br><tt><font size=2><br>
> I think I'd rather hold off on the extra complexity until there is
a<br>
> concrete implementation of something that requires and justifies it.</font></tt>
<br>
<br><tt><font size=2>The extra complexity is actually not that huge.. we
reuse the existing mechanism of generic filters.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>
<br><tt><font size=2>> -- <br>
> Russell Bryant<br>
</font></tt>