<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 12:52 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mon, 2014-03-17 at 12:39 -0700, Joe Gordon wrote:<br>
> On Mon, Mar 17, 2014 at 12:29 PM, Andrew Laski<br>
> <<a href="mailto:andrew.laski@rackspace.com">andrew.laski@rackspace.com</a>> wrote:<br>
> On 03/17/14 at 01:11pm, Chris Friesen wrote:<br>
> On 03/17/2014 11:59 AM, John Garbutt wrote:<br>
> On 17 March 2014 17:54, John Garbutt<br>
> <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>> wrote:<br>
><br>
> Given the scheduler split, writing<br>
> that value into the nova db from<br>
> the scheduler would be a step<br>
> backwards, and it probably breaks lots<br>
> of code that assumes the host is not<br>
> set until much later.<br>
><br>
> Why would that be a step backwards? The scheduler has<br>
> picked a host for the instance, so it seems reasonable<br>
> to record that information in the instance itself as<br>
> early as possible (to be incorporated into other<br>
> decision-making) rather than have it be implicit in<br>
> the destination of the next RPC message.<br>
><br>
> Now I could believe that we have code that assumes<br>
> that having "instance.host" set implies that it's<br>
> already running on that host, but that's a different<br>
> issue.<br>
><br>
> I forgot to mention, I am starting to be a fan<br>
> of a two-phase commit<br>
> approach, which could deal with these kinds of<br>
> things in a more<br>
> explicit way, before starting the main boot<br>
> process.<br>
><br>
> Its not as elegant as a database transaction,<br>
> but that doesn't seems<br>
> possible in the log run, but there could well<br>
> be something I am<br>
> missing here too.<br>
><br>
> I'm not an expert in this area, so I'm curious why you<br>
> think that database transactions wouldn't be possible<br>
> in the long run.<br>
><br>
><br>
> There has been some effort around splitting the scheduler out<br>
> of Nova and into its own project. So down the road the<br>
> scheduler may not have direct access to the Nova db.<br>
><br>
><br>
> If we do pull out the nova scheduler it can have its own DB, so I<br>
> don't think this should be an issue.<br>
<br>
</div></div>Just playing devil's advocate here, but even if Gantt had its own<br>
database, would that necessarily mean that there would be only a single<br>
database across the entire deployment? I'm thinking specifically in the<br>
case of cells, where presumably, scheduling requests would jump through<br>
multiple layers of Gantt services, would a single database transaction<br>
really be possible to effectively fence the entire scheduling request?<br></blockquote><div><br></div><div><br></div><div>So that opens the whole can of gantt and cells worms. I would rather evaluate design decisions more around what exists today and less on what we think will exist in the future (although we definitely don't want to design our selves into a corner). I'm just not very keen on the answer 'we shouldn't do x because of this thing we talked about but haven't done.'</div>
<div><br></div><div><div>That being said, this debate gets more complicated when you factor in the overhead of sqlalchemy, if we can drop that overhead we solve a lot of problems all at once (db is used all over the place both directly and through conductor, and sqlalchemy can have a 10x+ overhead).</div>
</div><div><br></div><div>For historical reasons we have spent a lot of time trying to decouple the SQL DB from the rest of the codebase, because we left the door open for alternate DB backends (re: noSQL). I think the ship has sailed on that one and we shouldn't spend worry about designing things around possibly adding in a noSQL backend in the future.</div>
<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Best,<br>
-jay<br>
<div class=""><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>