[openstack-dev] [nova] question about e41fb84 "fix anti-affinity race condition on boot"
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.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev