You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2010/07/22 18:49:09 UTC
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
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Aug 5, 2010 at 11:13 AM, Gary Dusbabek <gd...@gmail.com> wrote:
> On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis <jb...@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
Re: network compatibility from 0.6 to 0.7
Posted by Gary Dusbabek <gd...@gmail.com>.
On Thu, Aug 5, 2010 at 10:05, Jonathan Ellis <jb...@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
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <sy...@yakaz.com> 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 <gd...@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 <jb...@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
>>>
>>
>
--
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
Posted by Gary Dusbabek <gd...@gmail.com>.
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 <sy...@yakaz.com> 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 <gd...@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 <jb...@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
Posted by Sylvain Lebresne <sy...@yakaz.com>.
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 <gd...@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 <jb...@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
Posted by Gary Dusbabek <gd...@gmail.com>.
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 <jb...@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
Posted by Eric Evans <ee...@rackspace.com>.
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" <jb...@gmail.com>
> Sent: Thursday, July 22, 2010 11:49am
> To: cassandra-dev@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
eevans@rackspace.com
RE: network compatibility from 0.6 to 0.7
Posted by Stu Hood <st...@rackspace.com>.
> 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" <st...@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" <jb...@gmail.com>
Sent: Thursday, July 22, 2010 11:49am
To: cassandra-dev@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
Posted by Stu Hood <st...@rackspace.com>.
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" <jb...@gmail.com>
Sent: Thursday, July 22, 2010 11:49am
To: cassandra-dev@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
Posted by Tupshin Harper <tu...@tupshin.com>.
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" <jb...@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