On Mon, Mar 17, 2014 at 12:29 PM, Andrew Laski <andrew.la...@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 <j...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev