<font size=2 face="sans-serif">It is certainly an interesting idea to
have a policy service managed via APIs, and to have scheduler as a potential
consumer of such as service. However, I suspect that this requires more
discussion, and certainly can't be added for Havana (you can count on me
to suggest it as a topic for the upcoming design summit).</font>
<br>
<br><font size=2 face="sans-serif">Moreover, I think the currently proposed
implementation (incorporating some of the initial feedback provided in
this thread) introduces 80% of the value, with 20% of the effort and complexity.</font>
<br>
<br><font size=2 face="sans-serif">If anyone has specific suggestions on
how to make it better without adding another 1000 lines of code -- I would
be more than glad to adjust.</font>
<br>
<br><font size=2 face="sans-serif">IMO, it is better to start simple in
Havana, start getting feedback from the field regarding specific usability/feature
requirements earlier rather than later, and incrementally improve going
forward. The current design provides clear added value, while not introducing
anything that would be conceptually difficult to change in the future (e.g.,
no new APIs, no schema changes, fully backwards compatible).</font>
<br>
<br><font size=2 face="sans-serif">By the way, the inspiration for the
current design was the multi-backend support in Cinder, where a similar
approach is used to define multiple Cinder backends in cinder.conf, and
to use a simple logic to select the appropriate one at runtime base on
the name of the corresponding section.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br><font size=2 face="sans-serif">P.S. the code is ready for review..
Jenkins is still failing, but this seems to be due to a bug which has been
reported, fixed and will be merged soon.</font>
<br>
<br>
<br><tt><font size=2>"Day, Phil" <philip.day@hp.com> wrote
on 28/07/2013 01:29:22 PM:<br>
<br>
> From: "Day, Phil" <philip.day@hp.com></font></tt>
<br><tt><font size=2>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
</font></tt>
<br><tt><font size=2>> Date: 28/07/2013 01:36 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [Nova] support for
multiple active <br>
> scheduler policies/drivers</font></tt>
<br><tt><font size=2>> <br>
> <br>
> <br>
> > From: Joe Gordon [</font></tt><a href=mailto:joe.gordon0@gmail.com><tt><font size=2>mailto:joe.gordon0@gmail.com</font></tt></a><tt><font size=2>]
<br>
> > Sent: 26 July 2013 23:16<br>
> > To: OpenStack Development Mailing List<br>
> > Subject: Re: [openstack-dev] [Nova] support for multiple active
<br>
> scheduler policies/drivers<br>
> ><br>
> ><br>
> >><br>
> >> On Wed, Jul 24, 2013 at 6:18 PM, Alex Glikson <GLIKSON@il.ibm.com>
wrote:<br>
> >>> Russell Bryant <rbryant@redhat.com> wrote on 24/07/2013
07:14:27 PM:<br>
> >><br>
> >> <br>
> >>> I really like your point about not needing to set things
up via a config<br>
> >>> file.  That's fairly limiting since you can't change
it on the fly via<br>
> >>> the API.<br>
> <br>
> >>True. As I pointed out in another response, the ultimate goal
<br>
> would be to have policies as 'first class citizens' in Nova, <br>
> including a DB table, API, >>etc. Maybe even a separate policy
<br>
> service? But in the meantime, it seems that the approach with config<br>
> file is a reasonable compromise in >>terms of usability, consistency<br>
> and simplicity. <br>
> <br>
> I think we need to be looking in the future to being able to <br>
> delegate large parts of the functionality that is currently "admin
<br>
> only" in Nova, and a large part of that is moving things like
this <br>
> from the config file into APIs.   Once we have the Domain capability<br>
> in ketystone fully available to services like Nova we  need to
think<br>
> more about ownership of resources like hosts, and being able to <br>
> delegate this kind of capability.<br>
> <br>
> <br>
> >I do like your idea of making policies first class citizens in
<br>
> Nova, but I am not sure doing this in nova is enough.  Wouldn't
we <br>
> need similar things >in Cinder and Neutron?    Unfortunately
this <br>
> does tie into how to do good scheduling across multiple services,
<br>
> which is another rabbit hole all >together.<br>
> ><br>
> > I don't like the idea of putting more logic in the config file,
as<br>
> it is the config files are already too complex, making running any
<br>
> OpenStack >deployment  require some config file templating
and some <br>
> metadata magic (like heat).   I would prefer to keep things like
<br>
> this in aggregates, or >something else with a REST API.  So
why not <br>
> build a tool on top of aggregates to push the appropriate metadata
<br>
> into the aggregates.  This will >give you a central point
to manage <br>
> policies, that can easily be updated on the fly (unlike config files).
 <br>
> <br>
> I agree with Jo on this point, and his is the approach we're taking
<br>
> with the Pcloud / whole-host-allocation blueprint:<br>
> <br>
> </font></tt><a href=https://review.openstack.org/#/c/38156/><tt><font size=2>https://review.openstack.org/#/c/38156/</font></tt></a><tt><font size=2><br>
> </font></tt><a href=https://wiki.openstack.org/wiki/WholeHostAllocation><tt><font size=2>https://wiki.openstack.org/wiki/WholeHostAllocation</font></tt></a><tt><font size=2><br>
> <br>
> I don't think realistically we'll be able to land this in Havana now<br>
> (as much as anything I don't think it had enough air time yet to be
<br>
> sure we have a consensus on all of the details) but Rackspace are
<br>
> now helping with part of this and we do expect to have something in
<br>
> a PoC / Demonstratable state for the Design Summit to provide a more<br>
> focused discussion.  Because the code is layered on top of existing
<br>
> aggregate and scheduler features its pretty easy to keep it as <br>
> something we can just keep rebasing.<br>
> <br>
> Regards,<br>
> Phil<br>
> <br>
> <br>
>  <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>