nova team mailing list archive

[Rick Clark <rick@xxxxxxxxxxxxx>]

Ok, guys, this has been a lively discussion, but it is time to make a
decision.  This will be the primary topic for tomorrow's release
meeting.  I like the patch, but I really think we need to add back redis
support, not because I love redis, just as a matter of how we manage
change in the project. The big question to me is where/when we merge it
and what it means to the release.

A few things to keep in mind:

 * OpenStack should avoid making technical decisions for implementers.
We should only mandate a technology if we have to, for reasons like
uniformity of the code, i.e the twisted debate, or because choice would
be difficult to implement.

 * I think we should try not to take sides in contentious technical
issues, unless we have to. My reaction was that this change could be
seen to be a statement about Redis, or NoSQL in general.

 * In general, if we are going to drop a major technology choice, we
should do it slowly, by deprecating it first.  We should never go into a
release requiring a technology and end the release with it totally
unsupported.  This is just not fair to our users.  We will make choices,
but we need to ensure smooth transitions for people that have
implemented Openstack.  I know it is less of an issue for our first
release, but good policy is good policy.

Rick





On 09/13/2010 08:45 AM, Jay Pipes wrote:
> Okay, so I was not debating the usefulness of Redis or any particular
> key-value store.  What I was concerned about was the sheer size of the
> patch and its impact on other branches so close to the code freeze
> date.
> 
> But, I've said my piece (peace?) :)  It sounds like all but myself and
> Rick are not troubled and feel the patch should move forward quickly.
> With concerns noted, I'm willing to see the patch go through as well,
> if only to see forward momentum and ease the migration burden post
> Austin.
> 
> -jay
> 
> On Fri, Sep 10, 2010 at 4:00 PM, Soren Hansen <soren@xxxxxxxxxx> wrote:
>> On 10-09-2010 19:51, Justin Santa Barbara wrote:
>>> So it seems the only potential use case for Redis is public
>>> clouds (Rackspace), for reasons of scalability.
>>
>> This has been mentioned a couple of times. I acknowledge the fact that
>> the NoSQL projects have excellent reputations in terms scalability, but
>> for Redis specifically, I just don't see it. It's got fast master-slave
>> replication, but you can only write to the master, and you can only have
>> one master, AFAICT. That doesn't sounds fantastically scalable to me, to
>> be honest.
>>
>>> My real hope was that we would be able to have both Redis and SQL
>>> implementations, and we'd show that not only did Redis have all these
>>> problems, but we didn't get anything in return: it would be both slower
>>> (because of 1+N) and less scalable (because of the need to keep all the keys
>>> in memory); we'd then deprecate Redis.  However, we need to stay focused on
>>> Nova and not proving a SQL/NoSQL point - if we know what the outcome will
>>> be, let's just go with the right choice and not expend effort on what is
>>> likely to be a technical dead-end.  If someone wants to write a Redis
>>> back-end so that it can be benchmarked and deprecated, that's great;
>>> otherwise I think we should merge the patch and forget about NoSQL.
>>>
>>> If we let Redis get into V1, then we're stuck supporting it, and we'll have
>>> to solve all the above problems.  I would prefer that development effort be
>>> focused on building IaaS, not a relational DB on top of a key-value store.
>>
>> I agree completely on all of this.
>>
>> --
>> Soren Hansen
>> Ubuntu Developer    http://www.ubuntu.com/
>> OpenStack Developer http://www.openstack.org/
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~nova
>> Post to     : nova@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~nova
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~nova
> Post to     : nova@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova
> More help   : https://help.launchpad.net/ListHelp

Attachment: signature.asc
Description: OpenPGP digital signature