Open Stack

On 04/22/2016 03:27 PM, Ed Leafe wrote:
> OK, so I know that Friday afternoons are usually the worst times to
> write a blog post and start an email discussion, and that the Friday
> immediately before a Summit is the absolute worst, but I did it anyway.
>
> http://blog.leafe.com/index.php/2016/04/22/distributed_data_nova/

Whee!! Well look - at least someone is still on email. Lucky you.

> Summary: we are creating way too much complexity by trying to make Nova
> handle things that are best handled by a distributed database. The
> recent split of the Nova DB into an API database and separate cell
> databases is the glaring example of going down the wrong road.
>
> Anyway, read it on your flight (or, in my case, drive) to Austin, and
> feel free to pull me aside to explain just how wrong I am. ;-)

So - I don't think you're wrong, but I don't think you're right either.

I think replacing nova's persistent storage layer with a distributed 
database would have a great effect - but I do not think it would have 
anything to do with the database itself. It would come from the act that 
would be completely necessary to accomplish that- completely rewriting 
the persistence layer.

There is nothing even remotely close to being unmanagable by MySQL at 
the scale that even an Amazon-sized public cloud on OpenStack would be 
producing ... if the database interaction layer were not the table-lock 
ridden giant-mess-of-joins thing we have. MySQL and Postgres ... really 
any RDBMS other than sqlite ... could TOTALLY handle the actions our 
persistence layer need at the scale they need them. And be bored.

However, replacing the persistence layer with another technology or with 
a rewrite using the same technology is not all that simple, and we have 
a huge install base. This leaves us in the unpleasant position of making 
incremental improvements to the current mess.

I am not a fan of cells v2. Like, not even close. It makes my database 
consultant background cringe and cry and shudder. It's exactly the 
"scaling" approach I used to get called in to fix. However- it 
ultimately doesn't matter if it's what I would design from scratch - 
because it _is_ implementable, which is better than my ideas currently 
are. And it makes incremental improvements. And maybe it buys us enough 
time that we CAN talk about giant projects like a complete and total 
rewrite of the storage layer.

Anyway - I hope this isn't' too negative - I enjoyed your post and agree 
with the sentiment. I just think the reality of the problem is that the 
first 80% of doing that would be a ton of fun and feel good, and in 4 
years we'd still be working on getting to bug-for-bug parity with the 
old thing so that we could suggest a migration.

Monty