[openstack-dev] [nova] question about e41fb84 "fix anti-affinity race condition on boot"
chris.friesen at windriver.com
Mon Mar 17 19:11:58 UTC 2014
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.
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.
More information about the OpenStack-dev