Open Stack

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.