On Wed, Mar 21, 2012 at 8:50 AM, Eric Evans <eev...@acunu.com> wrote: > I must admit I find this a little disheartening. The discussion has > barely started. No one has had a chance to discuss implementation > specifics so that the rest of us could understand *how* disruptive it > would be (a necessary requirement in weighing cost:benefit), or what > an incremental approach would look like, and yet work has already > begun on shutting this down.
This isn't the first time vnodes has been brought up, so I've thought at least a little bit about what that would entail for TokenMetadata, StorageProxy, streaming, CFS, and on down the stack. And it scares me. So, I wanted to make my points about cost:benefit and about not committing with intentions to work out the details "later," up front. But if you're still in brainstorming mode, carry on. > Unless I'm reading you wrong, your mandate (I say mandate because you > hinted at a veto elsewhere), is No to anything complex or invasive > (for some value of each). The only alternative would seem to be a > phased or incremental approach, but you seem to be saying No to that > as well. > > There seems to be quite a bit of interest in having virtual nodes (and > there has been for as long as I can remember), the only serious > reservations relate to the difficulty/complexity. Is there really no > way to put our heads together and figure out how to properly manage > that aspect? At the risk of putting words in your mouth, I think your concern is that you don't want to go off and put man-months into a vnode implementation, only to have me come back and say, "Sorry, it's too complicated, -1." Which is totally reasonable, I get that. I would suggest that the best way to mitigate that is, when you are ready, to put together as detailed an implementation plan as possible ahead of time before you start generating patchsets. Then we can put some meat on the discussion more meaningful than vague "that scares me" statements from yours truly. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
