<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 3, 2014 at 4:05 AM, Soren Hansen <span dir="ltr"><<a href="mailto:soren@linux2go.dk" target="_blank">soren@linux2go.dk</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">I'm sorry about my slow responses. For some reason, gmail didn't think<br>
this was an important e-mail :(<br>
<span class=""><br>
2014-09-30 18:41 GMT+02:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>:<br>
> On 09/30/2014 08:03 AM, Soren Hansen wrote:<br>
>> 2014-09-12 1:05 GMT+02:00 Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>:<br>
</span><span class="">> How would I go about getting the associated fixed IPs for a network?<br>
> The query to get associated fixed IPs for a network [1] in Nova looks<br>
> like this:<br>
><br>
> SELECT<br>
>  fip.address,<br>
>  fip.instance_uuid,<br>
</span>[...]<br>
<span class="">> AND fip.instance_uuid IS NOT NULL<br>
> AND i.host = :host<br>
><br>
> would I have a Riak container for virtual_interfaces that would also<br>
> have instance information, network information, fixed_ip information?<br>
> How would I accomplish the query against a derived table that gets the<br>
> minimum virtual interface ID for each instance UUID?<br>
<br>
</span>What's a minimum virtual interface ID?<br>
<br>
Anyway, I think Clint answered this quite well.<br>
<span class=""><br>
>>> I've said it before, and I'll say it again. In Nova at least, the<br>
>>> SQL schema is complex because the problem domain is complex. That<br>
>>> means lots of relations, lots of JOINs, and that means the best way<br>
>>> to query for that data is via an RDBMS.<br>
</span>[...]<br>
<span class="">>> I don't think relying on a central data store is in any conceivable<br>
>> way appropriate for a project like OpenStack. Least of all Nova.<br>
>><br>
>> I don't see how we can build a highly available, distributed service<br>
>> on top of a centralized data store like MySQL.<br>
</span>[...]<br>
<span class="">> I don't disagree with anything you say above. At all.<br>
<br>
</span>Really? How can you agree that we can't "build a highly available,<br>
distributed service on top of a centralized data store like MySQL" while<br>
also saying that the best way to handle data in Nova is in an RDBMS?<br>
<span class=""><br>
>>> For complex control plane software like Nova, though, an RDBMS is<br>
>>> the best tool for the job given the current lay of the land in open<br>
>>> source data storage solutions matched with Nova's complex query and<br>
>>> transactional requirements.<br>
>> What transactional requirements?<br>
> <a href="https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L1654" target="_blank">https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L1654</a><br>
> When you delete an instance, you don't want the delete to just stop<br>
> half-way through the transaction and leave around a bunch of orphaned<br>
> children.  Similarly, when you reserve something, it helps to not have<br>
> a half-finished state change that you need to go clean up if something<br>
> goes boom.<br>
<br>
</span>Looking at that particular example, it's about deleting an instance and<br>
all its associated metadata. As we established earlier, these are things<br>
that would just be in the same key as the instance itself, so it'd just<br>
be a single key that would get deleted. Easy.<br>
<br>
That said, there will certainly be situations where there'll be a need<br>
for some sort of anti-entropy mechanism. It just so happens that those<br>
situations already exist. We're dealing with about a complex distributed<br>
system.  We're kidding ourselves if we think that any kind of<br>
consistency is guaranteed, just because our data store favours<br>
consistency over availability.<br>
<br></blockquote><div><br></div><div>I apologize if I'm missing something, but doesn't denormalization to add join support put the same value in many places, such that an update to that value is no longer a single atomic transaction? This would appear to counteract the requirement for strong consistency. If updating a single value is atomic (as in Riak's consistent mode) then it might be possible to construct a way to make multiple updates appear atomic, but it would add many more transactions and many more quorum checks, which would reduce performance to a crawl.</div><div><br></div><div>I also don't really see how a NoSQL system in strong consistency mode is any different from running MySQL with galera in its failure modes. The requirement for quorum makes the addition of nodes increase the potential latency of writes (and reads in some cases) so having large scale doesn't grant much benefit, if any. Quorum will also prevent nodes on the wrong side of a partition from being able to access system state (or it will give them stale state, which is probably just as bad in our case).</div><div><br></div><div>I think your goal of having state management that's able to handle network partitions is a good one, but I don't think the solution is as simple as swapping out where the state is stored. Maybe in some cases like split-racks the system needs to react to a network partition by forming its own independent cell with its own state storage, and when the network heals it then merges back into the other cluster cleanly? That would be very difficult to implement, but fun (for some definition of fun).<br></div><div><br></div><div>As a thought experiment, a while ago I considered what would happen if instead of using a central store, I put a sqlite database behind every daemon and allowed them to query each other for the data they needed, and cluster if needed (using raft). Services like nova-scheduler need strong consistency and would have to cluster to perform their role, but services like nova-compute would simply need to store the data concerning the resources they are responsible for. This follows the 'place state at the edge' kind of design principles that have been discussed in various circles. It falls down in a number of pretty obvious ways, and ultimately it would require more work than I am able to put in, but I mention it because perhaps it provides you with food for thought.</div><div><br></div><div>/architecture_astronaut</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">
> <a href="https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L3054" target="_blank">https://github.com/openstack/nova/blob/stable/icehouse/nova/db/sqlalchemy/api.py#L3054</a><br>
<br>
Sure, quotas will require stronger consistency. Any NoSQL data store<br>
worth its salt gives you primitives to implement that.<br></blockquote><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"><span class="">
>>> Folks in these other programs have actually, you know, thought about<br>
>>> these kinds of things and had serious discussions about<br>
>>> alternatives.  It would be nice to have someone acknowledge that<br>
>>> instead of snarky comments implying everyone else "has it wrong".<br>
>> I'm terribly sorry, but repeating over and over that an RDBMS is "the<br>
>> best tool" without further qualification than "Nova's data model is<br>
>> really complex" reads *exactly* like a snarky comment implying<br>
>> everyone else "has it wrong".<br>
> Sorry if I sound snarky. I thought your blog post was the definition<br>
> of snark.<br>
<br>
</span>I don't see the relevance of the tone of my blog post?<br>
<br>
You say it would be nice if people did something other than offer snarky<br>
comments implying everyone else "has it wrong".  I'm just pointing out<br>
that such requests ring really hollow when put forth in the very e-mail<br>
where you snarkily tell everyone else that they have it wrong.<br>
<br>
Since you did bring up my blog post, I really am astounded you find it<br>
snarky.  It was intended to be constructive and forward looking. The<br>
first one in the series, perhaps, but certainly not the one linked in<br>
this thread.<br>
<br>
Perhaps I need to take writing classes.<br>
<span class="im"><br>
--<br>
Soren Hansen             | <a href="http://linux2go.dk/" target="_blank">http://linux2go.dk/</a><br>
Ubuntu Developer         | <a href="http://www.ubuntu.com/" target="_blank">http://www.ubuntu.com/</a><br>
OpenStack Developer      | <a href="http://www.openstack.org/" target="_blank">http://www.openstack.org/</a><br>
<br>
</span><div class=""><div class="h5">_______________________________________________<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>