Re: network compatibility from 0.6 to 0.7
On Thu, Aug 5, 2010 at 11:13 AM, Gary Dusbabek wrote: > On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis 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
Re: network compatibility from 0.6 to 0.7
On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis 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
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. 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? On Thu, Jul 22, 2010 at 5:35 PM, Sylvain Lebresne wrote: > 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 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 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 >>> >> > -- 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
On Thu, 2010-07-22 at 12:35 -0500, Stu Hood wrote: > 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. Yeah, I think a full cluster restart is the worst upgrade hurdle that we currently impose on users, and I wouldn't like to see us do it more than one last time. > So I think we should probably try to preserve compatibility in 0.7. It seems a little late to get it right for 0.7, so I agree. > -Original Message- > From: "Jonathan Ellis" > 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) -- Eric Evans eev...@rackspace.com
Re: network compatibility from 0.6 to 0.7
I don't know of any, but I presume Jonathan does, else he wouldn't have brought it up. On Thu, Jul 22, 2010 at 16:35, Sylvain Lebresne wrote: > 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 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 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
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 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 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
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 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" 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" 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
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" 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
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" 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
