On 03/17/2014 01:29 PM, Andrew Laski wrote:
On 03/17/14 at 01:11pm, Chris Friesen wrote:
On 03/17/2014 11:59 AM, John Garbutt wrote:
On 17 March 2014 17:54, John Garbutt <[email protected]> wrote:
Given the scheduler split, writing that value into the nova db from
the scheduler would be a step backwards, and it probably breaks lots
of code that assumes the host is not set until much later.
Why would that be a step backwards? The scheduler has picked a host
for the instance, so it seems reasonable to record that information in
the instance itself as early as possible (to be incorporated into
other decision-making) rather than have it be implicit in the
destination of the next RPC message.
Now I could believe that we have code that assumes that having
"instance.host" set implies that it's already running on that host,
but that's a different issue.
I forgot to mention, I am starting to be a fan of a two-phase commit
approach, which could deal with these kinds of things in a more
explicit way, before starting the main boot process.
Its not as elegant as a database transaction, but that doesn't seems
possible in the log run, but there could well be something I am
missing here too.
I'm not an expert in this area, so I'm curious why you think that
database transactions wouldn't be possible in the long run.
There has been some effort around splitting the scheduler out of Nova
and into its own project. So down the road the scheduler may not have
direct access to the Nova db.
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.
Chris
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
