<div dir="ltr"><div><div><div><div>There is a global concern here about how an holistic scheduler can perform decisions, and from which key metrics.<br></div>The current effort is leading to having the Gantt DB updated thanks to resource tracker for scheduling appropriately the hosts.<br>
<br></div>If we consider these metrics as not enough, ie. that Gantt should perform an active check to another project, that's something which needs to be considered carefully. IMHO, on that case, Gantt should only access metrics thanks to the project REST API (and python client) in order to make sure that rolling upgrades could happen.<br>
</div>tl;dr: If Gantt requires accessing Nova data, it should request Nova REST API, and not perform database access directly (even thru the conductor)<br><br></div>-Sylvain<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-03-17 21:10 GMT+01:00 Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 03/17/2014 01:29 PM, Andrew Laski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/17/14 at 01:11pm, Chris Friesen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/17/2014 11:59 AM, John Garbutt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 17 March 2014 17:54, John Garbutt <<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>> wrote:<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Given the scheduler split, writing that value into the nova db from<br>
the scheduler would be a step backwards, and it probably breaks lots<br>
of code that assumes the host is not set until much later.<br>
</blockquote></blockquote>
<br>
Why would that be a step backwards?  The scheduler has picked a host<br>
for the instance, so it seems reasonable to record that information in<br>
the instance itself as early as possible (to be incorporated into<br>
other decision-making) rather than have it be implicit in the<br>
destination of the next RPC message.<br>
<br>
Now I could believe that we have code that assumes that having<br>
"instance.host" set implies that it's already running on that host,<br>
but that's a different issue.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I forgot to mention, I am starting to be a fan of a two-phase commit<br>
approach, which could deal with these kinds of things in a more<br>
explicit way, before starting the main boot process.<br>
<br>
Its not as elegant as a database transaction, but that doesn't seems<br>
possible in the log run, but there could well be something I am<br>
missing here too.<br>
</blockquote>
<br>
I'm not an expert in this area, so I'm curious why you think that<br>
database transactions wouldn't be possible in the long run.<br>
</blockquote>
<br>
There has been some effort around splitting the scheduler out of Nova<br>
and into its own project.  So down the road the scheduler may not have<br>
direct access to the Nova db.<br>
</blockquote>
<br>
<br></div></div>
Even if the scheduler itself doesn't have access to the nova DB, at some point we need to return back from the scheduler into a nova service (presumably nova-conductor) at which point we could update the nova db with the scheduler's decision and at that point we could check for conflicts and reschedule if necessary.<div class="HOEnZb">
<div class="h5"><br>
<br>
Chris<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>