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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 : [email protected] >> > Unsubscribe : https://launchpad.net/~nova >> > More help : https://help.launchpad.net/ListHelp >> > >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~nova >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~nova >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
