<tt><font size=2>"Day, Phil" <philip.day@hp.com> wrote
on 24/07/2013 12:39:16 PM:<br>
> <br>
> If you want to provide a user with a choice about how much overcommit</font></tt>
<br><tt><font size=2>> they will be exposed to then doing that in flavours
and the <br>
> aggregate_instance_extra_spec filter seems the more natural way to
<br>
> do this, since presumably you'd want to charge differently for those<br>
> and the flavour list is normally what is linked to the pricing model.
 </font></tt>
<br>
<br><tt><font size=2>So, there are 2 aspects here. First, whether policy
should be part of flavor definition or separate. I claim that in some cases
it would make sense to specify it separately. For example, if we want to
support multiple policies for the same virtual hardware configuration,
making policy to be part of the flavor extra spec would potentially multiply
the number of virtual hardware configurations, which is what flavors essentially
are, by the number of policies -- contributing to explosion in the number
of flavors in the system. Moreover, although in some cases you would want
the user to be aware and distinguish between policies, this is not always
the case. For example, the admin may want to apply consolidation/packing
policy in one aggregate, and spreading in another. Showing two different
flavors does seem reasonable in such cases. </font></tt>
<br>
<br><tt><font size=2>Secondly, even if the policy *is* defined in flavor
extra spec, I can see value in having a separate filter to handle it. I
personally see the main use-case for the extra spec filter in supporting
matching of capabilities. Resource management policy is something which
should be hidden, or at least abstracted, from the user. And enforcing
it with a separate filter could be a 'cleaner' design, and also more convenient
-- both from developer perspective and admin perspective.</font></tt>
<br><tt><font size=2><br>
> I also like the approach taken by the recent changes to the ram <br>
> filter where the scheduling characteristics are defined as <br>
> properties of the aggregate rather than separate stanzas in the <br>
> configuration file.</font></tt>
<br>
<br><tt><font size=2>Indeed, subset of the scenarios we had in mind can
be implemented by making each property of each filter/weight an explicit
key-value of the aggregate, and making each of the filters/weights aware
of those aggregate properties.</font></tt>
<br><tt><font size=2>However, our design have several potential advantages,
such as:</font></tt>
<br><tt><font size=2>1) different policies can have different sets of filters/weights</font></tt>
<br><tt><font size=2>2) different policies can be even enforced by different
drivers</font></tt>
<br><tt><font size=2>3) the configuration is more maintainable -- the admin
defines policies in one place, and not in 10 places (if you have large
environment with 10 aggregates). One of the side-effects is improved consistency
-- if the admin needs to change a policy, he needs to do it in one place,
and he can be sure that all the aggregates comply to one of the valid policies.
</font></tt>
<br><tt><font size=2>4) the developer of filters/weights does need to care
whether the parameters are persisted -- nova.conf or aggregate properties</font></tt>
<br>
<br><tt><font size=2>> An alternative, and the use case I'm most interested
in at the <br>
> moment, is where we want the user to be able to define the <br>
> scheduling policies on a specific set of hosts allocated to them (in<br>
> this case they pay for the host, so if they want to oversubscribe
on<br>
> memory/cpu/disk then they should be able to). </font></tt>
<br><tt><font size=2>[...]</font></tt>
<br><tt><font size=2>> Its not clear to me if what your proposing addresses
an additional <br>
> gap between this and the combination of the aggregate_extra_spec <br>
> filter + revised filters to get their configurations from aggregates)
?</font></tt>
<br>
<br><tt><font size=2>IMO, this can be done with our proposed implementation.
</font></tt>
<br><tt><font size=2>Going forward, I think that policies should be first-class
citizens (rather than static sections in nova.conf, or just sets of key-value
pairs associated with aggregates). Then we can provide APIs to manage them
in a more flexible manner.</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>> Cheers,<br>
> Phil<br>
> <br>
> > -----Original Message-----<br>
> > From: Russell Bryant [</font></tt><a href=mailto:rbryant@redhat.com><tt><font size=2>mailto:rbryant@redhat.com</font></tt></a><tt><font size=2>]<br>
> > Sent: 23 July 2013 22:32<br>
> > To: openstack-dev@lists.openstack.org<br>
> > Subject: Re: [openstack-dev] [Nova] support for multiple active
scheduler<br>
> > policies/drivers<br>
> > <br>
> > On 07/23/2013 04:24 PM, Alex Glikson wrote:<br>
> > > 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<br>
> > >> flavors and without this new aggreagte-policy mapping?<br>
> > >><br>
> > >> flavor 1 with extra specs to say aggregate A and policy
Y flavor 2<br>
> > >> with extra specs to say aggregate B and policy Z<br>
> > ><br>
> > > I agree that this approach is simpler to implement. One
of the<br>
> > > differences is the level of enforcement that instances within
an<br>
> > > aggregate are managed under the same policy. For example,
nothing<br>
> > > would prevent the admin to define 2 flavors with conflicting
policies<br>
> > > that can be applied to the same aggregate. Another aspect
of the same<br>
> > > problem is the case when admin wants to apply 2 different
policies in<br>
> > > 2 aggregates with same capabilities/properties. A natural
way to<br>
> > > distinguish between the two would be to add an artificial
property<br>
> > > that would be different between the two -- but then just
specifying<br>
> > > the policy would make most sense.<br>
> > <br>
> > I'm not sure I understand this.  I don't see anything here
that couldn't be<br>
> > accomplished with flavor extra specs.  Is that what you're
saying?<br>
> > Or are you saying there are cases that can not be set up using
<br>
> that approach?<br>
> > <br>
> > >> > Well, I can think of few use-cases when the selection
approach<br>
> > >> > might be different. For example, it could be based
on tenant<br>
> > >> > properties (derived from some kind of SLA associated
with the<br>
> > >> > tenant, determining the over-commit levels), or
image properties<br>
> > >> > (e.g., I want to determine placement of Windows
instances taking<br>
> > >> > into account Windows licensing considerations),
etc<br>
> > >><br>
> > >> Well, you can define tenant specific flavors that could
have<br>
> > >> different policy configurations.<br>
> > ><br>
> > > Would it possible to express something like 'I want CPU
over-commit of<br>
> > > 2.0 for tenants with SLA=GOLD, and 4.0 for tenants with
SLA=SILVER'?<br>
> > <br>
> > Sure.  Define policies for sla=gold and sla=silver, and
the flavors for each<br>
> > tenant would refer to those policies.<br>
> > <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.<br>
> > ><br>
> > > The extra complexity is actually not that huge.. we reuse
the existing<br>
> > > mechanism of generic filters.<br>
> > <br>
> > I just want to see something that actually requires it before
it <br>
> goes in.  I take<br>
> > exposing a pluggable interface very seriously.  I don't
want to expose more<br>
> > random plug points than necessary.<br>
> > <br>
> > > Regarding both suggestions -- I think the value of this
blueprint will<br>
> > > be somewhat limited if we keep just the simplest version.
But if<br>
> > > people think that it makes a lot of sense to do it in small
increments<br>
> > > -- we can probably split the patch into smaller pieces.<br>
> > <br>
> > I'm certainly not trying to diminish value, but I am looking
for <br>
> specific cases<br>
> > that can not be accomplished with a simpler solution.<br>
> > <br>
> > --<br>
> > Russell Bryant<br>
> > <br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
</font></tt>