So actually, how hard would it be to release a version of cassandra 6 which contained a second service Cassandra6 which was a replica of service Cassandra, then forward porting that service to Cassandra 7?
That would allow and upgrade to do the following 1. rolling upgrade 0.6 server to server with service Cassandra AND service Cassandra6 2. modify clients to use Cassandra6 service and perform rolling upgrade 3. rolling upgrade of 0.6 to 0.7 (this should work assuming you choose different ports for the cassandra gossip layer, right). 4. modify clients to use Cassandra 7 and perform rolling upgrade. It's a little messy but might work, maybe? The other solution I thought of would be to write a proxy which takes cassandra 6 thrift requests and spits out calls to a cassandra 6 or cassandra 7 server (or actually both for the transition), then point clients at that, then either side can update at any point. Of course in order to do that I have this feeling you'd have to do some low level hackery as I feel you would end up with symbol collision in the generated code. Anyway, it would be very nice if there were upgrade paths that were possible without downtime of both the clients and the server. -Anthony On Wed, Jan 19, 2011 at 05:05:02PM -0800, Anthony Molinaro wrote: > Really, my bad, I though they were, but maybe I'm confusing that with > protobuf, I work with too many serialization formats :(. > > -Anthony > > On Wed, Jan 19, 2011 at 04:46:48PM -0600, Jonathan Ellis wrote: > > > Of course that occurred to us, but method parameters cannot be > > optional in Thrift. > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder of Riptano, the source for professional Cassandra support > > http://riptano.com > > -- > ------------------------------------------------------------------------ > Anthony Molinaro <antho...@alumni.caltech.edu> -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu>
