Re: Review ApacheCon Cassandra track submissions

2019-05-21 Thread Nate McCall
Apologies if I wasn’t clear. The intention was pmc and committers. I would
be inclined to open it further but we are tied into the ASFs review system
for which you need an ASF account. (If someone had commit access on another
project and wanted to participate , I’d be cool with that).

On Tuesday, May 21, 2019, Joshua McKenzie  wrote:

> Re-reading that, I realize I probably need to clarify:
>
> 1) Entire PMC *+ anyone else who wants to volunteer* vote on talks. Not
> just PMC.
>
> On Tue, May 21, 2019 at 8:48 AM Joshua McKenzie 
> wrote:
>
> > 1) How about we have entire PMC vote on talks?
> > 2) We need to do t-shirts. :) Do we need corporate sponsorship for that
> > (i.e. $$)? I can look into that if so.
> >
> > On Tue, May 21, 2019 at 12:28 AM Nate McCall  wrote:
> >
> >> Hi Folks,
> >> As you probably know, the ApacheCon NA CFP recently closed. We received
> *a
> >> lot* of submissions for the Cassandra track (thanks everyone!!!). 3x
> more
> >> than any other project specific track and *almost* as much as the
> >> catch-all
> >> big data track.
> >>
> >> Not only that, but there are a lot of good ones in there. To accommodate
> >> this, we added another user-focused day (bringing us to 1 day of NGCC
> and
> >> 2
> >> days of talks) as well as another room. We'll be able to take 19 user
> >> talks
> >> and 9 NGCC talks.
> >>
> >> If you are a committer (or by extension a PMC member) and you want to
> help
> >> grade talks, please let me know by replying to this email and we'll get
> >> you
> >> setup. More instructions will follow once we get a head count. As we
> need
> >> to get started, I'll cap the number of people to whoever has replied
> >> within
> >> 72 hours of sending this email.
> >>
> >> Thanks again to everyone that submitted abstracts! I can't tell you how
> >> happy we were to see the response once we got access to the submissions.
> >>
> >> Cheers,
> >> -Nate
> >>
> >
>


Review ApacheCon Cassandra track submissions

2019-05-20 Thread Nate McCall
Hi Folks,
As you probably know, the ApacheCon NA CFP recently closed. We received *a
lot* of submissions for the Cassandra track (thanks everyone!!!). 3x more
than any other project specific track and *almost* as much as the catch-all
big data track.

Not only that, but there are a lot of good ones in there. To accommodate
this, we added another user-focused day (bringing us to 1 day of NGCC and 2
days of talks) as well as another room. We'll be able to take 19 user talks
and 9 NGCC talks.

If you are a committer (or by extension a PMC member) and you want to help
grade talks, please let me know by replying to this email and we'll get you
setup. More instructions will follow once we get a head count. As we need
to get started, I'll cap the number of people to whoever has replied within
72 hours of sending this email.

Thanks again to everyone that submitted abstracts! I can't tell you how
happy we were to see the response once we got access to the submissions.

Cheers,
-Nate


Re: Two day Apache Cassandra track at ApacheConNA 2019

2019-05-07 Thread Nate McCall
*Bump*
Just a reminder we are still accepting submissions for NGCC and our user
track at ApacheCon:
https://www.apachecon.com/acna19/cfp.html

Thanks to the folks who have submitted so far!!

Cheers,
-Nate

On Wed, Mar 13, 2019 at 1:22 PM Nate McCall  wrote:

> Hi Folks,
>
> I am delighted to share with you that we, the Apache Cassandra
> community, have been given a two day track at this year's ApacheCon
> North America.
>
> The goal of this track is simple: we are going to get together to talk
> about Apache Cassandra. As such, this will be the ideal place to
> network with peers, ask questions, get answers, etc.
>
> On day one, we will be having our Next Generation Cassandra Conference
> (NGCC). All are welcome to attend but this day is targeted for Apache
> Cassandra committers, contributors and large-scale cluster operators
> to get together and discuss topics of interest to them for future
> development efforts. The content will focus on internals and will be
> geared towards folks with knowledge of the codebase and/or operating
> Cassandra in very large environments. Talk submissions for NGCC should
> take this target audience into account.
>
> Day two will be more general purpose and accessible for a wider
> audience. If you are interested in speaking here, put something
> together that tells a story others will want to hear. What we are
> looking for is general use case submissions that our users will find
> interesting. This can be how you solved a specific problem or just a
> general picture into how your organization uses Apache Cassandra. A
> good submission will embrace the open source ethos of sharing
> information to help others solve similar problems.
>
> NGCC talks will be targeted to 30 minutes with 15 minutes for
> questions or small break out discussions. General purpose talks will
> have 40 minutes with five minutes for questions.
>
> For more information, including details of how to submit proposals,
> please see this page:
> http://cassandra.apache.org/events/2019-apache-cassandra-summit/
>


GSoD update: new mail list for inbounds

2019-05-05 Thread Nate McCall
Hi Folks,
For those that have offered to help GSoD efforts, please subscribe to the
following list publicly accessible, but moderated list:
gsod2...@cassandra.apache.org

Ie. as with any ASF list, send an email to
gsod2019-subscr...@cassandra.apache.org  with
SUBSCRIBE as the subject, reply to the follow-up and you should be all set.

This list will be primarily used to field initial inbound Q with
potential doc writers. I would like to push technical questions to the dev
list for wider exposure.

Thanks,
-Nate


Re: GSoD Exploration Information

2019-05-01 Thread Nate McCall
Hi Himanshu,
Thanks for reaching out regarding the GSoD project. However, GSoD itself
has the requirement of previous technical writing experience. I'm not sure
you are able to participate through the program without such?

That being said, as an open source project, we are certainly willing to
take contributions anytime.

Thanks again for your interest.

Cheers,
-Nate

On Thu, May 2, 2019 at 10:32 AM Himanshu Nailwal 
wrote:

>
> Hi,
>
> I hope all is well with you.
>
> Firstly, congratulations for being a selected  organization at GSoD 2019.
>
> I was going through the” Apache Cassandra GSoD 2019 application<
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+GSoD+2019+application>”.
> In this it is mentioned that the applicant should have a prior experience
> of technical writing.
>
> I am a graduate student at Jaypee Institute of Information Technology,
> Noida, India. My graduation is in Big Data Systems. I have hands on
> experience on Apache Cassandra from quite a long time.
>
> I am interested in your organization for GSoD 2019.
>
> Please let me know that this constraint is necessary or not?
>
> Regards,
> Himanshu Nailwal
>
>


Apache Cassandra Accepted to GSoD

2019-04-30 Thread Nate McCall
Hi Folks,
Quick update to say that we got accepted to Google's Season of Docs project:
https://developers.google.com/season-of-docs/docs/participants/

Outline of potential projects is here for reference:
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+GSoD+2019+application

Huge thanks to the volunteers (listed on the above confluence page)
who signed up for mentorship and took time to fill out the
applications.

Note that the dev@ email is on there as the contact point (it needed
to be a published, shared project address). Dinesh or myself we take
the initial inbounds as we are listed as mentors on the application,
but everyone please feel free to jump in to answer any questions that
come up during this process.

We'll write again once we know more about who we are working with.

Cheers,
-Nate

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: TLP tools for stress testing and building test clusters in AWS

2019-04-16 Thread Nate McCall
Just noticed the date - to be clear, this is like in ~45 mins?

On Wed, Apr 17, 2019 at 12:11 PM Nate McCall  wrote:
>
> > I have set up a zoom link for the TLP tool set intro that will be on in an
> > hours time (17 April 2019 @ 11:00AM AEST): https://zoom.us/j/272648772
> >
> Super rad - thanks for setting this up, Anthony!

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: TLP tools for stress testing and building test clusters in AWS

2019-04-16 Thread Nate McCall
> I have set up a zoom link for the TLP tool set intro that will be on in an
> hours time (17 April 2019 @ 11:00AM AEST): https://zoom.us/j/272648772
>
Super rad - thanks for setting this up, Anthony!

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Stabilising Internode Messaging in 4.0

2019-04-14 Thread Nate McCall
Josh - You are 100% correct on that - I appreciate you calling it out.
In re-reading this, I think that came out sideways and significantly
harsher from what I intended. My apologies to Benedict and Aleksey.

My (poorly made) point was that collaboration is the lifeblood of any
open source project. It will require extra work but sometimes large
complex efforts require a level of pragmatism that can be at odds with
this goal.


On Sun, Apr 14, 2019 at 12:28 AM Joshua McKenzie  wrote:
>
> >
> > a couple of people (even if I know them personally,
> > consider them friends and are both among the best engineers i've ever
> > met) going off in a room and producing something in isolation is more
> > or less a giant "f*k you" to the open source process and our community
> > as a whole.
>
> Two engineers who are co-located who spend a couple months collaborating on
> something before opening it up for broad consensus debate is hardly as
> extreme as I think you're characterizing it. If we want to have a formal
> process on this project where people preemptively get consensus on any work
> greater than some arbitrary LoC or complexity metric, that's fine, but
> let's not retcon this and try and impose restrictions or interpretations on
> peoples' behavior after the fact.
>
> Everyone acted in good faith here. Collaborating internationally with
> dozens of engineers is Hard; let's assume the best of each other.
>
>
>
>
>
> On Fri, Apr 12, 2019 at 5:45 PM Nate McCall  wrote:
>
> > As someone who has been here a (very) long time and worked on C* in
> > production envs. back to version 0.4, this large patch - taken by
> > itself - does, to be frank, scare the shit out of me. In a complex
> > system any large change will have side effects impossible to
> > anticipate. I have seen this hold true too many times.
> >
> > That said, I think we all agree that internode has been a source of
> > warts since Facebook spun this out 10+ yrs ago and that we are all
> > tired of applying bandaides.
> >
> > As has been talked to else thread - and this is the super crucial
> > point for me -  we also have a substantially better testing story
> > internally and externally coming together than at any point in the
> > projects past.
> >
> > This next part is partially selfish, but I want to be 100% clear is in
> > the immediate interests of the project's future:
> > I am getting on stage in about a month to keynote the first Cassandra
> > focused event with any notable attendance we have had for a long time.
> > We are then all going out to vegas in Sept. to discuss the future of
> > our project and ideally have some cool use cases to show a bunch of
> > users.
> >
> > For both of these, we need a story to tell. It needs to be clear and
> > cohesive. And I think it's super important to get in front of these
> > people and have part of this story be "we took three years because we
> > didnt compromise on quality." If we dont have our shit together here I
> > think we will start loosing users at a much faster pace and we
> > seriously risk becoming "that thing you can run only if you are a
> > large company and can put a bunch of people on it who know it
> > intimately." Whether that is the case or not, *it will* be the
> > perception. We are just running out of time.
> >
> > So back to this patch: on the surface, it fixes a lot of stuff and
> > puts us on the right track for the future. I'm willing to set aside
> > the number of times I've been burned over the past decade because I
> > think we are in a much better position - as a whole community - to
> > find, report and fix issues this patch will introduce and do so much
> > faster than we ever have.
> >
> > I do want to end this with one more point because it needs to be
> > called out: a couple of people (even if I know them personally,
> > consider them friends and are both among the best engineers i've ever
> > met) going off in a room and producing something in isolation is more
> > or less a giant "f*k you" to the open source process and our community
> > as a whole. Internode is a particularly complex, messy, baggage ridden
> > component where there is an argument to be made that uninterrupted
> > concentration was the only way to achieve this, but it must be
> > understood that the perception of actions like this is toe stepping,
> > devaluation of opinions and is generally not conducive to holding a
> > community together. Again, i doubt this was the intention, but it is
> > the perception. Please let's avoid this in the future.
> &g

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Nate McCall
As someone who has been here a (very) long time and worked on C* in
production envs. back to version 0.4, this large patch - taken by
itself - does, to be frank, scare the shit out of me. In a complex
system any large change will have side effects impossible to
anticipate. I have seen this hold true too many times.

That said, I think we all agree that internode has been a source of
warts since Facebook spun this out 10+ yrs ago and that we are all
tired of applying bandaides.

As has been talked to else thread - and this is the super crucial
point for me -  we also have a substantially better testing story
internally and externally coming together than at any point in the
projects past.

This next part is partially selfish, but I want to be 100% clear is in
the immediate interests of the project's future:
I am getting on stage in about a month to keynote the first Cassandra
focused event with any notable attendance we have had for a long time.
We are then all going out to vegas in Sept. to discuss the future of
our project and ideally have some cool use cases to show a bunch of
users.

For both of these, we need a story to tell. It needs to be clear and
cohesive. And I think it's super important to get in front of these
people and have part of this story be "we took three years because we
didnt compromise on quality." If we dont have our shit together here I
think we will start loosing users at a much faster pace and we
seriously risk becoming "that thing you can run only if you are a
large company and can put a bunch of people on it who know it
intimately." Whether that is the case or not, *it will* be the
perception. We are just running out of time.

So back to this patch: on the surface, it fixes a lot of stuff and
puts us on the right track for the future. I'm willing to set aside
the number of times I've been burned over the past decade because I
think we are in a much better position - as a whole community - to
find, report and fix issues this patch will introduce and do so much
faster than we ever have.

I do want to end this with one more point because it needs to be
called out: a couple of people (even if I know them personally,
consider them friends and are both among the best engineers i've ever
met) going off in a room and producing something in isolation is more
or less a giant "f*k you" to the open source process and our community
as a whole. Internode is a particularly complex, messy, baggage ridden
component where there is an argument to be made that uninterrupted
concentration was the only way to achieve this, but it must be
understood that the perception of actions like this is toe stepping,
devaluation of opinions and is generally not conducive to holding a
community together. Again, i doubt this was the intention, but it is
the perception. Please let's avoid this in the future.

In sum, +1. I wish this process were smoother but we're running out of time.

-Nate

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: need information

2019-03-31 Thread Nate McCall
Hi Amit,
The ASF product name usage guidelines would be a good place to start:
http://www.apache.org/foundation/marks/guide

Give that a read and let us know if you have any questions.

Thanks reaching out about this either way.

Cheers,
-Nate

On Sat, Mar 30, 2019 at 10:54 AM Dinesh Joshi
 wrote:
>
> Hi Amit,
>
> Moving dev@ to bcc. I am adding Mark Thomas, ASF VP Brand Management. I am 
> not too clear on the legal aspect pertaining to the trademark policies. The 
> trademark policies are here: https://apache.org/foundation/marks/
>
> I can help answer the technical aspects of your questions. Please see my 
> responses below –
>
> > On Mar 29, 2019, at 12:11 PM, Amit Sengar  wrote:
> >
> > Hey thanks for reply
> >
> > Actually I've created a basic version for cassandra GUI in electron js and 
> > i just want to share this with the other developers at electron/apps 
> > website so my concern is regarding the permissions like
> > 1) can i use cassandra logo image?
> > 2) can i use cassandra GUI name as title of project?
> > 3) can i publish this as open source?
>
> Depends on you and your organization's legal policies. It's a complex topic 
> and many organizations have some sort of legal review and approval process to 
> open source your code.
>
> > 4) can i publish this at any web site?
>
> Again this depends. However, typically developers prefer to host the source 
> code at github.
>
> Thanks,
>
> Dinesh
>
>
> > Please consider the above questions and let me know the answers
> >
> >
> > Thanks a lot
> > Regards
> > Amit Sengar
> >
> >
> > Sent from my iPhone
> >
> >> On 29-Mar-2019, at 21:43, Dinesh Joshi  wrote:
> >>
> >> Hi Amit,
> >>
> >> Please feel free to share with the dev@ list or user@
> >>
> >> Dinesh
> >>
> >>> On Mar 29, 2019, at 7:51 AM, Craig Russell  wrote:
> >>>
> >>> Hi Amit,
> >>>
> >>> We have a community of developers of Cassandra (copied here) whom you can 
> >>> contact and discuss your ideas.
> >>>
> >>> Regards,
> >>>
> >>> Craig
> >>>
>  On Mar 29, 2019, at 1:43 AM, Amit Sengar  wrote:
> 
>  Hey
>  Hope you are doing well. Actually i'm using Cassandra Db but i am not 
>  able to find any free GUI for database so i have created my own i.e 
>  based on electron js. So please let me know how can i publish that for 
>  other developers for free. So if you will grant me permission than i can 
>  publish that online and please let me know the terms and policies which 
>  are preventing me for doing that.
> 
>  hope to hear from you soon.
> 
> 
> 
>  Regards
>  Amit Sengar
>  (+91-9001942319)
> 
> 
>  कृपया धरती को बचायें. अति आवश्यक होने पर ही प्रिंट करें.
>  Please don't print this e-mail unless you really need to. Be Green.
> >>>
> >>> Craig L Russell
> >>> Secretary, Apache Software Foundation
> >>> c...@apache.org  http://db.apache.org/jdo 
> >>> 
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Two day Apache Cassandra track at ApacheConNA 2019

2019-03-12 Thread Nate McCall
Hi Folks,

I am delighted to share with you that we, the Apache Cassandra
community, have been given a two day track at this year's ApacheCon
North America.

The goal of this track is simple: we are going to get together to talk
about Apache Cassandra. As such, this will be the ideal place to
network with peers, ask questions, get answers, etc.

On day one, we will be having our Next Generation Cassandra Conference
(NGCC). All are welcome to attend but this day is targeted for Apache
Cassandra committers, contributors and large-scale cluster operators
to get together and discuss topics of interest to them for future
development efforts. The content will focus on internals and will be
geared towards folks with knowledge of the codebase and/or operating
Cassandra in very large environments. Talk submissions for NGCC should
take this target audience into account.

Day two will be more general purpose and accessible for a wider
audience. If you are interested in speaking here, put something
together that tells a story others will want to hear. What we are
looking for is general use case submissions that our users will find
interesting. This can be how you solved a specific problem or just a
general picture into how your organization uses Apache Cassandra. A
good submission will embrace the open source ethos of sharing
information to help others solve similar problems.

NGCC talks will be targeted to 30 minutes with 15 minutes for
questions or small break out discussions. General purpose talks will
have 40 minutes with five minutes for questions.

For more information, including details of how to submit proposals,
please see this page:
http://cassandra.apache.org/events/2019-apache-cassandra-summit/

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-03 Thread Nate McCall
On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler  wrote:
>
> I propose the following artifacts for release as 3.0.18.
>
> sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.14

2019-02-03 Thread Nate McCall
On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler  wrote:
>
> I propose the following artifacts for release as 2.2.14.
>
> sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.11.4

2019-02-03 Thread Nate McCall
On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler  wrote:
>
> I propose the following artifacts for release as 3.11.4.
>
> sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-03 Thread Nate McCall
+1 on the release of 2.1.21 (let's focus on that in the spirit of
these other votes we have up right now).

I don't feel the need to be absolutist about something being EOL.

On Sun, Feb 3, 2019 at 1:47 AM Stefan Podkowinski  wrote:
>
> What are we voting on here? Releasing the 2.1.21 candidate, or that 2.1
> would become EOL? Please let's have separate votes on that, if you want
> to propose putting 2.1 EOL (which I'm strongly -1).
>
>
> On 03.02.19 01:32, Michael Shuler wrote:
> > *EOL* release for the 2.1 series. There will be no new releases from the
> > 'cassandra-2.1' branch after this release.
> >
> > 
> >
> > I propose the following artifacts for release as 2.1.21.
> >
> > sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> > Git:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: CHANGES.txt:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> > [2]: NEWS.txt:
> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Cassandra website docs for 3.11 added

2019-01-07 Thread Nate McCall
This is fantastic!! Thanks a bunch for the effort on this, folks.

On Mon, Jan 7, 2019 at 4:31 PM Mick Semb Wever  wrote:
>
>
> > Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do
> > this next week if no one objects.
>
>
> This has been done by Joey Lynch, Anthony Grasso and myself .
>  See https://cassandra.apache.org/doc/latest/
>
>
> >  a) list and link to the different versions of the docs
>
> A very basic initial version of this is proposed in CASSANDRA-14954 just by 
> disabling the redirect and enabling directory listing under 
> https://cassandra.apache.org/doc/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Change Jira Workflow

2018-12-17 Thread Nate McCall
On Tue, Dec 18, 2018 at 4:19 AM Benedict Elliott Smith
 wrote:
>
> I propose these changes 
> *
>  to the Jira Workflow for the project.  The vote will be open for 72 hours**.
>


+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: JIRA Workflow Proposals

2018-12-05 Thread Nate McCall
> Summary:
>
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
>

1: A
2: +1
3: +1
4: +1
5: +0
6: +1

(Appreciate the good discussion here as well - thx everyone!)

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: 4.0 Testing Signup

2018-11-08 Thread Nate McCall
Thanks Romain!

Let's keep a top level ticket for the/a component, but add child tasks
as needed. I think child tickets are a little easier to manage than
using a tag or similar.
On Thu, Nov 8, 2018 at 11:04 AM Romain Hardouin
 wrote:
>
>
> Hi,
> I'm volunteer to be contributor on Metrics or Tooling component. Are we 
> supposed/allowed to edit Confluence page directly?Btw I think that tooling 
> should be split, maybe one ticket per tool?
> Thanks,
> RomainLe mercredi 7 novembre 2018 à 22:51:30 UTC+1, sankalp kohli 
>  a écrit :
>
>  This is good start and we should use this approach each component. Once we
> have volunteers for each area, it will be important to also publish a
> confluence page per component by the volunteer so we can know/discuss how
> it was tested.
>
> On Wed, Nov 7, 2018 at 12:14 PM Joseph Lynch  wrote:
>
> > Following up on Jon's call
> > <
> > https://lists.apache.org/thread.html/17e57d1666393d961a15502a648a1174a1b145a4bf0a8e07fd8bb760@%3Cdev.cassandra.apache.org%3E
> > >
> > for QA, I put together the start of a confluence page
> > for
> > people to list out important components that they think should be tested
> > before 4.0 releases and hopefully committers and contributors can signup
> > and present their progress to the community. I've certainly missed a ton of
> > components that need testing but I figured that it may be good to get the
> > conversation started and moving forward.
> >
> > What do people think? Is there a more effective way to list these out or if
> > people like this maybe folks can start contributing sections and
> > volunteering to shepherd or test them?
> >
> > Let me know,
> > -Joey
> >
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Jepsen testing

2018-11-08 Thread Nate McCall
[- cassandra-users]
Hi Yuji,
Thanks so much for working on this! Any fault injection testing is
certainly worth the effort.

Thanks,
-Nate
On Thu, Nov 8, 2018 at 1:36 PM Yuji Ito  wrote:
>
> Hi,
>
> We are working on Jepsen testing for Cassandra.
> https://github.com/scalar-labs/jepsen/tree/cassandra/cassandra
>
> As you may know, Jepsen is a framework for distributed systems verification.
> It can inject network failure and so on and check data consistency.
> https://github.com/jepsen-io/jepsen
>
> Our tests are based on riptano's great work.
> https://github.com/riptano/jepsen/tree/cassandra/cassandra
>
> I refined it for the latest Jepsen and removed some tests.
> Next, I'll fix clock-drift tests.
>
> I would like to get your feedback.
>
> Thanks,
> Yuji Ito

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Testing 4.0 upgrading

2018-10-24 Thread Nate McCall
> Now I will reinstall the old version and do the upgrade again and
> hopefully I can have more information soon.
>

Hi Tommy,
Thanks for taking the time to brave an upgrade test this early on - it
is super helpful to get this feedback.

Anyone else that has bandwidth, we very much appreciate these types of
tests, so please keep them coming.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: TSU NOTIFICATION - Encryption

2018-09-24 Thread Nate McCall
Just some housekeeping paper work for export controls per:
http://www.apache.org/licenses/exports/

See https://issues.apache.org/jira/browse/CASSANDRA-14634 and
https://issues.apache.org/jira/browse/LEGAL-358 if you're curios.
On Tue, Sep 25, 2018 at 5:28 PM Nate McCall  wrote:
>
> SUBMISSION TYPE:  TSU
>
> SUBMITTED BY:     Nate McCall
>
> SUBMITTED FOR:The Apache Software Foundation
>
> POINT OF CONTACT: Secretary, The Apache Software Foundation
>
> FAX:  +1-919-573-9199
>
> MANUFACTURER(S):  The Apache Software Foundation, Oracle, The
> OpenSSL Project
>
> PRODUCT NAME/MODEL #: Apache Cassandra
>
> ECCN: 5D002
>
> NOTIFICATION: http://www.apache.org/licenses/exports/

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



TSU NOTIFICATION - Encryption

2018-09-24 Thread Nate McCall
SUBMISSION TYPE:  TSU

SUBMITTED BY: Nate McCall

SUBMITTED FOR:The Apache Software Foundation

POINT OF CONTACT: Secretary, The Apache Software Foundation

FAX:  +1-919-573-9199

MANUFACTURER(S):  The Apache Software Foundation, Oracle, The
OpenSSL Project

PRODUCT NAME/MODEL #: Apache Cassandra

ECCN: 5D002

NOTIFICATION: http://www.apache.org/licenses/exports/

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [DISCUSS] changing default token behavior for 4.0

2018-09-23 Thread Nate McCall
Let's pick a default setup that works for most people (IME clusters <
30 nodes, but TLP and Instaclustr peeps probably have the most insight
here).

Then we just explain the heck out of it in the comments. I would also
like to see this include some details add/remove a DC to change the
values (perhaps we sub-task a doc creation for that?).

Good discussion though - thanks folks.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[RESULT] [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-20 Thread Nate McCall
With four binding +1s,  2 +0s, and no -1s, and 6 non-binding +1s, the
vote passes.

To re-iterate, resolving the license concerns is part of bringing
software into the project, not a reason to avoid trying. The incubator
PMC will have no problem sending a -1 if we cant get everything
together.

Regardless, I very much appreciate the discussion and opinions of
everyone. The non-binding votes are particularly helpful in
solidifying community agreement, IMO, so keep those coming.

Cheers,
-Nate

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Nate McCall
This will be the same process used for dtest. We will need to walk
this through the incubator per the process outlined here:

https://incubator.apache.org/guides/ip_clearance.html

Pending the outcome of this vote, we will create the JIRA issues for
tracking and after we go through the process, and discuss adding
committers in a separate thread (we need to do this atomically anyway
per general ASF committer adding processes).

Thanks,
-Nate

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [Discuss] Accept GoCQL driver donation

2018-09-12 Thread Nate McCall
Yep - that sounds like the best next step to me.

(apologies for spotty comms folks - been/still on vacation).
On Wed, Sep 12, 2018 at 8:03 AM sankalp kohli  wrote:
>
> Hi Nate,
> Looks like we had a lot of discussion here and everyone seems
> to be in favor. What is the next step? A vote?
> Thanks,
> Sankalp
>
> On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie  wrote:
>
> > Same here. I've been working on this project for a bit now, and I'm
> > planning to continue and contribute.
> >
> > I also like the idea of this project becoming an officially endorsed golang
> > Cassandra driver. Makes a lot of sense too.
> >
> > Alex.
> >
> >
> > On Sat., 1 Sep. 2018, 01:08 Chris Bannister, 
> > wrote:
> >
> > > I intend to stay on and continue to contribute.
> > >
> > > On Fri, 31 Aug 2018 at 4:37 pm, Jonathan Ellis 
> > wrote:
> > >
> > > > On Fri, Aug 31, 2018 at 9:14 AM Nate McCall 
> > wrote:
> > > >
> > > > > Hi folks,
> > > > > So I was recently talking with, Chris Bannister  the gocql [0]
> > > > > maintainer, and he expressed an interest in donating the driver to
> > the
> > > > > ASF.
> > > > >
> > > >
> > > > Is he looking to continue to maintain it or is he looking to give it a
> > > good
> > > > home when he moves on?
> > > >
> > > > We could accept this along the same lines as how we took in the dtest
> > > > > donation - going through the incubator IP clearance process [1], but
> > > > > in this case it's much simpler as an individual (Chris) owns the
> > > > > copyright.
> > > > >
> > > >
> > > > Is that actually the case?  Github says 128 contributors, and I don't
> > see
> > > > any mention of a CLA in
> > > > https://github.com/gocql/gocql/blob/master/CONTRIBUTING.md.
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[Discuss] Accept GoCQL driver donation

2018-08-31 Thread Nate McCall
Hi folks,
So I was recently talking with, Chris Bannister  the gocql [0]
maintainer, and he expressed an interest in donating the driver to the
ASF.

We could accept this along the same lines as how we took in the dtest
donation - going through the incubator IP clearance process [1], but
in this case it's much simpler as an individual (Chris) owns the
copyright.

I think the end goal here is to have a reference protocol
implementation controlled by the project at the least, potentially
replace cqlsh with a GoLang statically compiled binary eventually (?).

What are other folks' thoughts about this? (we are discussing, not voting).

[0] https://github.com/gocql/gocql
[1] https://incubator.apache.org/guides/ip_clearance.html

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Proposing an Apache Cassandra Management process

2018-08-17 Thread Nate McCall
> I'm not sure logistically how we get a new repo created and licensing and
> such, but if someone helps make it we can cut the patch against it
>
This is pretty straight forward. For precedent, see:
https://issues.apache.org/jira/browse/CASSANDRA-13634

We currently have three repositories:
https://git-wip-us.apache.org/repos/asf

I'm +0 on what approach we take.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Apache Cassandra Blog is now live

2018-08-07 Thread Nate McCall
It's just another contribution so JIRA + patch should suffice.

On Wed, Aug 8, 2018 at 2:11 PM, Dikang Gu  wrote:
> The fast streaming is very cool!
>
> We are also interested in contributing to the blog, what's the process?
>
> Thanks
> Dikang.
>
> On Tue, Aug 7, 2018 at 7:01 PM Nate McCall  wrote:
>
>> You can tell how psyched we are about it because we cross posted!
>>
>> Seriously though - this is by the community for the community, so any
>> ideas - please send them along.
>>
>> On Wed, Aug 8, 2018 at 1:53 PM, sankalp kohli 
>> wrote:
>> > Hi,
>> >  Apache Cassandra Blog is now live. Check out the first blog post.
>> >
>> >
>> http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html
>> >
>> > Thanks,
>> > Sankalp
>>
>> -
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>>
>
> --
> Dikang

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Apache Cassandra Blog is now live

2018-08-07 Thread Nate McCall
You can tell how psyched we are about it because we cross posted!

Seriously though - this is by the community for the community, so any
ideas - please send them along.

On Wed, Aug 8, 2018 at 1:53 PM, sankalp kohli  wrote:
> Hi,
>  Apache Cassandra Blog is now live. Check out the first blog post.
>
> http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html
>
> Thanks,
> Sankalp

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: GitHub PR ticket spam

2018-08-05 Thread Nate McCall
I'd be fine with putting this traffic through as 'worklog' - good call, Mick!

On Sun, Aug 5, 2018 at 7:56 PM, Mick Semb Wever  wrote:
>> I find this a bit annoying while subscribed to commits@,
>> especially since we created pr@ for these kind of messages. Also I don't
>> really see any value in mirroring all github comments to the ticket.
>
>
> I agree with you Stefan. It makes the jira tickets quite painful to read. And 
> I tend to make comments on the commits rather than the PRs so to avoid 
> spamming back to the jira ticket.
>
> But the linking to the PR is invaluable. And I can see Ariel's point about a 
> chronological historical archive.
>
>
>> Ponies would be for this to be mirrored to a tab
>> separate from comments in JIRA.
>
>
> Ariel, that would be the the "worklog" option.
> https://reference.apache.org/pmc/github
>
> If this works for you, and others, I can open a INFRA to switch to worklog.
> wdyt?
>
>
> Mick.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Tracking Testing, Release Status, and Build Health

2018-07-29 Thread Nate McCall
Thanks for putting this together Scott!

I like the idea of using Confluence for coordinating the bits and
pieces on the way to 4.0. There are better things out there, but It's
lightweight, straight forward and everyone with a ASF Jira account can
participate. The one thing it does very well IMO is link back and
forth with Jira so referencing issues is really easy.

Kafka also makes good use of Confluence for development process stuff.
it's not the most organized, but it's kept up to date and their
committers and contributors use it. Check our their release pages:
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.10.2.2

On Mon, Jul 30, 2018 at 12:04 PM, Scott Andreas  wrote:
> Hi everyone,
>
> As September approaches, I’ve been thinking about how we might be able to 
> share notes on testing and build health.
>
> Some types of information I have in mind:
>
> – Known issues with builds (e.g., master / nightlies) that impact the ability 
> to test the project. These could include known-flaky tests, bugs impacting 
> test automation, or specific features that aren’t functioning as designed. 
> Some contributors may be prefer to waive specific types of testing to prevent 
> their automation from failing; others may prefer to continue more exhaustive 
> testing of builds known not to be impacted by an issue.
> – Tracking high-priority bugs that are known blockers, either for test 
> automation or suitability of a release for dev / QA environments.
> – Pre-release checklists and outstanding to-do items that need to be 
> completed prior to cutting a build which aren’t necessarily best represented 
> by a JIRA ticket.
> – Performance test status – the characteristics of tests performed, hardware 
> configurations, and improvements / regressions identified over time.
>
> Some of this information may change often as development and testing progress 
> - as often as daily in some cases.
>
> Here are a couple examples of similar work in other projects:
>
> –
> – Hadoop’s “Release Status” docs in Confluence: 
> https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+2.8.0+Release
>
> The Hadoop project uses these status docs to track release blockers, to-do 
> items that need to be tracked ahead of release, and notes on scope as defined 
> by the community.
>
> – Hadoop’s “Road Map” docs in Confluence:
> https://cwiki.apache.org/confluence/display/HADOOP/Roadmap
>
> Similarly, the Hadoop project uses docs like this to track planned features 
> for each release, and feature freeze, code freeze, and planned release dates. 
> These are useful for organizing development and signposting what’s planned to 
> the user community.
>
> – “Are We Fast Yet”: A project from Mozilla tracking JS engine performance
> https://arewefastyet.com
>
> Perf testing of nightlies across a several platforms (and comparisons with 
> other JavaScript engines), useful for identifying regressions quickly and 
> tracking progress toward perf goals.
> –
>
> I’m curious on the dev community’s thoughts on how best to organize 
> information like this. My thinking is that by having a space to share this, 
> the community can be more informed on each others’ work toward testing, build 
> health, and active projects.
>
> The current Cassandra wiki (https://wiki.apache.org/cassandra) doesn’t appear 
> too active and carries a warning. What do others think about filing an INFRA 
> ticket to request a Confluence space at https://cwiki.apache.org for this 
> type of information?
>
> I’d be happy to help maintain information tracking build health, remaining 
> to-do’s, known test automation blockers, flaky tests, etc. as well.
>
> Cheers,
>
> – Scott
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.13

2018-07-25 Thread Nate McCall
+1

On Wed, Jul 25, 2018, 7:49 PM Michael Shuler  wrote:

> I propose the following artifacts for release as 2.2.13.
>
> sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1167/org/apache/cassandra/apache-cassandra/2.2.13/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1167/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> [2]: NEWS.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

2018-07-25 Thread Nate McCall
+1

On Wed, Jul 25, 2018, 7:47 PM Michael Shuler  wrote:

> I propose the following artifacts for release as 3.0.17.
>
> sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1165/org/apache/cassandra/apache-cassandra/3.0.17/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1165/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> [2]: NEWS.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

2018-07-25 Thread Nate McCall
+1

On Wed, Jul 25, 2018, 7:46 PM Michael Shuler  wrote:

> I propose the following artifacts for release as 3.11.3.
>
> sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1164/org/apache/cassandra/apache-cassandra/3.11.3/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1164/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: CHANGES.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> [2]: NEWS.txt:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: NGCC 2018?

2018-07-24 Thread Nate McCall
This was discussed amongst the PMC recently. We did not come to a
conclusion and there were not terribly strong feelings either way.

I don't feel like we need to hustle to get "NGCC" in place,
particularly given our decided focus on 4.0. However, that should not
stop us from doing an additional 'c* developer' event in sept. to
coincide with distributed data summit.

On Wed, Jul 25, 2018 at 5:03 AM, Patrick McFadin  wrote:
> Ben,
>
> Lynn Bender had offered a space the day before Distributed Data Summit in
> September (http://distributeddatasummit.com/) since we are both platinum
> sponsors. I thought he and Nate had talked about that being a good place
> for NGCC since many of us will be in town already.
>
> Nate, now that I've spoken for you, you can clarify, :D
>
> Patrick
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Branching Change for 4.0 Freeze

2018-07-13 Thread Nate McCall
+1
I appreciate Gary's points, but if it's not working and/or we have a
specific issue, we'll address it.




On Thu, Jul 12, 2018 at 9:46 AM, sankalp kohli  wrote:
> Hi,
> As discussed in the thread[1], we are proposing that we will not branch
> on 1st September but will only allow following merges into trunk.
>
> a. Bug and Perf fixes to 4.0.
> b. Critical bugs in any version of C*.
> c. Testing changes to help test 4.0
>
> If someone has a change which does not fall under these three, we can
> always discuss it and have an exception.
>
> Vote will be open for 72 hours.
>
> Thanks,
> Sankalp
>
> [1]
> https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.11.3

2018-07-02 Thread Nate McCall
+1

On Tue, Jul 3, 2018 at 8:11 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.11.3.
>
> sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.3-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1161/org/apache/cassandra/apache-cassandra/3.11.3/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1161/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> [2]: (NEWS.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.3-tentative
>
> --
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.0.17

2018-07-02 Thread Nate McCall
+1

On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.17.
>
> sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.17-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1160/org/apache/cassandra/apache-cassandra/3.0.17/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1160/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> [2]: (NEWS.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.17-tentative
>
> --
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.13

2018-07-02 Thread Nate McCall
+1

On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 2.2.13.
>
> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.13-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1159/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> [2]: (NEWS.txt)
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.13-tentative
>
> --
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Recommendation: running Cassandra in containers

2018-06-27 Thread Nate McCall
On Tue, Jun 26, 2018 at 3:12 AM, Pierre Mavro  wrote:
> Hi,
>
> Regarding the limits in linux cgroups (as used in Kubernetes/Mesos), I
> was wondering if there are any recommendation (didn't find anything on
> this topic).
>
> In general on Java 8 running instances, it is advised to run those
> options to take into account cgroup environment:
>
> -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
>
> Other tuning options for this exists (ex: MaxRAMFraction), I was
> wondering if there is any information somewhere about it.
>

Not that I've seen.

I think there is an opportunity for someone to do a thorough
investigation and writeup about it (particularly given y'alls
experience with C* over the past few years :)

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Hi-Rez of Apache Cassandra logo??

2018-06-26 Thread Nate McCall
Quick followup - here is a color pallet I pulled out of the logo:
https://coolors.co/export/png/7b8f9a-3d3b3b-9d9c9c-65adcc-dbeaf2

Folks should feel free to use this for any C* related presentations.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



CVE-2018-8016 on Apache Cassandra

2018-06-25 Thread Nate McCall
CVE-2018-8016 describes an issue with the default configuration of
Apache Cassandra releases 3.8 through 3.11.1 which binds an
unauthenticated JMX/RMI interface to all network interfaces allowing
attackers to execute arbitrary Java code via an RMI request. This
issue is a regression of the previously disclosed CVE-2015-0225.

The regression was introduced in
https://issues.apache.org/jira/browse/CASSANDRA-12109. The fix for the
regression is implemented in
https://issues.apache.org/jira/browse/CASSANDRA-14173. This fix is
contained in the 3.11.2 release of Apache Cassandra.

- The Apache Cassandra PMC

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Rocksandra performance test result

2018-06-02 Thread Nate McCall
On Sat, Jun 2, 2018 at 4:46 PM, Jay Zhuang  wrote:
> We're shadowing some production traffics to a Rocksandra cluster (
> https://github.com/Instagram/cassandra/tree/rocks_3.0), the P99 latency is
> significantly improved (about 6x for read, 12x for write). Here are the
> test details:
>
> https://docs.google.com/document/d/1cEM8ZqB5tOYVdsh1LpqSZ-eLasumWfzn_Tk_lDjxOTk/
>
> Thanks,
> Jay

Thanks for the update on performance. Those numbers are pretty interesting.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Rocksandra performance test result

2018-06-02 Thread Nate McCall
> Thanks for sharing, Jay.
>
> Could you say a bit more about how you’ve approached shadowing traffic 
> against an alternate cluster? (Asking not so much with regard to the 
> Rocksandra test, but toward shadowing methodology in general).

+1 to this. If someone out there had a method to transparently tee
read and write traffic to a Cassandra cluster, I would like to hear
about it as that would be hugely valuable to the community.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Hi-Rez of Apache Cassandra logo??

2018-05-18 Thread Nate McCall
Super cool. Thanks folks!

On Fri, May 18, 2018, 5:57 PM Michael Shuler <mich...@pbandjelly.org> wrote:

> Nice, thanks!
>
> I went ahead and committed the files to SVN. I hope that was OK, Scott :)
>
> https://svn.apache.org/repos/asf/cassandra/logo/
>
> 
> r1831825 | mshuler | 2018-05-18 00:53:54 -0500 (Fri, 18 May 2018) | 5 lines
>
> Add Apache Cassandra logos provided by Scott Andreas
>
> Since Scott uploaded them to a temporary location, let's add them here.
>
> https://lists.apache.org/thread.html/981adf13e8d483d9de41bf5ab30328aafe8544da6b36036e64744046@%3Cdev.cassandra.apache.org%3E
>
> --
> Kind regards,
> Michael
>
> On 05/18/2018 12:23 AM, Scott Andreas wrote:
> > Hi Nate,
> >
> > Here are vectorized versions of the logo reading "Apache Cassandra":
> > – http://paradoxica.net/img/cassandra/apache-cassandra.pdf
> > – http://paradoxica.net/img/cassandra/apache-cassandra.eps
> >
> > This is not an official graphic, but for the sake of provenance:
> >
> > – The image is sourced from:
> https://svn.apache.org/repos/asf/cassandra/logo/cassandra.svg
> > – I've replaced "cassandra" with "apache cassandra" set in Cronos Pro
> Bold Italic (which I believe is the original typeface).
> > – And exported as a vector PDF and EPS, which should be scalable to any
> size you need.
> >
> > The above URLs are not permanent; since the list allows max-1MB
> attachments, I've uploaded them to a temporary location.
> >
> > Happy to make changes or to share in another format if that works better.
> >
> > – Scott
> >
> > 
> > From: Nate McCall <zznat...@gmail.com>
> > Sent: Thursday, May 17, 2018 9:45:18 PM
> > To: dev
> > Subject: Hi-Rez of Apache Cassandra logo??
> >
> > I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
> > (that last part is important) basically what we have on the website.
> > I'm gonna run off some laptop stickers on sticker mule.
> >
> > Provided I can track that down, you can have one if you show up here:
> > https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/
> >
> > Once I get this squared away, i'll create a template and share it
> > somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
> > stuff provided they follow the merchandising guidelines:
> > https://www.apache.org/foundation/marks/merchandise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Hi-Rez of Apache Cassandra logo??

2018-05-17 Thread Nate McCall
I'm looking for a hi-rez source of 'the eye' with "Apache Cassandra"
(that last part is important) basically what we have on the website.
I'm gonna run off some laptop stickers on sticker mule.

Provided I can track that down, you can have one if you show up here:
https://www.meetup.com/Apache-Cassandra-Bay-Area/events/250901453/

Once I get this squared away, i'll create a template and share it
somewhere (maybe check it in?) so anyone can print "Apache Cassandra"
stuff provided they follow the merchandising guidelines:
https://www.apache.org/foundation/marks/merchandise

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-05-08 Thread Nate McCall
To close the loop on this thread: I don't think we need to do an
official vote here, but let's just put it on our calendars that we are
aiming to branch off 4.0 and freeze the first week of Sept.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Evolving the client protocol

2018-04-23 Thread Nate McCall
Folks,
Before this goes much further, let's take a step back for a second.

I am hearing the following: Folks are fine with CASSANDRA-14311 and
CASSANDRA-2848 *BUT* they don't make much sense from the project's
perspective without a reference implementation. I think the shard
concept is too abstract for the project right now, so we should
probably set that one aside.

Dor and Avi, I appreciate you both engaging directly on this. Where
can we find common ground on this?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-12 Thread Nate McCall
> If we push it to Sept 1 freeze, I'll personally spend a lot of time testing.
>
> What can I do to help convince the Jun1 folks that Sept1 is acceptable?

I can come around to that. At this point, I really just want us to
have a date we can start talking to/planning around.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-12 Thread Nate McCall
To be clear, more who is willing to commit to testing should we go this
route.

On Fri, Apr 13, 2018, 7:41 AM Nate McCall <zznat...@gmail.com> wrote:

> Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.
>
> We (tlp) will put some resources on this via going through some canned
> scenarios we have internally. We aren't in a position to test data validity
> (yet) but we can do a lot around cluster behavior.
>
> Who else has specific stuff they are willing to do? Even if it's just
> tee'ing prod traffic, that would be hugely valuable.
>
> On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa <jji...@gmail.com> wrote:
>
>> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad <j...@jonhaddad.com>
>> wrote:
>>
>> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
>> that
>> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
>> because
>> > it's a big task and there's not enough stuff in 4.0 to make it
>> worthwhile.
>> >
>> >
>> More like "not enough stuff in 4.0 to make it worthwhile for the people I
>> personally know to be willing and able to find the weird bugs".
>>
>>
>> > If that is the case, I'm not quite sure how increasing the surface area
>> of
>> > changed code which needs to be vetted is going to make the process any
>> > easier.
>>
>>
>> It changes the interest level of at least some of the people able to
>> properly test it from "not willing" to "willing".
>>
>> Totally possible that there exist people who are willing and able to find
>> and fix those bugs, who just haven't committed to it in this thread.
>> That's
>> probably why Sankalp keeps asking who's actually willing to do the testing
>> on June 2 - if nobody's going to commit to doing real testing on June 2,
>> all we're doing is adding inconvenience to those of us who'd be willing to
>> do it later in the year.
>>
>


Re: Roadmap for 4.0

2018-04-12 Thread Nate McCall
Ok. So who's willing to test 4.0 on June 2nd? Let's start a sign up.

We (tlp) will put some resources on this via going through some canned
scenarios we have internally. We aren't in a position to test data validity
(yet) but we can do a lot around cluster behavior.

Who else has specific stuff they are willing to do? Even if it's just
tee'ing prod traffic, that would be hugely valuable.

On Fri, Apr 13, 2018, 6:15 AM Jeff Jirsa  wrote:

> On Thu, Apr 12, 2018 at 9:41 AM, Jonathan Haddad 
> wrote:
>
> > It sounds to me (please correct me if I'm wrong) like Jeff is arguing
> that
> > releasing 4.0 in 2 months isn't worth the effort of evaluating it,
> because
> > it's a big task and there's not enough stuff in 4.0 to make it
> worthwhile.
> >
> >
> More like "not enough stuff in 4.0 to make it worthwhile for the people I
> personally know to be willing and able to find the weird bugs".
>
>
> > If that is the case, I'm not quite sure how increasing the surface area
> of
> > changed code which needs to be vetted is going to make the process any
> > easier.
>
>
> It changes the interest level of at least some of the people able to
> properly test it from "not willing" to "willing".
>
> Totally possible that there exist people who are willing and able to find
> and fix those bugs, who just haven't committed to it in this thread. That's
> probably why Sankalp keeps asking who's actually willing to do the testing
> on June 2 - if nobody's going to commit to doing real testing on June 2,
> all we're doing is adding inconvenience to those of us who'd be willing to
> do it later in the year.
>


Re: Roadmap for 4.0

2018-04-10 Thread Nate McCall
A lot of good points and everyone's input is really appreciated.

So it sounds like we are building consensus towards June 1 for 4.0
branch point/feature freeze and the goal is stability. (No one has
come with a hard NO anyway).

I want to reiterate Sylvain's point that we can do whatever we want in
terms of dropping a new feature 4.1/5.0 (or whatev.) whenever we want.

In thinking about this, what is stopping us from branching 4.0 a lot
sooner? Like now-ish? This will let folks start hacking on trunk with
new stuff, and things we've gotten close on can still go in 4.0
(Virtual tables). I guess I'm asking here if we want to disambiguate
"feature freeze" from "branch point?" I feel like this makes sense.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Failed request after changing compression strategy from LZ4 to Deflate and using upgradesstable

2018-04-10 Thread Nate McCall
Hi Hitesh,
This list is for conversations regarding Cassandra development. Can
you subscribe and post this to us...@cassandra.apache.org instead? You
will get a much wider audience when you do.



On Tue, Apr 10, 2018 at 10:45 PM, hitesh dua  wrote:
>  Hi,
> My Compression strategy in Production was *LZ4 Compression. *But I modified
> it to *Deflate *using alter command
>
> For compression change, we have to use *nodetool Upgradesstables *to
> forcefully upgrade the compression strategy on all sstables
>
> But once upgradesstabloes command completed on all the 5 nodes in the
> cluster, My requests started to fail, both read and write
>
> Replication Factor - 3
> Read Consistency - 1
> Write Consistency - 1
> FYI - I am also using lightweight transaction which uses PAXOS
> Cassandra Version 3.10
>
> I am now facing Following Errors in my debug.log file and some of my
> requests have started to fail :
>
> Debug.log
>
> ERROR [ReadRepairStage:82952] 2018-04-09 19:05:20,669
>>> CassandraDaemon.java:229 - Exception in thread
>>> Thread[ReadRepairStage:82952,5,main]
>>
>> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out
>>> - received only 0 responses.
>>
>> at 
>> org.apache.cassandra.service.DataResolver$RepairMergeListener.close(DataResolver.java:171)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.db.partitions.UnfilteredPartitionIterat
>>> ors$2.close(UnfilteredPartitionIterators.java:182)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:82)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 
>> org.apache.cassandra.service.DataResolver.compareResponses(DataResolver.java:89)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThr
>>> ow(AsyncRepairCallback.java:50) ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> ~[na:1.8.0_144]
>>
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> ~[na:1.8.0_144]
>>
>> at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$
>>> threadLocalDeallocator$0(NamedThreadFactory.java:79)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
>>
>> DEBUG [ReadRepairStage:82953] 2018-04-09 19:05:22,932
>>> ReadCallback.java:242 - Digest mismatch:
>>
>> org.apache.cassandra.service.DigestMismatchException: Mismatch for key
>>> DecoratedKey(-2666936192316364820, 5756f5b8e7b341afa22cef22c5d33260)
>>> (d29a0e2a05f81315f0945dee5a210060 vs d41d8cd98f00b204e9800998ecf8427e)
>>
>> at 
>> org.apache.cassandra.service.DigestResolver.compareResponses(DigestResolver.java:92)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 
>> org.apache.cassandra.service.ReadCallback$AsyncRepairRunner.run(ReadCallback.java:233)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> [na:1.8.0_144]
>>
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> [na:1.8.0_144]
>>
>> at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$
>>> threadLocalDeallocator$0(NamedThreadFactory.java:79)
>>> [apache-cassandra-3.10.jar:3.10]
>>
>> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_144]
>>
>> INFO  [HintsDispatcher:767] 2018-04-09 19:05:24,874
>>> HintsDispatchExecutor.java:283 - Finished hinted handoff of file
>>> 68c7c130-6cf8-4864-bde8-1819f238045c-1523315072851-1.hints to endpoint
>>> 68c7c130-6cf8-4864-bde8-1819f238045c, partially
>>
>> DEBUG [ReadRepairStage:82950] 2018-04-09 19:05:24,932
>>> DataResolver.java:169 - Timeout while read-repairing after receiving all 1
>>> data and digest responses
>>
>> ERROR [ReadRepairStage:82950] 2018-04-09 19:05:24,933
>>> CassandraDaemon.java:229 - Exception in thread
>>> Thread[ReadRepairStage:82950,5,main]
>>
>> org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out
>>> - received only 0 responses.
>>
>> at 
>> org.apache.cassandra.service.DataResolver$RepairMergeListener.close(DataResolver.java:171)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.db.partitions.UnfilteredPartitionIterat
>>> ors$2.close(UnfilteredPartitionIterators.java:182)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.db.transform.BaseIterator.close(BaseIterator.java:82)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 
>> org.apache.cassandra.service.DataResolver.compareResponses(DataResolver.java:89)
>>> ~[apache-cassandra-3.10.jar:3.10]
>>
>> at org.apache.cassandra.service.AsyncRepairCallback$1.runMayThr
>>> ow(AsyncRepairCallback.java:50) ~[apache-cassandra-3.10.jar:3.10]
>>
>> at 

Re: Roadmap for 4.0

2018-04-09 Thread Nate McCall
> I'd like to see pluggable storage and transient replica tickets land, for
> starters.

I think both those features are, frankly, necessary for our future. On
the other hand, they both have the following risks:
1. core behavioral changes
2. require changing a (relatively) large surface area of code

We can aim to de-risk 4.0 by focusing on what we have now which is
solid repair and NIO internode (maybe we move the 4.0 branch timeline
up?), aiming for a 4.1 following soon-ish.

Or we can go in eyes open and agree on a larger footprint 4.0.

I'm on the fence, tbh (can't emphasize enough how big both those
features will be). I just want everyone to know what we are getting
into and that we are potentially impacting our goals of "stable" ==
"exciting."

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [Discuss] patch review virtual hackathon

2018-04-05 Thread Nate McCall
That could work as well. My goal is that we figure out how to resource and
focus on this for a bit.

On Fri, Apr 6, 2018, 5:02 PM sankalp kohli <kohlisank...@gmail.com> wrote:

> I think it better to pick some JIRAs per 2-3 weeks and have people review
> them. In my experience, it is hard to synchronize all people across
> companies during one 72 hour slot.
>
>
>
> On Thu, Apr 5, 2018 at 9:48 PM, Nate McCall <zznat...@gmail.com> wrote:
>
> > Per Kurt's point in our release thread, we have a lot to do here.
> >
> > What do folks feel about setting aside a 72hr period at some point soon
> > where we get some allotment from our employers to spend a window or two
> of
> > time therein reviewing patches?
> >
> > I have seen a couple of other ASF communities do this type of thing
> > effectively in recent months. If we pull this off I think it could set an
> > excellent precedent for swarming on other things in the future.
> >
>


[Discuss] patch review virtual hackathon

2018-04-05 Thread Nate McCall
Per Kurt's point in our release thread, we have a lot to do here.

What do folks feel about setting aside a 72hr period at some point soon
where we get some allotment from our employers to spend a window or two of
time therein reviewing patches?

I have seen a couple of other ASF communities do this type of thing
effectively in recent months. If we pull this off I think it could set an
excellent precedent for swarming on other things in the future.


Re: Roadmap for 4.0

2018-04-05 Thread Nate McCall
>>
>> So long as non-user-visible improvements, including big ones, can still go
>> in 4.0 at that stage, I’m all for it.
>
>
> My understanding is that after June 1st the 4.0 branch would be created and
> would be bugfix only. It's not really a feature freeze if you allow
> improvements after that, which is why they'd instead go to trunk.
>
> I'm also on the "too soon" train so pushing it back to August or so is
> desirable to me.
>

For those wanting to delay, are we just dancing around inclusion of
some pet features? This is fine, I just think we need to communicate
what we are after if so.

We can do two things:
1. Lay our cards on the table about what we want included in 4.0 and
work to get those in
2. Agree to keep June 1 follow up a lot quicker with a 4.1

I do want to remind everyone though that each new feature is at odds
with our stability goals for 4.0.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Repair scheduling tools

2018-04-05 Thread Nate McCall
I think a take away here is that we can't assume a level of operation
maturity will coincide automatically with scale. To make our core
features robust, we have to account for less-experienced users.

A lot of folks on this thread have *really* strong ops and OpsViz
stories. Let's not forget that most of our users don't.
((Un)fortunately, as a consulting firm, we tend to see the worst of
this).

On Fri, Apr 6, 2018 at 2:52 PM, Jonathan Haddad  wrote:
> Off the top of my head I can remember clusters with 600 or 700 nodes with
> 256 tokens.
>
> Not the best situation, but it’s real. 256 has been the default for better
> or worse.
>
> On Thu, Apr 5, 2018 at 7:41 PM Joseph Lynch  wrote:
>
>> >
>> > We see this in larger clusters regularly. Usually folks have just
>> > 'grown into it' because it was the default.
>> >
>>
>> I could understand a few dozen nodes with 256 vnodes, but hundreds is
>> surprising. I have a whitepaper draft lying around showing how vnodes
>> decrease availability in large clusters by orders of magnitude, I'll polish
>> it up and send it out to the list when I get a second.
>>
>> In the meantime, sorry for de-railing a conversation about repair
>> scheduling to talk about vnodes, let's chat about that in a different
>> thread :-)
>>
>> -Joey
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Repair scheduling tools

2018-04-05 Thread Nate McCall
>
> Somewhat beside the point, I wasn't aware there were any 100 node +
> clusters running with vnodes, if my math is correct they would be
> excessively vulnerable to outages with that many vnodes and that many
> nodes. Most of the large clusters I've heard of (100 nodes plus) are
> running with single or at most 4 tokens per node.

We see this in larger clusters regularly. Usually folks have just
'grown into it' because it was the default.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-05 Thread Nate McCall
>>> My understanding, from Nate's summary, was June 1 is the freeze date for
>>> features. I expect we would go for at least 4 months (if not longer)
>>> testing, fixing bugs, early dogfooding, and so on. I also equated June 1
>>> with the data which we would create a 'cassandra-4.0' branch, and thus the
>>> merge order becomes: 3.0->3,11->4.0->trunk.

This^ (apologies - 'freeze for alpha' was a bit open for interpretation :)

The idea of making this point in time the 4.0 branch date and merge
order switch is a good one.

Can we move our gelling consensus here towards this goal?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-04 Thread Nate McCall
Top-posting as I think this summary is on point - thanks, Scott! (And
great to have you back, btw).

It feels to me like we are coalescing on two points:
1. June 1 as a freeze for alpha
2. "Stable" is the new "Exciting" (and the testing and dogfooding
implied by such before a GA)

How do folks feel about the above points?


> Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:
>
> –––
> Jeff:
>>> A hard date for a feature freeze makes sense, a hard date for a release
>>> does not.
>
> Josh:
>> Strongly agree. We should also collectively define what "Done" looks like
>> post freeze so we don't end up in bike-shedding hell like we have in the
>> past.
> –––
>
> Another way of saying this: ensuring that the 4.0 release is of high quality 
> is more important than cutting the release on a specific date.
>
> If we adopt Sylvain's suggestion of freezing features on a "feature complete" 
> date (modulo a "definition of done" as Josh suggested), that will help us 
> align toward the polish, performance work, and dog-fooding needed to feel 
> great about shipping 4.0. It's a good time to start thinking about the 
> approaches to testing, profiling, and dog-fooding various contributors will 
> want to take on before release.
>
> I love how Ben put it:
>
>> An "exciting" 4.0 release to me is one that is stable and usable
>> with no perf regressions on day 1 and includes some of the big
>> internal changes mentioned previously.
>>
>> This will set the community up well for some awesome and exciting
>> stuff that will still be in the pipeline if it doesn't make it to 4.0.
>
> That sounds great to me, too.
>
> – Scott

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-04 Thread Nate McCall
On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
 wrote:
> Can I suggest a way of defining the next few progressions as a way of 
> approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the code as 
> can be ready for a release on a date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of
discussion. Please see the following two (lengthy) threads from last
year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Roadmap for 4.0

2018-04-03 Thread Nate McCall
> My concrete proposal would be to declare a feature freeze for 4.0 in 2
> months,
> so say June 1th. That leave some time for finishing features that are in
> progress, but not too much to get derailed. And let's be strict on that
> freeze.

I quite like this suggestion. Thanks, Sylvain.

> After that, we'll see how quickly we can get stuffs to stabilize but I'd
> suggest aiming for an alpha 3-4 weeks after that.

Yes. We've had folks step up and offer to dog-food 4.0 and can
probably solicit some more with some outreach.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Repair scheduling tools

2018-04-03 Thread Nate McCall
This document does a really good job of listing out some of the issues
of coordinating scheduling repair. Regardless of which camp you fall
into, it is certainly worth a read.

On Wed, Apr 4, 2018 at 8:10 AM, Joseph Lynch  wrote:
> I just want to say I think it would be great for our users if we moved
> repair scheduling into Cassandra itself. The team here at Netflix has
> opened the ticket 
> and have written a detailed design document
> 
> that includes problem discussion and prior art if anyone wants to
> contribute to that. We tried to fairly discuss existing solutions, what
> their drawbacks are, and a proposed solution.
>
> If we were to put this as part of the main Cassandra daemon, I think it
> should probably be marked experimental and of course be something that
> users opt into (table by table or cluster by cluster) with the
> understanding that it might not fully work out of the box the first time we
> ship it. We have to be willing to take risks but we also have to be honest
> with our users. It may help build confidence if a few major deployments use
> it (such as Netflix) and we are happy of course to provide that QA as best
> we can.
>
> -Joey
>
> On Tue, Apr 3, 2018 at 10:48 AM, Blake Eggleston 
> wrote:
>
>> Hi dev@,
>>
>>
>>
>> The question of the best way to schedule repairs came up on
>> CASSANDRA-14346, and I thought it would be good to bring up the idea of an
>> external tool on the dev list.
>>
>>
>>
>> Cassandra lacks any sort of tools for automating routine tasks that are
>> required for running clusters, specifically repair. Regular repair is a
>> must for most clusters, like compaction. This means that, especially as far
>> as eventual consistency is concerned, Cassandra isn’t totally functional
>> out of the box. Operators either need to find a 3rd party solution or
>> implement one themselves. Adding this to Cassandra would make it easier to
>> use.
>>
>>
>>
>> Is this something we should be doing? If so, what should it look like?
>>
>>
>>
>> Personally, I feel like this is a pretty big gap in the project and would
>> like to see an out of process tool offered. Ideally, Cassandra would just
>> take care of itself, but writing a distributed repair scheduler that you
>> trust to run in production is a lot harder than writing a single process
>> management application that can failover.
>>
>>
>>
>> Any thoughts on this?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Blake
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: A JIRA proposing a seperate repository for the online documentation

2018-03-18 Thread Nate McCall
On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman
 wrote:
> I don't know what we are doing for the website technologies right now because 
> like everything else what we do is not documented anywhere.  Where are the 
> servers: the cloud?  What server software are we running?  How is the html, 
> etc. generated and published?  How is search done for the website?

http://cassandra.apache.org/doc/latest/development/documentation.html
The resulting static HTML from Sphinx is hosted on ASF infrastructure.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Expensive metrics?

2018-02-27 Thread Nate McCall
Hi Micke,
There is some good research in here - have you had a chance to create
some issues in Jira from this?

On Fri, Feb 23, 2018 at 6:28 AM, Michael Burman  wrote:
> Hi,
>
> I was referring to this article by Shipilev (there are few small issues
> forgotten in that url you pasted):
>
> https://shipilev.net/blog/2014/nanotrusting-nanotime/
>
> And his lovely recommendation on it: "System.nanoTime is as bad as
> String.intern now: you can use it, but use it wisely. ". And Cassandra uses
> it quite a lot in the write path at least. There isn't necessarily a better
> option in Java for it, but for that reason we shouldn't push them everywhere
> in the code "for fun".
>
>   - Micke
>
>
>
> On 02/22/2018 06:08 PM, Jeremiah D Jordan wrote:
>>
>> re: nanoTime vs currentTimeMillis there is a good blog post here about the
>> timing of both and how your choice of Linux clock source can drastically
>> effect the speed of the calls, and also showing that in general on linux
>> there is no perf improvement for one over the other.
>> http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html
>>
>>> On Feb 22, 2018, at 11:01 AM, Blake Eggleston 
>>> wrote:
>>>
>>> Hi Micke,
>>>
>>> This is really cool, thanks for taking the time to investigate this. I
>>> believe the metrics around memtable insert time come in handy in identifying
>>> high partition contention in the memtable. I know I've been involved in a
>>> situation over the past year where we got actionable info from this metric.
>>> Reducing resolution to milliseconds is probably a no go since most things in
>>> this path should complete in less than a millisecond.
>>>
>>> Revisiting the use of the codahale metrics in the hot path like this
>>> definitely seems like a good idea though. I don't think it's been something
>>> we've talked about a lot, and it definitely looks like we could benefit from
>>> using something more specialized here. I think it's worth doing, especially
>>> since there won't be any major changes to how we do threading in 4.0. It's
>>> probably also worth opening a JIRA and investigating the calls to nano time.
>>> We at least need microsecond resolution here, and there could be something
>>> we haven't thought of? It's worth a look at least.
>>>
>>> Thanks,
>>>
>>> Blake
>>>
>>> On 2/22/18, 6:10 AM, "Michael Burman"  wrote:
>>>
>>> Hi,
>>>
>>> I wanted to get some input from the mailing list before making a JIRA
>>> and potential fixes. I'll touch the performance more on latter part,
>>> but
>>> there's one important question regarding the write latency metric
>>> recording place. Currently we measure the writeLatency (and metric
>>> write
>>> sampler..) in ColumnFamilyStore.apply() and this is also the metric
>>> we
>>> then replicate to Keyspace metrics etc.
>>>
>>> This is an odd place for writeLatency. Not to mention it is in a
>>> hot-path of Memtable-modifications, but it also does not measure the
>>> real write latency, since it completely ignores the CommitLog latency
>>> in
>>> that same process. Is the intention really to measure
>>> Memtable-modification latency only or the actual write latencies?
>>>
>>> Then the real issue.. this single metric is a cause of huge overhead
>>> in
>>> Memtable processing. There are several metrics / events in the CFS
>>> apply
>>> method, including metric sampler, storageHook reportWrite,
>>> colUpdateTimeDeltaHistogram and metric.writeLatency. These are not
>>> free
>>> at all when it comes to the processing. I made a small JMH benchmark
>>> here:
>>> https://gist.github.com/burmanm/b5b284bc9f1d410b1d635f6d3dac3ade
>>> that I'll be referring to.
>>>
>>> The most offending of all these metrics is the writeLatency metric.
>>> What
>>> it does is update the latency in codahale's timer, doing a histogram
>>> update and then going through all the parent metrics also which
>>> update
>>> the keyspace writeLatency and globalWriteLatency. When measuring the
>>> performance of Memtable.put with parameter of 1 partition (to reduce
>>> the
>>> ConcurrentSkipListMap search speed impact - that's separate issue and
>>> takes a little bit longer to solve although I've started to prototype
>>> something..) on my machine I see 1.3M/s performance with the metric
>>> and
>>> when it is disabled the performance climbs to 4M/s. So the overhead
>>> for
>>> this single metric is ~2/3 of total performance. That's insane. My
>>> perf
>>> stats indicate that the CPU is starved as it can't get enough data
>>> in.
>>>
>>> Removing the replication from TableMetrics to the Keyspace & global
>>> latencies in the write time (and doing this when metrics are
>>> requested
>>> instead) improves the performance to 2.1M/s on my machine. It's an
>>> improvement, but it's still huge amount. Even when we pressure the
>>> 

Re: Why isn't there a separate JVM per table?

2018-02-22 Thread Nate McCall
Agree that any first efforts per compaction should be on profiling.
Probably some low-hanging fruit there.

On Fri, Feb 23, 2018 at 11:55 AM, Jeff Jirsa <jji...@gmail.com> wrote:
> Bloom filters are offheap.
>
> To be honest, there may come a time when it makes sense to move compaction
> into its own JVM, but it would be FAR less effort to just profile what
> exists now and fix the problems.
>
>
>
> On Thu, Feb 22, 2018 at 2:52 PM, Carl Mueller <carl.muel...@smartthings.com>
> wrote:
>
>> BLoom filters... nevermind
>>
>>
>> On Thu, Feb 22, 2018 at 4:48 PM, Carl Mueller <
>> carl.muel...@smartthings.com>
>> wrote:
>>
>> > Is the current reason for a large starting heap due to the memtable?
>> >
>> > On Thu, Feb 22, 2018 at 4:44 PM, Carl Mueller <
>> > carl.muel...@smartthings.com> wrote:
>> >
>> >>  ... compaction on its own jvm was also something I was thinking about,
>> >> but then I realized even more JVM sharding could be done at the table
>> level.
>> >>
>> >> On Thu, Feb 22, 2018 at 4:09 PM, Jon Haddad <j...@jonhaddad.com> wrote:
>> >>
>> >>> Yeah, I’m in the compaction on it’s own JVM camp, in an ideal world
>> >>> where we’re isolating crazy GC churning parts of the DB.  It would mean
>> >>> reworking how tasks are created and removal of all shared state in
>> favor of
>> >>> messaging + a smarter manager, which imo would be a good idea
>> regardless.
>> >>>
>> >>> It might be a better use of time (especially for 4.0) to do some GC
>> >>> performance profiling and cut down on the allocations, since that
>> doesn’t
>> >>> involve a massive effort.
>> >>>
>> >>> I’ve been meaning to do a little benchmarking and profiling for a while
>> >>> now, and it seems like a few others have the same inclination as well,
>> >>> maybe now is a good time to coordinate that.  A nice perf bump for 4.0
>> >>> would be very rewarding.
>> >>>
>> >>> Jon
>> >>>
>> >>> > On Feb 22, 2018, at 2:00 PM, Nate McCall <zznat...@gmail.com> wrote:
>> >>> >
>> >>> > I've heard a couple of folks pontificate on compaction in its own
>> >>> > process as well, given it has such a high impact on GC. Not sure
>> about
>> >>> > the value of individual tables. Interesting idea though.
>> >>> >
>> >>> > On Fri, Feb 23, 2018 at 10:45 AM, Gary Dusbabek <gdusba...@gmail.com
>> >
>> >>> wrote:
>> >>> >> I've given it some thought in the past. In the end, I usually talk
>> >>> myself
>> >>> >> out of it because I think it increases the surface area for failure.
>> >>> That
>> >>> >> is, managing N processes is more difficult that managing one
>> process.
>> >>> But
>> >>> >> if the additional failure modes are addressed, there are some
>> >>> interesting
>> >>> >> possibilities.
>> >>> >>
>> >>> >> For example, having gossip in its own process would decrease the
>> odds
>> >>> that
>> >>> >> a node is marked dead because STW GC is happening in the storage
>> JVM.
>> >>> On
>> >>> >> the flipside, you'd need checks to make sure that the gossip process
>> >>> can
>> >>> >> recognize when the storage process has died vs just running a long
>> GC.
>> >>> >>
>> >>> >> I don't know that I'd go so far as to have separate processes for
>> >>> >> keyspaces, etc.
>> >>> >>
>> >>> >> There is probably some interesting work that could be done to
>> support
>> >>> the
>> >>> >> orgs who run multiple cassandra instances on the same node (multiple
>> >>> >> gossipers in that case is at least a little wasteful).
>> >>> >>
>> >>> >> I've also played around with using domain sockets for IPC inside of
>> >>> >> cassandra. I never ran a proper benchmark, but there were some
>> >>> throughput
>> >>> >> advantages to this approach.
>> >>> >>
>> >>> >> Cheers,
>> >>> >>
>> &

Re: Why isn't there a separate JVM per table?

2018-02-22 Thread Nate McCall
I've heard a couple of folks pontificate on compaction in its own
process as well, given it has such a high impact on GC. Not sure about
the value of individual tables. Interesting idea though.

On Fri, Feb 23, 2018 at 10:45 AM, Gary Dusbabek  wrote:
> I've given it some thought in the past. In the end, I usually talk myself
> out of it because I think it increases the surface area for failure. That
> is, managing N processes is more difficult that managing one process. But
> if the additional failure modes are addressed, there are some interesting
> possibilities.
>
> For example, having gossip in its own process would decrease the odds that
> a node is marked dead because STW GC is happening in the storage JVM. On
> the flipside, you'd need checks to make sure that the gossip process can
> recognize when the storage process has died vs just running a long GC.
>
> I don't know that I'd go so far as to have separate processes for
> keyspaces, etc.
>
> There is probably some interesting work that could be done to support the
> orgs who run multiple cassandra instances on the same node (multiple
> gossipers in that case is at least a little wasteful).
>
> I've also played around with using domain sockets for IPC inside of
> cassandra. I never ran a proper benchmark, but there were some throughput
> advantages to this approach.
>
> Cheers,
>
> Gary.
>
>
> On Thu, Feb 22, 2018 at 8:39 PM, Carl Mueller 
> wrote:
>
>> GC pauses may have been improved in newer releases, since we are in 2.1.x,
>> but I was wondering why cassandra uses one jvm for all tables and
>> keyspaces, intermingling the heap for on-JVM objects.
>>
>> ... so why doesn't cassandra spin off a jvm per table so each jvm can be
>> tuned per table and gc tuned and gc impacts not impact other tables? It
>> would probably increase the number of endpoints if we avoid having an
>> overarching query router.
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] (Take 2) Release Apache Cassandra 3.0.16

2018-02-15 Thread Nate McCall
Thanks, Jason!!

On Fri, Feb 16, 2018 at 1:18 PM, Jason Brown <jasedbr...@gmail.com> wrote:
> Nate, I can do this.
>
> On Thu, Feb 15, 2018 at 2:51 PM, Nate McCall <zznat...@gmail.com> wrote:
>
>> >
>> > My circleci test runs fail on lack of resources and I understand now
>> > that Jason used the circleci configuration from the trunk branch to run
>> > the 3.0 and 3.11 branches. These branches should get commits for a
>> > working CI configuration in-tree.
>> >
>>
>> Quick follow up - does someone have an issue/action item on updating these:
>>
>> https://github.com/apache/cassandra/blob/cassandra-3.0/circle.yml
>> https://github.com/apache/cassandra/blob/cassandra-3.11/circle.yml
>>
>> Still showing as out of date(?).
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] (Take 2) Release Apache Cassandra 3.0.16

2018-02-15 Thread Nate McCall
>
> My circleci test runs fail on lack of resources and I understand now
> that Jason used the circleci configuration from the trunk branch to run
> the 3.0 and 3.11 branches. These branches should get commits for a
> working CI configuration in-tree.
>

Quick follow up - does someone have an issue/action item on updating these:

https://github.com/apache/cassandra/blob/cassandra-3.0/circle.yml
https://github.com/apache/cassandra/blob/cassandra-3.11/circle.yml

Still showing as out of date(?).

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



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

2018-02-14 Thread Nate McCall
+1

On Thu, Feb 15, 2018 at 10:09 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.11.2.
>
> sha1: 1d506f9d09c880ff2b2693e3e27fa58c02ecf398
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.2-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1158/org/apache/cassandra/apache-cassandra/3.11.2/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1158/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> [2]: (NEWS.txt) https://goo.gl/kpnVHp
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] (Take 2) Release Apache Cassandra 3.0.16

2018-02-14 Thread Nate McCall
+1

On Thu, Feb 15, 2018 at 9:40 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.16.
>
> sha1: 890f319142ddd3cf2692ff45ff28e71001365e96
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.16-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1157/org/apache/cassandra/apache-cassandra/3.0.16/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1157/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> [2]: (NEWS.txt) https://goo.gl/EkrT4G
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

2018-02-12 Thread Nate McCall
+1

Thanks for the reroll!!

On Feb 13, 2018 4:41 PM, "Michael Shuler"  wrote:

> I propose the following artifacts for release as 3.11.2.
>
> sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.2-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> [2]: (NEWS.txt) https://goo.gl/kpnVHp
>
>


Re: [VOTE] Release Apache Cassandra 3.11.2

2018-02-12 Thread Nate McCall
I thought we had committed CASSANDRA-14212 last week. We need a
release bad enough that I don't want to sink this with a -1, but we
have seen this be an issue with folks a couple of times recently.



On Tue, Feb 13, 2018 at 10:16 AM, Jon Haddad  wrote:
> I’m a +1 on getting this into 3.11.2.
>
>> On Feb 12, 2018, at 1:11 PM, mck  wrote:
>>
>>> I propose the following artifacts for release as 3.11.2.
>>> …
>>> The vote will be open for 72 hours (longer if needed).
>>
>>
>> I just pushed the back-port of CASSANDRA-13080 (under CASSANDRA-14212).
>> This is the improvement "Use new token allocation for non bootstrap case as 
>> well".
>> We've seen that this effects 3.11.1 users and that it would be positive to 
>> see it in 3.11.2.
>>
>> Any chance we could recut 3.11.2 ?
>>
>> regards,
>> Mick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.1.20

2018-02-12 Thread Nate McCall
> I propose the following artifacts for release as 2.1.20.
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.11.2

2018-02-12 Thread Nate McCall
> I propose the following artifacts for release as 3.11.2.
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.0.16

2018-02-12 Thread Nate McCall
> I propose the following artifacts for release as 3.0.16.
>

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.12

2018-02-12 Thread Nate McCall
> I propose the following artifacts for release as 2.2.12.

+1

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: How to fetch replication factor of a given keyspace

2017-12-20 Thread Nate McCall
I think you want:
Schema.instance.getKeyspaceMetadata

There is a ReplicationParams nested under there which should have
everything you need fully populated.

On Thu, Dec 21, 2017 at 2:02 PM, Tyagi, Preetika
 wrote:
> Hi,
>
> If I need to get the replication factor of a given keyspace in nodetool 
> commands (e.g. status), how can I do that? I'm trying to figure it out for a 
> JIRA item I'm working on.
>
> I tried using the below:
> Keyspace keyspace = Keyspace.open(keyspaceName);
> Int rf = keyspace.getReplicationStrategy().getReplicationFactor()
>
> However, it runs into some issues since internally something doesn't get 
> initialized while looking up keyspaces/metatadata.
>
> Any ideas on how I can approach it differently?
>
> Thanks,
> Preetika
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: duration based config settings

2017-12-04 Thread Nate McCall
> I'd be in favour of never retiring the _ms format though - it's almost
> free, there's no backward compatibility problems, and it's fairly intuitive
> so long as we're consistent about it.
>

Agreed on this point. Overall, this will be excellent for usability.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: custom validation before replication

2017-11-16 Thread Nate McCall
On Fri, Nov 17, 2017 at 9:11 AM, Abdelkrim Fitouri  wrote:
> Trigger does not resolve my problem because it is not a format validation
> issue but an integrity constraint ...
>
> My purpose is to check data integrity before replication, by returning an
> error and killing the service, so i am killing the node that is supposed to
> replicate data after a write action ...

I'm a little confused. Can you provide some specific examples of your
requirements?

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.0.15

2017-10-02 Thread Nate McCall
+1

On Tue, Oct 3, 2017 at 6:18 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.15.
>
> sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.15-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1150/
>
> 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/RyuPpw
> [2]: (NEWS.txt) https://goo.gl/qxwUti
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: Expected release date for 3.11.1?

2017-09-28 Thread Nate McCall
Agree on waiting for SRP. And in general having the patience to put out
artifacts in which we have higher confidence.

Thanks for the effort Alexi.

On Sep 29, 2017 5:29 AM, "Michael Shuler"  wrote:

> I'm happy to include these for the quality. Let's draw the line in the
> sand for these remaining tickets, so we can get 3.0.15/3.11.1 out. A few
> more days is not a problem.
>
> I appreciate the update!
>
> --
> Michael
>
> On 09/28/2017 10:50 AM, Aleksey Yeshchenko wrote:
> > FWIW, none of the remaining issues are strictly speaking regressions
> from previous versions.
> >
> > So if we felt strongly about starting the vote right now, I wouldn’t
> object, and would vote +1 - there is a lot of fixes accumulated there
> already.
> >
> > But all I need is a few days here, assuming review is done quickly, and
> we’ll be able to include some reasonably major fixes to long-lasting issues
> for the price of a few days’s delay (admittedly only CASSANDRA-13595 really
> qualifies).
> >
> > I’m aiming for end of this week/mid next week completion of the
> remaining tickets. If we can wait that long, great. If we feel an urge to
> go ahead now, then it’ll have to be 3.0.16/3.11.2 for fully working short
> read protection.
> >
> > —
> > AY
> >
> > On 28 September 2017 at 00:04:13, Michael Shuler (mich...@pbandjelly.org)
> wrote:
> >
> > On 09/27/2017 02:40 PM, Vincent Lee wrote:
> >> Anyone has an approximate date when 3.11.1 will be released?
> >> Interested to get fix for CASSANDRA-13752
> >
> > The issues currently in progress for 3.11.1 are:
> >
> > CASSANDRA-13595   Implement short read protection on partition
> boundaries
> > CASSANDRA-13808   Integer overflows with Amazon Elastic File System
> (EFS)
> > CASSANDRA-13911   IllegalStateException thrown by
> UPI.Serializer.hasNext()
> > for some SELECT queries
> > CASSANDRA-13913   Be more optimistic when fetching more rows for SRP
> >
> > After these are committed, I'll get the release rolled up. The devs
> > working on these issues project mid next week completion (maybe sooner -
> > now you're on the hook, Aleksey :). The above also affect 3.0.15, so
> > we'll also get that version released.
> >
> > If you're having problems now and want the latest artifacts that contain
> > CASSANDRA-13752 already, you can grab those from:
> >
> > https://builds.apache.org/view/A-D/view/Cassandra/job/
> Cassandra-3.11-artifacts/
> >
> > If you want to build your own packages, the README.md on the -builds
> > repo has the steps:
> >
> > https://github.com/apache/cassandra-builds
> >
> > --
> > Kind regards,
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Release Apache Cassandra 2.2.11

2017-09-28 Thread Nate McCall
+1

On Sep 29, 2017 7:41 AM, "Michael Shuler"  wrote:

> I propose the following artifacts for release as 2.2.11.
>
> sha1: c510e001481637e1f74d9ad176f8dc3ab7ebd1e3
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.2.11-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1149/org/apache/cassandra/apache-cassandra/2.2.11/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1149/
>
> The Debian and RPM 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/qTG7xU (also RPM file ownership fix)
> [2]: (NEWS.txt) https://goo.gl/ggdkLH
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>


Re: [VOTE] Release Apache Cassandra 2.1.19

2017-09-28 Thread Nate McCall
+1

On Sep 29, 2017 7:12 AM, "Michael Shuler"  wrote:

I propose the following artifacts for release as 2.1.19.

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

The Debian and RPM 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/1sZLdP (also RPM file ownership fix)
[2]: (NEWS.txt) https://goo.gl/YKEuRc

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org


Re: The future: Java 9 and the disappearance of CLASSPATH

2017-09-20 Thread Nate McCall
There are several other components that function similarly (compaction
strategies, snitches, UDFs, etc.). I don't see us doing anything
different without a compelling reason.

On Thu, Sep 21, 2017 at 3:06 AM, Russell Bateman  wrote:
> We're very new to Cassandra.
>
> We implement org.apache.index.Indexdropping a JAR containing our
> custom-index service into Cassandra's /lib/ subdirectory because this
> subdirectory is on the classpath. It's early days yet, but I thought I'd ask
> about the plans for Java 9 given that Jigsaw sort of closes the door on
> classpath (though it doesn't shut and lock it absolutely).
>
> What are Cassandra's plans in this direction? Do I have anything to fear
> long-term? Given the importance of Stratio's Lucene index extension, which
> uses this mechanism too, I'd guess no one wants to do anything that would
> destroy that either, but I need to ask.
>
> Many thanks,
>
> Russ
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Should we do some releases?

2017-09-19 Thread Nate McCall
It's been about 3 mos since our last set.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: State of Materialized Views

2017-07-24 Thread Nate McCall
>
> We're working on the following MV-related issues in the 4.0 time-frame:
> CASSANDRA-13162
> CASSANDRA-13547
Patch Available

> CASSANDRA-13127
Patch Available

> CASSANDRA-13409
Patch Available

> CASSANDRA-12952
Patch Available

> CASSANDRA-13069
> CASSANDRA-12888
>

Josh - want to make sure folks are not duplicating effort here, is the
status of the above on your radar? Regardless, I appreciate the
communication. Thanks for that!

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: State of Materialized Views

2017-07-20 Thread Nate McCall
>
>  so perhaps the real solution is we need to be more aggressive about 
> nominating and electing committers who are willing to spend some attention on 
> MVs.
>

I am very much +1 on this solution.

Huge thanks to Kurt for the excellent summarization and to Benjamin
and ZhaoYang for all their recent development efforts.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Cassandra dtest cloned to ASF

2017-07-12 Thread Nate McCall
https://github.com/apache/cassandra-dtest

History is intact, but I left all the branches as that all looked like
a bunch of one-off personal stuff.

DataStax folks - what do y'all want to do re: "repository has moved"
readme or similar?

Tracking this under:
https://issues.apache.org/jira/browse/CASSANDRA-13613

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 2.2.10

2017-06-21 Thread Nate McCall
+1

On Thu, Jun 22, 2017 at 8:20 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 2.2.10.
>
> sha1: 83f28ce3c4eeff75ce70855a56b6155047ce8e9a
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1147/org/apache/cassandra/apache-cassandra/2.2.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1147/
>
> The Debian and RPM 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/N2ZEkF
> [2]: (NEWS.txt) https://goo.gl/FAv57Z
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: AutoBoxing overhead in lambda expressions

2017-06-21 Thread Nate McCall
Hi Ameya,
Did you end up creating any issues for your findings?

On Mon, Jun 12, 2017 at 6:44 PM, Jeff Jirsa  wrote:
> Generally speaking,
>
> Patches that decrease boxing/unboxing overhead are great, and we've made a
> point of committing some of those in the past ( such as in CASSANDRA-12199
> and CASSANDRA-8019 ) , though there are also some examples where we've
> decided not to apply boxing changes to critical code paths that didn't have
> a meaningful performance impact.
>
> I would expect that if you refactor it in chunks - that is, break it down
> into a handful of patches, where each patch is contained to a specific
> subsystem (compaction, commitlog, repair, messaging, etc) so it could be
> reasonably reviewed - such refactoring would likely be appreciated,
> especially if it came with quantifiable performance increase (using
> something like cstar https://github.com/datastax/cstar_perf or stress runs
> or microbenchmarks or similar).
>
> - Jeff
>
>
> On Fri, Jun 9, 2017 at 10:50 AM, Ameya Sanjay Sanjay Ketkar <
> ketk...@oregonstate.edu> wrote:
>
>> Hello,
>>
>> I am  graduate researcher at Oregon State University, currently studying
>> lambda expressions in java open source project.
>> Using a generic Functional interface when a specialized primitive
>> functional interface can be used, is one the lambda smells I am focussing
>> on.
>> for instance  Function could be IntUnaryOperator.
>>
>> https://github.com/apache/cassandra/pull/116 > cassandra/pull/116>
>>
>> Is an instance of refactoring, of such lambda smell.
>> I would love to contribute to this project, by refactoring such lambda
>> smells.
>>
>> I am developing a tool to detect such opportunities.
>> But all the refactoring done are manual and all instances are checked and
>> verified by me manually, before creating a pull request.
>>
>> Regards,
>> Ameya Ketkar
>>
>> Graduate Research Assistant
>> Oregon State University

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [DISCUSS] Should we do a 2.2 release?

2017-06-20 Thread Nate McCall
> Should we also do a 2.1.18 release as a final cut and end commits to the
> cassandra-2.1 branch? I'm sorry I hadn't thought about this sooner.

Meh? There is nothing major in there. That said, if we want to just
say "that's it for 2.1", I guess we could do another.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



[DISCUSS] Should we do a 2.2 release?

2017-06-20 Thread Nate McCall
Since we have the others going out and we do have some bugfixes there.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.11.0

2017-06-19 Thread Nate McCall
+1

On Tue, Jun 20, 2017 at 11:10 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.11.0.
>
> sha1: 88dee7e9d515ad94ecf8f2309f1e6138ec79e1a2
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.0-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1145/org/apache/cassandra/apache-cassandra/3.11.0/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1145/
>
> The Debian and RPM 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/x6SzsQ
> [2]: (NEWS.txt) https://goo.gl/qxG8MQ
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



Re: [VOTE] Release Apache Cassandra 3.0.14

2017-06-19 Thread Nate McCall
+1

On Tue, Jun 20, 2017 at 8:37 AM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.14.
>
> sha1: f3e38cb638113c2a23855a104d6082da5bc10ddb
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.14-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1143/org/apache/cassandra/apache-cassandra/3.0.14/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1143/
>
> The Debian and RPM 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/VdkHQH
> [2]: (NEWS.txt) https://goo.gl/Qkknas
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



All clear to import dtest

2017-06-15 Thread Nate McCall
We got through all the legal shenanigans necessary to import dtest
into the project:
https://issues.apache.org/jira/browse/CASSANDRA-13584

This is just a heads up that I have created CASSANDRA-13613 for
tracking the actual import and will be adding some sub-tasks next week
for the actual migration into ASF infra and housekeeping around such.

To sum up previous mail list conversations [0], we will be creating a
new "cassandra-dtest" git repo at the ASF with the same committer list
as the project.

Anybody have any remaining issues or concerns here?

Thanks,
-Nate

[0] 
https://lists.apache.org/thread.html/840fd900fb7f6568bfa008d122d4375b708c1f7f1b5929018118d5d5@%3Cdev.cassandra.apache.org%3E

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org



  1   2   3   >