Re: network compatibility from 0.6 to 0.7
On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis jbel...@gmail.com wrote: The situation today is that network compatibility in trunk has been broken without us noticing for a while now -- in CASSANDRA-956 (according to git annotate) we changed ColumnFamily serialization in a non-backwards-compatible way. 956 was all about streaming, not CF serialization. Still, it breaks network compatibility with respect to streaming. The IClock changes were more likely to have broken CF serialization. Given the difficulty on the client side of mixing 0.6 and 0.7, most sites are going to end up doing a Big Bang upgrade anyway. So is it really worth a lot of effort on the network protocol side? My opinion: no. But I don't have to upgrade a huge cluster. Gary.
Re: network compatibility from 0.6 to 0.7
On Thu, Aug 5, 2010 at 11:13 AM, Gary Dusbabek gdusba...@gmail.com wrote: On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis jbel...@gmail.com wrote: The situation today is that network compatibility in trunk has been broken without us noticing for a while now -- in CASSANDRA-956 (according to git annotate) we changed ColumnFamily serialization in a non-backwards-compatible way. 956 was all about streaming, not CF serialization. Still, it breaks network compatibility with respect to streaming. The IClock changes were more likely to have broken CF serialization. In ColumnFamilySerializer the very first thing we used to read/write the CF name, and now we read/write a boolean as to whether the CF is null instead. That is from r947122: remove name field from cf and clean up. Patch by Stu Hood, reviewed by Gary Dusbabek. CASSANDRA-956 Perhaps the issue number was a typo, but either way it is logically an extension of the CF id changes from CASSANDRA-827 so it makes more sense to think of that as the culprit here. There may well be other problems deeper in as you say. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
network compatibility from 0.6 to 0.7
How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp - Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: network compatibility from 0.6 to 0.7
As long as network compatibility is in place, it is possible to incrementally upgrade a cluster by restricting thrift clients to only talk to the 0.6 nodes until half the cluster is upgraded and then modify them to talk to the 0.7 nodes. If networking compatibility breaks, there is no way to avoid downtime or even test 0.7 under production load. On Jul 22, 2010 9:50 AM, Jonathan Ellis jbel...@gmail.com wrote: How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp - Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
RE: network compatibility from 0.6 to 0.7
So I think we should probably try to preserve compatibility in 0.7. We could probably limit the scope of our network compatibility to steady-state messages, aka, nothing having to do with bootstrap, repair, etc. -Original Message- From: Stu Hood stu.h...@rackspace.com Sent: Thursday, July 22, 2010 12:35pm To: dev@cassandra.apache.org Subject: RE: network compatibility from 0.6 to 0.7 I feel like the next time we break network compatibility should be the last time, aka, the release when we introduce a backwards compatible RPC layer (Avro?), and implement support for dropping messages that a node can't handle. So I think we should probably try to preserve compatibility in 0.7. -Original Message- From: Jonathan Ellis jbel...@gmail.com Sent: Thursday, July 22, 2010 11:49am To: cassandra-...@incubator.apache.org Subject: network compatibility from 0.6 to 0.7 How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp - Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
Re: network compatibility from 0.6 to 0.7
What would be the pros of breaking it for 0.7 now ? I suppose you have something specific in mind that would break compatibility ? On Thu, Jul 22, 2010 at 8:19 PM, Gary Dusbabek gdusba...@gmail.com wrote: I think this depends on how much value users place in rolling upgrades (it's going to vary). My opinion is that we should be allowed to break it between major versions if required. Gary. On Thu, Jul 22, 2010 at 11:49, Jonathan Ellis jbel...@gmail.com wrote: How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp - Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
