On 11/09/14 19:05, Jay Pipes wrote:
On 09/11/2014 04:09 PM, Zane Bitter wrote:
Swift is the current exception here, but one could argue, and people
have[2], that Swift is also the only project that actually conforms to
our stated design tenets for OpenStack. I'd struggle to tell the Zaqar
folks they've done the Wrong Thing... especially when abandoning the
RDBMS driver was done largely at the direction of the TC iirc.
<snip>
[2] http://blog.linux2go.dk/2013/08/30/openstack-design-tenets-part-2/
No offense to Soren, who wrote some interesting and poignant things, nor
to the Swift developers, who continue to produce excellent work, but
Swift is object storage. It is a data plane system with a small API
surface, a very limited functional domain, and a small, inflexible
storage schema (which is perfectly fine for its use cases). It's needs
for a relational database are nearly non-existent. It replicates a
SQLite database around using rsync [1]. Try doing that with a schema of
any complexity and you will quickly find the limitations of such a
strategy.
If Nova was to take Soren's advice and implement its data-access layer
on top of Cassandra or Riak, we would just end up re-inventing SQL Joins
in Python-land. I've said it before, and I'll say it again. In Nova at
least, the SQL schema is complex because the problem domain is complex.
That means lots of relations, lots of JOINs, and that means the best way
to query for that data is via an RDBMS.
And I say that knowing just how *poor* some of the queries are in Nova!
I wasn't trying to suggest that Nova should change (if there was another
project I had in mind while reading that it would have been Heat, not
Nova). My point was that it's understandable that Zaqar, which is *also*
a data-plane service with a small API surface and a limited functional
domain, doesn't have the same architecture as Nova (just as Swift
doesn't) and that it's probably counter-productive to force it into that
architecture purely because a bunch of other things use it.
For projects like Swift, Zaqar, even Keystone, Glance and Cinder, a
non-RDBMS solution might be a perfectly reasonable solution for the
underlying data storage and access layer (and for the record, I never
said that Zaqar should or should not use an RDBMS for its storage). For
complex control plane software like Nova, though, an RDBMS is the best
tool for the job given the current lay of the land in open source data
storage solutions matched with Nova's complex query and transactional
requirements.
+1
Folks in these other programs have actually, you know, thought about
these kinds of things and had serious discussions about alternatives. It
would be nice to have someone acknowledge that instead of snarky
comments implying everyone else "has it wrong".
I didn't mean to imply that anybody else has it wrong (although FWIW I
do think that Heat probably has it wrong), and I apologise to anyone who
interpreted it that way.
Going back in my hole,
-jay
No! Let's talk about Zaqar :)
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
