nova team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

Like I said, my issues have been raised and addressed.  The community
seems to greatly be in favour of moving the patch forward, and I won't
hinder it any further. We're a community, after all, and the community
seems to have spoken in favour of the patch! Let's do it. :)  Unless
Rick has any more concerns, I say let's get on with it and get the
patch fully reviewed and merged in the next day or two so the baking
can begin.

-jay

On Mon, Sep 13, 2010 at 10:16 AM, Joshua McKenty <jmckenty@xxxxxxxxx> wrote:
> Jay,
> I share your concern about pulling Redis support, but I've talked already
> with Vish about getting that back in shortly. That issue aside, is there
> anything else blocking this one?
> Joshua
>
> On Mon, Sep 13, 2010 at 3:45 PM, Jay Pipes <jaypipes@xxxxxxxxx> 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
>
>