Open Stack

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 <john at johngarbutt.com> 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