[openstack-dev] [nova] question about e41fb84 "fix anti-affinity race condition on boot"
Joe Gordon
joe.gordon0 at gmail.com
Mon Mar 17 19:39:22 UTC 2014
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>
More information about the OpenStack-dev
mailing list