Re: Repair when a replica is Down

2016-01-16 Thread Anuj Wadehra 
Hi
I have intentionally posted this message to the dev mailing list instead of 
users list because its regarding a conscious design decision taken regarding a 
bug and I feel that dev team is the most appropriate team who could respond to 
it. Please let me know if there are better ways to get it addressed.
ThanksAnuj
Sent from Yahoo Mail on Android 
 
  On Fri, 15 Jan, 2016 at 11:36 pm, Anuj Wadehra wrote: 
  Hi 
We are on 2.0.14,RF=3 in a 3 node cluster. We use repair -pr . Recently, we 
observed that repair -pr for all nodes fails if a node is down. Then I found 
the JIRA 
https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-2290
where an intentional decision was taken to abort the repair if a replica is 
down.
I need to understand the reasoning behind aborting the repair instead of 
proceeding with available replicas.
I have following concerns with the approach:
We say that we have a fault tolerant Cassandra system such that we can afford 
single node failure because RF=3 and we read/write at QUORUM.But when a node 
goes down and we are not sure how much time will be needed to restore the node, 
entire system health is in question as gc_grace_period is approaching and we 
are not able to run repair -pr on any of the nodes.
Then there is a dilemma:Whether to remove the faulty node well before gc grace 
period so that we get enough time to save data by repairing other two nodes?
This may cause massive streaming which may be unnecessary if we are able to 
bring back the faulty node before gc grace period.
OR
Wait and hope that the issue will be resolved before gc grace time and we will 
have some buffer to run repair -pr on all nodes.
OR
Increase the gc grace period temporarily. Then we should have capacity planning 
to accomodate the extra storage needed for extra gc grace that may be needed in 
case of node failure scenarios.

I need to understand the recommeded approach too for maintaing a fault tolerant 
system which can handle such node failures without hiccups.

ThanksAnuj

Re: Versioning policy?

2016-01-16 Thread Anuj Wadehra 
Hi Jonathan

It would be really nice if you could share your thoughts on the four points 
raised regarding the Cassandra EOL process. I think similar things happen for 
other open source products and it would be really nice if we could streamline 
such things for Apache Cassandra.

ThanksAnuj

Sent from Yahoo Mail on Android 
 
  On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra wrote: 
  Hi Jonathan,
Thanks for the crisp communication regarding the tick tock release & EOL.
I think its worth considering some points regarding EOL policy and it would be 
great if you can share your thoughts on below points:
1.  EOL of a release should be based on "most stable"/"production ready" 
version date rather than "GA" date of subsequent major releases.
2.  I think we should have "Formal EOL Announcement" on Apache Cassandra 
website.  
3. "Formal EOL Announcement" should come at least 6 months before the EOL, so 
that users get reasonable time to  upgrade.
4. EOL Policy (even if flexible) should be stated on Apache Cassandra website

EOL thread on users mailing list ended with the conclusion of raising a 
Wishlist JIRA but I think above points are more about working on policy and 
processes rather than just a wish list. 

ThanksAnuj



Sent from Yahoo Mail on Android 
 
  On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote:  
Hi Maciek,

First let's talk about the tick-tock series, currently 3.x.  This is pretty
simple: outside of the regular monthly releases, we will release fixes for
critical bugs against the most recent bugfix release, the way we did
recently with 3.1.1 for CASSANDRA-10822 [1].  No older tick-tock releases
will be patched.

Now, we also have three other release series currently being supported:

2.1.x: supported with critical fixes only until 4.0 is released, projected
in November 2016 [2]
2.2.x: maintained until 4.0 is released
3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017

I will add this information to the releases page [3].

[1]
https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E
[2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
sunsetting deprecated features like Thrift so bumping the major version
seems appropriate
[3] http://cassandra.apache.org/download/

On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda  wrote:

> There was a discussion recently about changing the Cassandra EOL policy on
> the users list [1], but it didn't really go anywhere. I wanted to ask here
> instead to clear up the status quo first. What's the current versioning
> policy? The tick-tock versioning blog post [2] states in passing that two
> major releases are maintained, but I have not found this as an official
> policy stated anywhere. For comparison, the Postgres project lays this out
> very clearly [3]. To be clear, I'm not looking for any official support,
> I'm just asking for clarification regarding the maintenance policy: if a
> critical bug or security vulnerability is found in version X.Y.Z, when can
> I expect it to be fixed in a bugfix patch to that major version, and when
> do I need to upgrade to the next major version.
>
> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
> [3]: http://www.postgresql.org/support/versioning/
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
 

Re: Versioning policy?

2016-01-16 Thread Michael Kjellman 
Correct, this is an open source project. 

If you want a Enterprise support story Datastax has an Enterprise option for 
you. 

> On Jan 16, 2016, at 11:19 AM, Anuj Wadehra  wrote:
> 
> Hi Jonathan
> 
> It would be really nice if you could share your thoughts on the four points 
> raised regarding the Cassandra EOL process. I think similar things happen for 
> other open source products and it would be really nice if we could streamline 
> such things for Apache Cassandra.
> 
> ThanksAnuj
> 
> Sent from Yahoo Mail on Android 
> 
>  On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra 
> wrote:   Hi Jonathan,
> Thanks for the crisp communication regarding the tick tock release & EOL.
> I think its worth considering some points regarding EOL policy and it would 
> be great if you can share your thoughts on below points:
> 1.  EOL of a release should be based on "most stable"/"production ready" 
> version date rather than "GA" date of subsequent major releases.
> 2.  I think we should have "Formal EOL Announcement" on Apache Cassandra 
> website.  
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so 
> that users get reasonable time to  upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
> 
> EOL thread on users mailing list ended with the conclusion of raising a 
> Wishlist JIRA but I think above points are more about working on policy and 
> processes rather than just a wish list. 
> 
> ThanksAnuj
> 
> 
> 
> Sent from Yahoo Mail on Android 
> 
>   On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote:  
> Hi Maciek,
> 
> First let's talk about the tick-tock series, currently 3.x.  This is pretty
> simple: outside of the regular monthly releases, we will release fixes for
> critical bugs against the most recent bugfix release, the way we did
> recently with 3.1.1 for CASSANDRA-10822 [1].  No older tick-tock releases
> will be patched.
> 
> Now, we also have three other release series currently being supported:
> 
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
> 
> I will add this information to the releases page [3].
> 
> [1]
> https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3] http://cassandra.apache.org/download/
> 
>> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda  wrote:
>> 
>> There was a discussion recently about changing the Cassandra EOL policy on
>> the users list [1], but it didn't really go anywhere. I wanted to ask here
>> instead to clear up the status quo first. What's the current versioning
>> policy? The tick-tock versioning blog post [2] states in passing that two
>> major releases are maintained, but I have not found this as an official
>> policy stated anywhere. For comparison, the Postgres project lays this out
>> very clearly [3]. To be clear, I'm not looking for any official support,
>> I'm just asking for clarification regarding the maintenance policy: if a
>> critical bug or security vulnerability is found in version X.Y.Z, when can
>> I expect it to be fixed in a bugfix patch to that major version, and when
>> do I need to upgrade to the next major version.
>> 
>> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
>> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
>> [3]: http://www.postgresql.org/support/versioning/
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: Versioning policy?

2016-01-16 Thread Anuj Wadehra 
I was not referring to Enterprise support here. When I said Open source 
"product" by mistake, I was just referring to some other Apache open source 
projects like Apache Cassandra where you get EOL announcements, info etc on the 
main Apache web site. I think all four points are very relevant in context of 
an Open source project and thats why I wanted to thoughts on these points.



ThanksAnuj

Sent from Yahoo Mail on Android 
 
  On Sun, 17 Jan, 2016 at 1:43 am, Michael 
Kjellman wrote:   Correct, this is an open source 
project. 

If you want a Enterprise support story Datastax has an Enterprise option for 
you. 

> On Jan 16, 2016, at 11:19 AM, Anuj Wadehra  wrote:
> 
> Hi Jonathan
> 
> It would be really nice if you could share your thoughts on the four points 
> raised regarding the Cassandra EOL process. I think similar things happen for 
> other open source products and it would be really nice if we could streamline 
> such things for Apache Cassandra.
> 
> ThanksAnuj
> 
> Sent from Yahoo Mail on Android 
> 
>  On Thu, 14 Jan, 2016 at 11:28 pm, Anuj Wadehra 
>wrote:  Hi Jonathan,
> Thanks for the crisp communication regarding the tick tock release & EOL.
> I think its worth considering some points regarding EOL policy and it would 
> be great if you can share your thoughts on below points:
> 1.  EOL of a release should be based on "most stable"/"production ready" 
> version date rather than "GA" date of subsequent major releases.
> 2.  I think we should have "Formal EOL Announcement" on Apache Cassandra 
> website.  
> 3. "Formal EOL Announcement" should come at least 6 months before the EOL, so 
> that users get reasonable time to      upgrade.
> 4. EOL Policy (even if flexible) should be stated on Apache Cassandra website
> 
> EOL thread on users mailing list ended with the conclusion of raising a 
> Wishlist JIRA but I think above points are more about working on policy and 
> processes rather than just a wish list. 
> 
> ThanksAnuj
> 
> 
> 
> Sent from Yahoo Mail on Android 
> 
>  On Thu, 14 Jan, 2016 at 10:57 pm, Jonathan Ellis wrote:  
>Hi Maciek,
> 
> First let's talk about the tick-tock series, currently 3.x.  This is pretty
> simple: outside of the regular monthly releases, we will release fixes for
> critical bugs against the most recent bugfix release, the way we did
> recently with 3.1.1 for CASSANDRA-10822 [1].  No older tick-tock releases
> will be patched.
> 
> Now, we also have three other release series currently being supported:
> 
> 2.1.x: supported with critical fixes only until 4.0 is released, projected
> in November 2016 [2]
> 2.2.x: maintained until 4.0 is released
> 3.0.x: maintained for 6 months after 4.0, i.e. projected until May 2017
> 
> I will add this information to the releases page [3].
> 
> [1]
> https://mail-archives.apache.org/mod_mbox/incubator-cassandra-user/201512.mbox/%3CCAKkz8Q3StqRFHfMgCMRYaaPdg+HE5N5muBtFVt-=v690pzp...@mail.gmail.com%3E
> [2] 4.0 will be an ordinary tick-tock release after 3.11, but we will be
> sunsetting deprecated features like Thrift so bumping the major version
> seems appropriate
> [3] http://cassandra.apache.org/download/
> 
>> On Sun, Jan 10, 2016 at 9:29 PM, Maciek Sakrejda  wrote:
>> 
>> There was a discussion recently about changing the Cassandra EOL policy on
>> the users list [1], but it didn't really go anywhere. I wanted to ask here
>> instead to clear up the status quo first. What's the current versioning
>> policy? The tick-tock versioning blog post [2] states in passing that two
>> major releases are maintained, but I have not found this as an official
>> policy stated anywhere. For comparison, the Postgres project lays this out
>> very clearly [3]. To be clear, I'm not looking for any official support,
>> I'm just asking for clarification regarding the maintenance policy: if a
>> critical bug or security vulnerability is found in version X.Y.Z, when can
>> I expect it to be fixed in a bugfix patch to that major version, and when
>> do I need to upgrade to the next major version.
>> 
>> [1]: http://www.mail-archive.com/user@cassandra.apache.org/msg45324.html
>> [2]: http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
>> [3]: http://www.postgresql.org/support/versioning/
> 
> 
> 
> -- 
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>