Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[sankalp kohli]

Hi Nate,
 Most of the JIRAs in the middle are being rebased or being
reviewed and code is already out there. These will make 4.0 a very solid
release.

Thanks,
Sankalp

On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead  wrote:

> We are happy to start testing against completed features. Ideally once
> everything is ready for an RC (to catch interaction bugs), but we can do
> sooner for features where it make sense and are finished earlier.
>
> On Thu, 17 Nov 2016 at 16:47 Nate McCall  wrote:
>
> > To sum up that other thread (I very much appreciate everyone's input,
> > btw), here is an aggregate list of large, breaking 4.0 proposed
> > changes:
> >
> > CASSANDRA-9425 Immutable node-local schema
> > CASSANDRA-10699 Strongly consistent schema alterations
> > --
> > CASSANDRA-12229 NIO streaming
> > CASSANDRA-8457 NIO messaging
> > CASSANDRA-12345 Gossip 2.0
> > CASSANDRA-9754 Birch trees
> > CASSANDRA-11559 enhanced node representation
> > CASSANDRA-6246 epaxos
> > CASSANDRA-7544 storage port configurable per node
> > --
> > CASSANDRA-5 remove thrift support
> > CASSANDRA-10857 dropping compact storage
> >
> > Again, this is the "big things that will probably break stuff" list
> > and thus should happen with a major (did I miss anything?). There
> > were/are/will be other smaller issues, but we don't really need to
> > keep them in front of us for this discussion as they can/will just
> > kind of happen w/o necessarily affecting anything else.
> >
> > That all said, since we are 'doing a software' we need to start
> > thinking about the above in balance with resources and time. However,
> > a lot of the above items do have a substantial amount of code written
> > against them so it's not as daunting as it seems.
> >
> > What I would like us to discuss is rough timelines and what is needed
> > to get these out the door.
> >
> > One thing that sticks out to me: that big chunk in the middle there is
> > coming out of the same shop in Cupertino. I'm nervous about that. Not
> > that that ya'll are not capable, I'm solely looking at it from the
> > "that is a big list of some pretty hard shit" perspective.
> >
> > So what else do we need to discuss to get these completed? How and
> > where can other folks pitch in?
> >
> > -Nate
> >
> --
> Ben Bromhead
> CTO | Instaclustr 
> +1 650 284 9692
> Managed Cassandra / Spark on AWS, Azure and Softlayer
>

[VOTE] Release Apache Cassandra 3.10 (Take 3)

[Michael Shuler]

I propose the following artifacts for release as 3.10.

sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1135/

The Debian packages are available here: http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) https://goo.gl/vah74X
[2]: (NEWS.txt) https://goo.gl/In3vp7



signature.asc
Description: OpenPGP digital signature

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[Jason Brown]

Hey all,

Here's an update on the following items:

NIO meassing/streaming - first is being reviewed; second is getting close
to review time
Gossip 2.0 - TL;DR I don't plan on moving cluster metadata (the current
"gossip" data) onto the new gossip/membership stack until 5.0, so it's not
a 4.0 blocker. I'll update #12345 with the details I'm thinking about. I
still want to start getting this code in, though, or at least in discussion.
Birch - on track
#11559 (enhanced node representation) - decided it's *not* something we
need wrt #7544 storage port configurable per node, so we are punting on
#11559
#6246 epaxos - if we're targeting Q1 2017 for 4.0, we probably can't get it
ready by then
#7544 storage port configurable per node - on track

So basically, I've removed two items off that list of blockers for 4.0.
Hope that helps

-Jason



On Fri, Nov 18, 2016 at 9:25 AM, sankalp kohli 
wrote:

> Hi Nate,
>  Most of the JIRAs in the middle are being rebased or being
> reviewed and code is already out there. These will make 4.0 a very solid
> release.
>
> Thanks,
> Sankalp
>
> On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead  wrote:
>
> > We are happy to start testing against completed features. Ideally once
> > everything is ready for an RC (to catch interaction bugs), but we can do
> > sooner for features where it make sense and are finished earlier.
> >
> > On Thu, 17 Nov 2016 at 16:47 Nate McCall  wrote:
> >
> > > To sum up that other thread (I very much appreciate everyone's input,
> > > btw), here is an aggregate list of large, breaking 4.0 proposed
> > > changes:
> > >
> > > CASSANDRA-9425 Immutable node-local schema
> > > CASSANDRA-10699 Strongly consistent schema alterations
> > > --
> > > CASSANDRA-12229 NIO streaming
> > > CASSANDRA-8457 NIO messaging
> > > CASSANDRA-12345 Gossip 2.0
> > > CASSANDRA-9754 Birch trees
> > > CASSANDRA-11559 enhanced node representation
> > > CASSANDRA-6246 epaxos
> > > CASSANDRA-7544 storage port configurable per node
> > > --
> > > CASSANDRA-5 remove thrift support
> > > CASSANDRA-10857 dropping compact storage
> > >
> > > Again, this is the "big things that will probably break stuff" list
> > > and thus should happen with a major (did I miss anything?). There
> > > were/are/will be other smaller issues, but we don't really need to
> > > keep them in front of us for this discussion as they can/will just
> > > kind of happen w/o necessarily affecting anything else.
> > >
> > > That all said, since we are 'doing a software' we need to start
> > > thinking about the above in balance with resources and time. However,
> > > a lot of the above items do have a substantial amount of code written
> > > against them so it's not as daunting as it seems.
> > >
> > > What I would like us to discuss is rough timelines and what is needed
> > > to get these out the door.
> > >
> > > One thing that sticks out to me: that big chunk in the middle there is
> > > coming out of the same shop in Cupertino. I'm nervous about that. Not
> > > that that ya'll are not capable, I'm solely looking at it from the
> > > "that is a big list of some pretty hard shit" perspective.
> > >
> > > So what else do we need to discuss to get these completed? How and
> > > where can other folks pitch in?
> > >
> > > -Nate
> > >
> > --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +1 650 284 9692
> > Managed Cassandra / Spark on AWS, Azure and Softlayer
> >
>

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

[Jeff Jirsa]

+1

On 2016-11-18 10:08 (-0800), Michael Shuler  wrote: 
> I propose the following artifacts for release as 3.10.
> 
> sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1135/
> 
> The Debian packages are available here: http://people.apache.org/~mshuler
> 
> The vote will be open for 72 hours (longer if needed).
> 
> [1]: (CHANGES.txt) https://goo.gl/vah74X
> [2]: (NEWS.txt) https://goo.gl/In3vp7
> 
> 

Node replacement failed in 2.2

[Dikang Gu]

Hi, I encountered couple times that I could not replace a down node due to
error:

2016-11-17_19:33:58.70075 Exception (java.lang.RuntimeException)
encountered during startup: Could not find tokens for
/2401:db00:2130:4091:face:0:13:0 to replace
2016-11-17_19:33:58.70489 ERROR 19:33:58 [main]: Exception encountered
during startup
2016-11-17_19:33:58.70491 java.lang.RuntimeException: Could not find tokens
for /2401:db00:2130:4091:face:0:13:0 to replace
2016-11-17_19:33:58.70491   at
org.apache.cassandra.service.StorageService.prepareReplacementInfo(StorageService.java:525)
~[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70492   at
org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:760)
~[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70492   at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:693)
~[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70492   at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:585)
~[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70492   at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:300)
[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70493   at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70493   at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:625)
[apache-cassandra-2.2.5+git20160315.c29948b.jar:2.2.5+git20160315.c29948b]
2016-11-17_19:33:58.70649 INFO  19:33:58 [StorageServiceShutdownHook]:
Announcing shutdown
2016-11-17_19:34:00.70967 INFO  19:34:00 [StorageServiceShutdownHook]:
Waiting for messaging service to quiesce
2016-11-17_19:34:00.71066 INFO  19:34:00
[ACCEPT-/2401:db00:2130:4091:face:0:13:0]: MessagingService has terminated
the accept() thread

Did not find a relevant ticket for this, is anyone aware of this?

Thanks!

-- 
Dikang

Re: Rough roadmap for 4.0

[Edward Capriolo]

These tickets claim to duplicate each other:

https://issues.apache.org/jira/browse/CASSANDRA-12674
https://issues.apache.org/jira/browse/CASSANDRA-12746

But one is marked fixed and the other is still open.

What is the status here?

On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan  wrote:

> Be very careful, there is a serious bug about AND/OR semantics, not solved
> yet and not going to be solved any soon:
> https://issues.apache.org/jira/browse/CASSANDRA-12674
>
> On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa 
> wrote:
>
> >
> > We’ll be voting in the very near future on timing of major releases and
> > release strategy. 4.0 won’t happen until that vote takes place.
> >
> > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > for production because it needs SASI.
> >
> > - Jeff
> >
> > On 11/17/16, 9:59 AM, "Jonathan Haddad"  wrote:
> >
> > >I think it might be worth considering adopting the release strategy
> before
> > >4.0 release.  Are any PMC members putting tick tock in prod? Does anyone
> > >even trust it?  What's the downside of changing the release cycle
> > >independently from 4.0?
> > >
> > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown 
> wrote:
> > >
> > >Jason,
> > >
> > >That's a separate topic, but we will have a different vote on how the
> > >branching/release strategy should be for the future.
> > >
> > >On Thursday, November 17, 2016, jason zhao yang <
> > zhaoyangsingap...@gmail.com
> > >>
> > >wrote:
> > >
> > >> Hi,
> > >>
> > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > >>
> > >> Stefan Podkowinski >于2016年11月16日周三
> > >> 下午4:52写道：
> > >>
> > >> > From my understanding, this will also effect EOL dates of other
> > >branches.
> > >> >
> > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> and
> > >3.0
> > >> > for six months after that.".
> > >> >
> > >> >
> > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall  > >> > wrote:
> > >> >
> > >> > > Agreed. As long as we have a goal I don't see why we have to
> adhere
> > to
> > >> > > arbitrary date for 4.0.
> > >> > >
> > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> alek...@datastax.com
> > >> >
> > >> > wrote:
> > >> > >
> > >> > > > I’ll comment on the broader issue, but right now I want to
> > elaborate
> > >> on
> > >> > > > 3.11/January/arbitrary cutoff date.
> > >> > > >
> > >> > > > Doesn’t matter what the original plan was. We should continue
> with
> > >> 3.X
> > >> > > > until all the 4.0 blockers have been
> > >> > > > committed - and there are quite a few of them remaining yet.
> > >> > > >
> > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > >personally
> > >> > be
> > >> > > > surprised if 4.0 comes out before
> > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > >> > > >
> > >> > > > —
> > >> > > > AY
> > >> > > >
> > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > >> > m...@thelastpickle.com 
> > >> > > )
> > >> > > > wrote:
> > >> > > >
> > >> > > > On 4 November 2016 at 13:47, Nate McCall  > >> > wrote:
> > >> > > >
> > >> > > > > Specifically, this should be "new stuff that could/will break
> > >> things"
> > >> > > > > given we are upping
> > >> > > > > the major version.
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > > How does this co-ordinate with the tick-tock versioning¹ leading
> > up
> > >> to
> > >> > > the
> > >> > > > 4.0 release?
> > >> > > >
> > >> > > > To just stop tick-tock and then say yeehaa let's jam in all the
> > >> > breaking
> > >> > > > changes we really want seems to be throwing away some of the
> > learnt
> > >> > > wisdom,
> > >> > > > and not doing a very sane transition from tick-tock to
> > >> > > > features/testing/stable². I really hope all this is done in a
> way
> > >> that
> > >> > > > continues us down the path towards a stable-master.
> > >> > > >
> > >> > > > For example, are we fixing the release of 4.0 to November? or
> > >> > continuing
> > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > >> > > > features/testing/stable branching approach with 3.11?
> > >> > > >
> > >> > > >
> > >> > > > Background:
> > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > >> > > >
> > >> > > > > And as 4.0 was initially supposed to come after 3.11, which is
> > >> > coming,
> > >> > > > it's probably time to have a home for those tickets.
> > >> > > >
> > >> > > > ²) The new versioning scheme slated for 4.0, per the "Proposal -
> > >> 3.5.1"
> > >> > > > thread
> > >> > > >
> > >> > > > > three branch plan with “features”, “testing”, and “stable”
> > >starting
> > >> > > with
> > >> > > > 4.0?
> > >> > > >
> > >> > > >
> > >> > > > Mick
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: Rough roadmap for 4.0

[Brandon Williams]

It's not marked fixed, it's marked resolved and the resolution is duplicate.

This is how all dupes are marked in jira.

On Fri, Nov 18, 2016 at 2:30 PM, Edward Capriolo 
wrote:

> These tickets claim to duplicate each other:
>
> https://issues.apache.org/jira/browse/CASSANDRA-12674
> https://issues.apache.org/jira/browse/CASSANDRA-12746
>
> But one is marked fixed and the other is still open.
>
> What is the status here?
>
> On Thu, Nov 17, 2016 at 5:20 PM, DuyHai Doan  wrote:
>
> > Be very careful, there is a serious bug about AND/OR semantics, not
> solved
> > yet and not going to be solved any soon:
> > https://issues.apache.org/jira/browse/CASSANDRA-12674
> >
> > On Thu, Nov 17, 2016 at 7:32 PM, Jeff Jirsa 
> > wrote:
> >
> > >
> > > We’ll be voting in the very near future on timing of major releases and
> > > release strategy. 4.0 won’t happen until that vote takes place.
> > >
> > > But since you asked, I have ONE tick/tock (3.9) cluster being qualified
> > > for production because it needs SASI.
> > >
> > > - Jeff
> > >
> > > On 11/17/16, 9:59 AM, "Jonathan Haddad"  wrote:
> > >
> > > >I think it might be worth considering adopting the release strategy
> > before
> > > >4.0 release.  Are any PMC members putting tick tock in prod? Does
> anyone
> > > >even trust it?  What's the downside of changing the release cycle
> > > >independently from 4.0?
> > > >
> > > >On Thu, Nov 17, 2016 at 9:03 AM Jason Brown 
> > wrote:
> > > >
> > > >Jason,
> > > >
> > > >That's a separate topic, but we will have a different vote on how the
> > > >branching/release strategy should be for the future.
> > > >
> > > >On Thursday, November 17, 2016, jason zhao yang <
> > > zhaoyangsingap...@gmail.com
> > > >>
> > > >wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Will we still use tick-tock release for 4.x and 4.0.x ?
> > > >>
> > > >> Stefan Podkowinski >于2016年11月16日周三
> > > >> 下午4:52写道：
> > > >>
> > > >> > From my understanding, this will also effect EOL dates of other
> > > >branches.
> > > >> >
> > > >> > "We will maintain the 2.2 stability series until 4.0 is released,
> > and
> > > >3.0
> > > >> > for six months after that.".
> > > >> >
> > > >> >
> > > >> > On Wed, Nov 16, 2016 at 5:34 AM, Nate McCall  > > >> > wrote:
> > > >> >
> > > >> > > Agreed. As long as we have a goal I don't see why we have to
> > adhere
> > > to
> > > >> > > arbitrary date for 4.0.
> > > >> > >
> > > >> > > On Nov 16, 2016 1:45 PM, "Aleksey Yeschenko" <
> > alek...@datastax.com
> > > >> >
> > > >> > wrote:
> > > >> > >
> > > >> > > > I’ll comment on the broader issue, but right now I want to
> > > elaborate
> > > >> on
> > > >> > > > 3.11/January/arbitrary cutoff date.
> > > >> > > >
> > > >> > > > Doesn’t matter what the original plan was. We should continue
> > with
> > > >> 3.X
> > > >> > > > until all the 4.0 blockers have been
> > > >> > > > committed - and there are quite a few of them remaining yet.
> > > >> > > >
> > > >> > > > So given all the holidays, and the tickets remaining, I’ll
> > > >personally
> > > >> > be
> > > >> > > > surprised if 4.0 comes out before
> > > >> > > > February/March and 3.13/3.14. Nor do I think it’s an issue.
> > > >> > > >
> > > >> > > > —
> > > >> > > > AY
> > > >> > > >
> > > >> > > > On 16 November 2016 at 00:39:03, Mick Semb Wever (
> > > >> > m...@thelastpickle.com 
> > > >> > > )
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > On 4 November 2016 at 13:47, Nate McCall  > > >> > wrote:
> > > >> > > >
> > > >> > > > > Specifically, this should be "new stuff that could/will
> break
> > > >> things"
> > > >> > > > > given we are upping
> > > >> > > > > the major version.
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > How does this co-ordinate with the tick-tock versioning¹
> leading
> > > up
> > > >> to
> > > >> > > the
> > > >> > > > 4.0 release?
> > > >> > > >
> > > >> > > > To just stop tick-tock and then say yeehaa let's jam in all
> the
> > > >> > breaking
> > > >> > > > changes we really want seems to be throwing away some of the
> > > learnt
> > > >> > > wisdom,
> > > >> > > > and not doing a very sane transition from tick-tock to
> > > >> > > > features/testing/stable². I really hope all this is done in a
> > way
> > > >> that
> > > >> > > > continues us down the path towards a stable-master.
> > > >> > > >
> > > >> > > > For example, are we fixing the release of 4.0 to November? or
> > > >> > continuing
> > > >> > > > tick-tocks until we complete the 4.0 roadmap? or starting the
> > > >> > > > features/testing/stable branching approach with 3.11?
> > > >> > > >
> > > >> > > >
> > > >> > > > Background:
> > > >> > > > ¹) Sylvain wrote in an earlier thread titled "A Home for 4.0"
> > > >> > > >
> > > >> > > > > And as 4.0 was initially supposed to come after 3.11, which
> is
> > > >> > coming,
> > > >> > > > it's probably time to have a home for those tickets.
> > > >> > > >
> > > >> > > > ²) The new versioning scheme slated for 4.0, per the
> "Proposal -
> > > >> 3.5.1"
> > > 

Cassandra Mutation object decoding

[Sanal Vasudevan]

Hi there,

I am trying to read the Commit logs to decode the original CQL which used.
I get to the point an implemention of  CommitLogReadHandler is able to push
back Mutation objects from the Commit logs.

Questions:
1) CQL: delete from myks.mytable where key1  = 1;
For the above CQL, the Mutation object has zero objects of
org.apache.cassandra.db.rows.Row inside ParitionUpdate object.
Is this the only way to detect a DELETE operation? or we have any other
metadata to indicate a DELETE operation?
mutation.getPartitionUpdates().forEach(rows -> { if(rows.isEmpty())
System.out.println("May be a DELETE operation") });
2) Likewise do we have metadata inside Mutation object to decode whether
the CQL was an INSERT or UPDATE operation?

Josh Mckenzie indicated that PartitionUpdate.deletionInfo
(MutableDeletionInfo) may have some information but deletionInfo is private.

Basically, I am looking for help to find a way to classify Mutation object
to INSERT/UPDATE/DELETE with related column and key information.

Many thanks.
-- 
Sanal

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[Blake Eggleston]

Introducing all of these in a single release seems pretty risky. I think it 
would be safer to spread these out over a few 4.x releases (as they’re 
finished) and give them time to stabilize before including them in an LTS 
release. The downside would be having to maintain backwards compatibility 
across the 4.x versions, but that seems preferable to delaying the release of 
4.0 to include these, and having another big bang release.

The other problem here is uncertainty about the frequency and length of support 
of so called LTS releases. There was a thread about getting off of tick-tock a 
while ago, but it died without coming to any kind of conclusion. Personally, 
I’d like to see us do (non-dev) releases every 6 months, support them for 1 
year, and critical fixes for 2 years.


On November 18, 2016 at 10:25:31 AM, Jason Brown (jasedbr...@gmail.com) wrote:

Hey all,  

Here's an update on the following items:  

NIO meassing/streaming - first is being reviewed; second is getting close  
to review time  
Gossip 2.0 - TL;DR I don't plan on moving cluster metadata (the current  
"gossip" data) onto the new gossip/membership stack until 5.0, so it's not  
a 4.0 blocker. I'll update #12345 with the details I'm thinking about. I  
still want to start getting this code in, though, or at least in discussion.  
Birch - on track  
#11559 (enhanced node representation) - decided it's *not* something we  
need wrt #7544 storage port configurable per node, so we are punting on  
#11559  
#6246 epaxos - if we're targeting Q1 2017 for 4.0, we probably can't get it  
ready by then  
#7544 storage port configurable per node - on track  

So basically, I've removed two items off that list of blockers for 4.0.  
Hope that helps  

-Jason  



On Fri, Nov 18, 2016 at 9:25 AM, sankalp kohli   
wrote:  

> Hi Nate,  
> Most of the JIRAs in the middle are being rebased or being  
> reviewed and code is already out there. These will make 4.0 a very solid  
> release.  
>  
> Thanks,  
> Sankalp  
>  
> On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead  wrote:  
>  
> > We are happy to start testing against completed features. Ideally once  
> > everything is ready for an RC (to catch interaction bugs), but we can do  
> > sooner for features where it make sense and are finished earlier.  
> >  
> > On Thu, 17 Nov 2016 at 16:47 Nate McCall  wrote:  
> >  
> > > To sum up that other thread (I very much appreciate everyone's input,  
> > > btw), here is an aggregate list of large, breaking 4.0 proposed  
> > > changes:  
> > >  
> > > CASSANDRA-9425 Immutable node-local schema  
> > > CASSANDRA-10699 Strongly consistent schema alterations  
> > > --  
> > > CASSANDRA-12229 NIO streaming  
> > > CASSANDRA-8457 NIO messaging  
> > > CASSANDRA-12345 Gossip 2.0  
> > > CASSANDRA-9754 Birch trees  
> > > CASSANDRA-11559 enhanced node representation  
> > > CASSANDRA-6246 epaxos  
> > > CASSANDRA-7544 storage port configurable per node  
> > > --  
> > > CASSANDRA-5 remove thrift support  
> > > CASSANDRA-10857 dropping compact storage  
> > >  
> > > Again, this is the "big things that will probably break stuff" list  
> > > and thus should happen with a major (did I miss anything?). There  
> > > were/are/will be other smaller issues, but we don't really need to  
> > > keep them in front of us for this discussion as they can/will just  
> > > kind of happen w/o necessarily affecting anything else.  
> > >  
> > > That all said, since we are 'doing a software' we need to start  
> > > thinking about the above in balance with resources and time. However,  
> > > a lot of the above items do have a substantial amount of code written  
> > > against them so it's not as daunting as it seems.  
> > >  
> > > What I would like us to discuss is rough timelines and what is needed  
> > > to get these out the door.  
> > >  
> > > One thing that sticks out to me: that big chunk in the middle there is  
> > > coming out of the same shop in Cupertino. I'm nervous about that. Not  
> > > that that ya'll are not capable, I'm solely looking at it from the  
> > > "that is a big list of some pretty hard shit" perspective.  
> > >  
> > > So what else do we need to discuss to get these completed? How and  
> > > where can other folks pitch in?  
> > >  
> > > -Nate  
> > >  
> > --  
> > Ben Bromhead  
> > CTO | Instaclustr   
> > +1 650 284 9692  
> > Managed Cassandra / Spark on AWS, Azure and Softlayer  
> >  
>  

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[kurt Greaves]

On 18 November 2016 at 18:25, Jason Brown  wrote:

> #11559 (enhanced node representation) - decided it's *not* something we
> need wrt #7544 storage port configurable per node, so we are punting on
>

#12344 - Forward writes to replacement node with same address during replace

depends on #11559. To be honest I'd say #12344 is pretty important,
otherwise it makes it difficult to replace nodes without potentially
requiring client code/configuration changes. It would be nice to get #12344
in for 4.0. It's marked as an improvement but I'd consider it a bug and
thus think it could be included in a later minor release.

Introducing all of these in a single release seems pretty risky. I think it
> would be safer to spread these out over a few 4.x releases (as they’re
> finished) and give them time to stabilize before including them in an LTS
> release. The downside would be having to maintain backwards compatibility
> across the 4.x versions, but that seems preferable to delaying the release
> of 4.0 to include these, and having another big bang release.


I don't think anyone expects 4.0.0 to be stable. It's a major version
change with lots of new features; in the production world people don't
normally move to a new major version until it has been out for quite some
time and several minor releases have passed. Really, most people are only
migrating to 3.0.x now. While stability is important if we push back large
"core" changes until later we're just setting ourselves up to face the same
issues later on. There should be enough uptake on the early releases of 4.0
from new users to help test and get it to a production-ready state.


Kurt Greaves
k...@instaclustr.com
www.instaclustr.com

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[Blake Eggleston]

> While stability is important if we push back large "core" changes until later 
> we're just setting ourselves up to face the same issues later on

In theory, yes. In practice, when incomplete features are earmarked for a 
certain release, those features are often rushed out, and not always fully 
baked.

In any case, I don’t think it makes sense to spend too much time planning what 
goes into 4.0, and what goes into the next major release with so many release 
strategy related decisions still up in the air. Are we going to ditch 
tick-tock? If so, what will it’s replacement look like? Specifically, when will 
the next “production” release happen? Without knowing that, it's hard to say if 
something should go in 4.0, or 4.5, or 5.0, or whatever.

The reason I suggested a production release every 6 months is because (in my 
mind) it’s frequent enough that people won’t be tempted to rush features to hit 
a given release, but not so frequent that it’s not practical to support. It 
wouldn’t be the end of the world if some of these tickets didn’t make it into 
4.0, because 4.5 would fine.

On November 18, 2016 at 1:57:21 PM, kurt Greaves (k...@instaclustr.com) wrote:

On 18 November 2016 at 18:25, Jason Brown  wrote:  

> #11559 (enhanced node representation) - decided it's *not* something we  
> need wrt #7544 storage port configurable per node, so we are punting on  
>  

#12344 - Forward writes to replacement node with same address during replace  
  
depends on #11559. To be honest I'd say #12344 is pretty important,  
otherwise it makes it difficult to replace nodes without potentially  
requiring client code/configuration changes. It would be nice to get #12344  
in for 4.0. It's marked as an improvement but I'd consider it a bug and  
thus think it could be included in a later minor release.  

Introducing all of these in a single release seems pretty risky. I think it  
> would be safer to spread these out over a few 4.x releases (as they’re  
> finished) and give them time to stabilize before including them in an LTS  
> release. The downside would be having to maintain backwards compatibility  
> across the 4.x versions, but that seems preferable to delaying the release  
> of 4.0 to include these, and having another big bang release.  


I don't think anyone expects 4.0.0 to be stable. It's a major version  
change with lots of new features; in the production world people don't  
normally move to a new major version until it has been out for quite some  
time and several minor releases have passed. Really, most people are only  
migrating to 3.0.x now. While stability is important if we push back large  
"core" changes until later we're just setting ourselves up to face the same  
issues later on. There should be enough uptake on the early releases of 4.0  
from new users to help test and get it to a production-ready state.  


Kurt Greaves  
k...@instaclustr.com  
www.instaclustr.com  

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

[Jeff Jirsa]

We should assume that we’re ditching tick/tock. I’ll post a thread on 
4.0-and-beyond here in a few minutes.

The advantage of a prod release every 6 months is fewer incentive to push 
unfinished work into a release.
The disadvantage of a prod release every 6 months is then we either have a very 
short lifespan per-release, or we have to maintain lots of active releases. 

2.1 has been out for over 2 years, and a lot of people (including us) are 
running it in prod – if we have a release every 6 months, that means we’d be 
supporting 4+ releases at a time, just to keep parity with what we have now? 
Maybe that’s ok, if we’re very selective about ‘support’ for 2+ year old 
branches. 


On 11/18/16, 3:10 PM, "beggles...@apple.com on behalf of Blake Eggleston" 
 wrote:

>> While stability is important if we push back large "core" changes until 
>> later we're just setting ourselves up to face the same issues later on
>
>In theory, yes. In practice, when incomplete features are earmarked for a 
>certain release, those features are often rushed out, and not always fully 
>baked.
>
>In any case, I don’t think it makes sense to spend too much time planning what 
>goes into 4.0, and what goes into the next major release with so many release 
>strategy related decisions still up in the air. Are we going to ditch 
>tick-tock? If so, what will it’s replacement look like? Specifically, when 
>will the next “production” release happen? Without knowing that, it's hard to 
>say if something should go in 4.0, or 4.5, or 5.0, or whatever.
>
>The reason I suggested a production release every 6 months is because (in my 
>mind) it’s frequent enough that people won’t be tempted to rush features to 
>hit a given release, but not so frequent that it’s not practical to support. 
>It wouldn’t be the end of the world if some of these tickets didn’t make it 
>into 4.0, because 4.5 would fine.
>
>On November 18, 2016 at 1:57:21 PM, kurt Greaves (k...@instaclustr.com) wrote:
>
>On 18 November 2016 at 18:25, Jason Brown  wrote:  
>
>> #11559 (enhanced node representation) - decided it's *not* something we  
>> need wrt #7544 storage port configurable per node, so we are punting on  
>>  
>
>#12344 - Forward writes to replacement node with same address during replace  
>depends on #11559. To be honest I'd say #12344 is pretty important,  
>otherwise it makes it difficult to replace nodes without potentially  
>requiring client code/configuration changes. It would be nice to get #12344  
>in for 4.0. It's marked as an improvement but I'd consider it a bug and  
>thus think it could be included in a later minor release.  
>
>Introducing all of these in a single release seems pretty risky. I think it  
>> would be safer to spread these out over a few 4.x releases (as they’re  
>> finished) and give them time to stabilize before including them in an LTS  
>> release. The downside would be having to maintain backwards compatibility  
>> across the 4.x versions, but that seems preferable to delaying the release  
>> of 4.0 to include these, and having another big bang release.  
>
>
>I don't think anyone expects 4.0.0 to be stable. It's a major version  
>change with lots of new features; in the production world people don't  
>normally move to a new major version until it has been out for quite some  
>time and several minor releases have passed. Really, most people are only  
>migrating to 3.0.x now. While stability is important if we push back large  
>"core" changes until later we're just setting ourselves up to face the same  
>issues later on. There should be enough uptake on the early releases of 4.0  
>from new users to help test and get it to a production-ready state.  
>
>
>Kurt Greaves  
>k...@instaclustr.com  



smime.p7s
Description: S/MIME cryptographic signature

Proposals for releases - 4.0 and beyond

[Jeff Jirsa]

With 3.10 voting in progress (take 3), 3.11 in December/January (probably?), we 
should solidify the plan for 4.0.

I went through the archives and found a number of proposals. We (PMC) also had 
a very brief chat in private to make sure we hadn’t missed any, and here are 
the proposals that we’ve seen suggested. 

Option #1: Jon proposed [1] a feature release every 3 months and bugfixes for 6 
months after that.
Option #2: Mick proposed [2] bimonthly feature, semver, labelling release with 
stability/quality during voting, 3 GA branches at a time. 
Option #3: Sylvain proposed [3] feature / testing / stable branches, Y cadence 
for releases, X month rotation from feature -> testing -> stable -> EOL (X to 
be determined). This is similar to an Ubuntu/Debian like release schedule – I 
asked Sylvain for an example just to make sure I understood it, and I’ve copied 
that to github at [4].
Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12 months 
break off X.0.Y which becomes LTS (same as 3.0.x now). This explicitly excludes 
alternating tick/tock feature/bugfix for the monthly cadence on the 
newest/feature/4.x branch. 
Option #5: Jason proposed a revision to Jeremiah’s proposal such that releases 
to the LTS branches are NOT tied to a monthly cadence, but are released “as 
needed”, and the LTS branches are also “as needed”, not tied to a fixed 
(annual/semi-annual/etc) schedule. 

Please use this thread as an opportunity to discuss these proposals or feel 
free to make your own proposals. I think it makes sense to treat this like a 
nomination phase of an election – let’s allow at least 72 hours for submitting 
and discussing proposals, and then we’ll open a vote after that.

- Jeff

[1]: 
https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E
[2]: 
https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E
[3]: 
https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538eef34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E
[4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf
[5]: 
https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b203b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E






smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

[Brandon Williams]

+1

On Fri, Nov 18, 2016 at 12:08 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 3.10.
>
> sha1: 96d67b109a2ef858c2753bbb9853d01460cb8f8e
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1135/org/apache/cassandra/apache-cassandra/3.10/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1135/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/vah74X
> [2]: (NEWS.txt) https://goo.gl/In3vp7
>
>

Re: Proposals for releases - 4.0 and beyond

[Jeremiah D Jordan]

I think the monthly releases are important, otherwise releases become an 
“event”.  The monthly releases mean they are just a normal thing that happens.  
So I like any of 3/4/5.

Sylvain's proposal sounds interesting to me.  My only concern would be with 
making sure we label things very clearly so that users understand which branch 
is the current “stable” branch.  The switch from “testing” to “stable” seems 
like a place that could cause confusion, but as long as we label everything 
well I think we can handle it.

That being said, I think it would be a good addition to the current model 
making the “wait for .6 for stable” more explicit in the release plan, since 
this is what many users already do on their own.

So I think I like Option 3 most of them.  It keeps a monthly cadence, it makes 
explicit which branch we think is stable, and it keeps the number of active 
branches manageable.

-Jeremiah


> On Nov 18, 2016, at 5:49 PM, Jeff Jirsa  wrote:
> 
> With 3.10 voting in progress (take 3), 3.11 in December/January (probably?), 
> we should solidify the plan for 4.0.
> 
> I went through the archives and found a number of proposals. We (PMC) also 
> had a very brief chat in private to make sure we hadn’t missed any, and here 
> are the proposals that we’ve seen suggested. 
> 
> Option #1: Jon proposed [1] a feature release every 3 months and bugfixes for 
> 6 months after that.
> Option #2: Mick proposed [2] bimonthly feature, semver, labelling release 
> with stability/quality during voting, 3 GA branches at a time. 
> Option #3: Sylvain proposed [3] feature / testing / stable branches, Y 
> cadence for releases, X month rotation from feature -> testing -> stable -> 
> EOL (X to be determined). This is similar to an Ubuntu/Debian like release 
> schedule – I asked Sylvain for an example just to make sure I understood it, 
> and I’ve copied that to github at [4].
> Option #4: Jeremiah proposed [5] keeping monthly cadence, and every 12 months 
> break off X.0.Y which becomes LTS (same as 3.0.x now). This explicitly 
> excludes alternating tick/tock feature/bugfix for the monthly cadence on the 
> newest/feature/4.x branch. 
> Option #5: Jason proposed a revision to Jeremiah’s proposal such that 
> releases to the LTS branches are NOT tied to a monthly cadence, but are 
> released “as needed”, and the LTS branches are also “as needed”, not tied to 
> a fixed (annual/semi-annual/etc) schedule. 
> 
> Please use this thread as an opportunity to discuss these proposals or feel 
> free to make your own proposals. I think it makes sense to treat this like a 
> nomination phase of an election – let’s allow at least 72 hours for 
> submitting and discussing proposals, and then we’ll open a vote after that.
>   
> - Jeff
> 
> [1]: 
> https://lists.apache.org/thread.html/0b2ca82eb8c1235a4e44a406080729be78fb539e1c0cbca638cfff52@%3Cdev.cassandra.apache.org%3E
> [2]: 
> https://lists.apache.org/thread.html/674ef1c02997041af4b8950023b07b2f48bce3b197010ef7d7088662@%3Cdev.cassandra.apache.org%3E
> [3]: 
> https://lists.apache.org/thread.html/fcc4180b7872be4db86eae12b538eef34c77dcdb5b13987235c8f2bd@%3Cdev.cassandra.apache.org%3E
> [4]: https://gist.github.com/jeffjirsa/9bee187246ca045689c52ce9caed47bf
> [5]: 
> https://lists.apache.org/thread.html/0a3372b2f2b30fbeac04f7d5a214b203b18f3d69223e7ec9efb64776@%3Cdev.cassandra.apache.org%3E
> 
> 
> 
> 

Re: Proposals for releases - 4.0 and beyond

[kurt Greaves]

Option 3 seems the most reasonable and the clearest from a user
perspective. The main thing I'd be concerned about with a 6 month cycle
would be how short a branch is supported for. Most users will be bound to a
specific release for at least 2 years, and we still find bugs in 2.1 2
years since release. The only adjustment I would make would be to support
branches for 1.5 - 2 years before EOL.