Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Last I checked — and I could be wrong — we’ve never had to think about what to number a Cassandra version due to a ticket that could “impact” our users so dramatically due to the scope of the changes from a single ticket. Food for thought. love, kjellman > On May 11, 2015, at 2:20 PM, Alex Pop

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

On Mon, May 11, 2015 at 2:16 PM, Jonathan Haddad wrote: > I'm not sure if the complications surrounding the versioning of the drivers > should be factored into the releases of Cassandra. I agree. If we could come up with a versioning scheme that would also work for drivers, that would be the id

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Another option could be 2.1 -> 2.5* -> 3.0 This would still emphasize the major new features and changes in both versions. (*) unfortunately 2.5 would not help for drivers, so labeling 2.6 would get my +1. On Mon, May 11, 2015 at 2:09 PM, Jonathan Ellis wrote: > I do like 2.2 and 3.0 over 3.0

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

I'm not sure if the complications surrounding the versioning of the drivers should be factored into the releases of Cassandra. I think that 3.0 signals a massive change and calling the release containing 8099 a .1 would be drastically underplaying how big of a release it is - from the perspective

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

I do like 2.2 and 3.0 over 3.0 and 3.1 because going from 2.x to 3.x signals that 8099 really is a big change. On Mon, May 11, 2015 at 3:28 PM, Alex Popescu wrote: > On Sun, May 10, 2015 at 2:14 PM, Robert Stupp wrote: > > > Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so >

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

On Mon, May 11, 2015 at 1:41 PM, Aleksey Yeschenko wrote: > 3.0 to 2.2? Python and C# have already used 2.5 (I wouldn't have brought this up if I had other options). -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Can you not alter the version of the drivers, though? 3.0 to 2.2? --  AY On May 11, 2015 at 23:38:00, Alex Popescu (al...@datastax.com) wrote: On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko wrote: > The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 > will be

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Overall +1. I'm -0 on EOL of 2.0 once 2.2 is release. I'd rather keep 2.0 around till 3.0 comes out. As for 2.2 blockers, we might want to vet and make sure everything we need in protocol v4 is finished before we release 2.2 https://issues.apache.org/jira/browse/CASSANDRA-8043 On Sat, May 9, 20

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko wrote: > The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 > will be pushed shortly after 8099, and break things. Apologies, I didn't mean they are ready today. Version-wise, renaming this proposed 2.2 to 3.0 would allo

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Jeremiah - still need to worry about whether folks are doing CQL2 or CQL3 over cassandra-jdbc. If it is not in much use, that's fine by me. I just wanted to raise one place where folks might be using CQL2 without realizing it. On Mon, May 11, 2015 at 4:00 PM, Jeremiah Jordan wrote: > Cassandra

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 will be pushed shortly after 8099, and break things. --  AY On May 11, 2015 at 23:29:13, Alex Popescu (al...@datastax.com) wrote: On Sun, May 10, 2015 at 2:14 PM, Robert Stupp wrote: > Instead of labeling it 2.2, I’d

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

On Sun, May 10, 2015 at 2:14 PM, Robert Stupp wrote: > Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so > basically just move 8099 to 3.1). > In the end it’s ”only a label”. But there are a lot of new user-facing > features in it that justifies a major release. > +1 on labelin

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never recommend it) is that it does cql3 over thrift. So you lose out on all the native protocol features. > On May 11, 2015, at 2:53 PM, Brian Hess wrote: > > One thing that does jump out at me, though, is about CQL2. As

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Unresolved issues tagged for 2.2b1: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%20%222.2%20beta%201%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC On Mon, May 11, 2015 at 2:42 PM, Jonathan

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

One thing that does jump out at me, though, is about CQL2. As much as we have advised against using cassandra-jdbc, I have encountered a few that actually have used that as an integration point. I believe that cassandra-jdbc is CQL2-based, which is the main reason we have been advising folks agai

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko wrote: > > So I think EOLing 2.0.x when 2.2 comes > > out i

Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

Thanks also! I did it, JAVA-761 created! Regards, Carlos Juzarte Rolo Cassandra Consultant Pythian - Love your data rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo * Mob

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

> So I think EOLing 2.0.x when 2.2 comes  > out is reasonable, especially considering that 2.2 is realistically a month  > or two away even if we can get a beta out this week.  Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 a

Re: Wrap around CQL queries for token ranges?

That was an intentional decision on our side. Have a look at  https://issues.apache.org/jira/browse/CASSANDRA-5573 - Sylvain’s comment in particular. --  AY On May 11, 2015 at 20:05:54, Brian O'Neill (b...@alumni.brown.edu) wrote: Looks like the java-driver supplies the hack I need. (TokenRange

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko wrote: > 3.0, however, will require a stabilisation period, just by the nature of > it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and > 2.2 are, if you go purely by the feature list, but in fact the opposite is > true. > Y

Re: Wrap around CQL queries for token ranges?

Looks like the java-driver supplies the hack I need. (TokenRange.unwrap) I¹ll leave it to you guys to decide if it is more elegant to support wrapping natively in CQL. -brian --- Brian O'Neill Chief Technology Officer Health Market Science, a LexisNexis Company 215.588.6024 Mobile € @boneill42

Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

I hit this issue today with the c# driver. I still think the drivers should handle peers inconsistencies better and maybe even output warnings about them. I opened CSHARP-296, @rolo, it's probably a good idea to open a similar one for java. On May 11, 2015 11:24 AM, "Carlos Rolo" wrote: > Thanks

Wrap around CQL queries for token ranges?

I was doing some testing around data locality today (and adding it to our distributed processing layer). I retrieved all of the TokenRanges back using: tokenRanges = metadata.getTokenRanges(keyspace, localhost) And when I spun through the token ranges returned, I ended up missing records. The

Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

Thanks! Regards, Carlos Juzarte Rolo Cassandra Consultant Pythian - Love your data rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo * Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649 www.pythian.com On Mon, May 11, 201

Re: Nodes failed to bootstrap, no nodetool info but system.peer populated.

https://issues.apache.org/jira/browse/CASSANDRA-9180 On Mon, May 11, 2015 at 4:17 AM, Carlos Rolo wrote: > Hi all, > > I just wanted to know if this should be worth filling a bug or not > (Couldn't find any similar). > > I have a 3 node cluster (2.0.14). Decided to add 3 new ones. 2 failed > bec

Re: Stream sstables hosted on a node from client using streaming protocol

Yeah, at least you need to set up Schema for loading SSTable. If you find anything that we can improve, please file JIRA. On Sun, May 10, 2015 at 5:27 AM, Pierre Devops wrote: > OK so I know a little more now, it's not doable in client mode ATM because > it rely to much on server side stuff. > >

Nodes failed to bootstrap, no nodetool info but system.peer populated.

Hi all, I just wanted to know if this should be worth filling a bug or not (Couldn't find any similar). I have a 3 node cluster (2.0.14). Decided to add 3 new ones. 2 failed because of hardware failure (virtualized environment). The process was automated, so what was supposed to happen was: - N