Open Stack

On Mon, Mar 17, 2014 at 12:29 PM, Andrew Laski
<andrew.laski at rackspace.com>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.


If we do pull out the nova scheduler it can have its own DB, so I don't
think this should be an issue.


>
>
>
>> Given that the database is one of the few services that isn't prone to
>> races, it seems reasonable to me to implement decision-making as
>> transactions within the database.
>>
>> Where possible it seems to make a lot more sense to have the database do
>> an atomic transaction than to scan the database, extract a bunch of
>> (potentially unnecessary) data and transfer it over the network, do logic
>> in python, send the result back over the network and update the database
>> with the result.
>>
>> Chris
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/7564f5ca/attachment.html>