Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Vinay Chella]

Congratulations Francisco !!

Thanks,
Vinay Chella


On Tue, Nov 28, 2023 at 11:24 AM Mick Semb Wever  wrote:

>
>
> On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi  wrote:
>
>> The PMC members are pleased to announce that Francisco Guerrero Hernandez
>> has accepted
>> the invitation to become committer today.
>>
>> Congratulations and welcome!
>
>
>
> Congrats !!
>

Re: [VOTE] Accept java-driver

[Vinay Chella]

+1 (nb)

Thanks,
Vinay Chella


On Tue, Oct 3, 2023 at 10:44 AM Yifan Cai  wrote:

> +1
> --
> *From:* David Capwell 
> *Sent:* Tuesday, October 3, 2023 9:45:02 AM
> *To:* dev 
> *Subject:* Re: [VOTE] Accept java-driver
>
> +1
>
> On Oct 3, 2023, at 8:32 AM, Chris Lohfink  wrote:
>
> +1
>
> On Tue, Oct 3, 2023 at 10:30 AM Jeff Jirsa  wrote:
>
> +1
>
>
> On Mon, Oct 2, 2023 at 9:53 PM Mick Semb Wever  wrote:
>
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF.  This does not require acknowledgement
> before the vote.
>
> Once the vote passes, and the SGA has been filed by the ASF Secretary, we
> will request ASF Infra to move the datastax/java-driver as-is to
> apache/java-driver
>
> This means all branches and tags, with all their history, will be kept.  A
> cleaning effort has already cleaned up anything deemed not needed.
>
> Background for the donation is found in CEP-8:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>
> PMC members, please take note of (and check) the IP Clearance requirements
> when voting.
>
> The vote will be open for 72 hours (or longer). Votes by PMC members are
> considered binding. A vote passes if there are at least three binding +1s
> and no -1's.
>
> regards,
> Mick
>
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Vinay Chella]

Well deserved one, Congratulations, Patrick.

On Fri, Feb 3, 2023 at 4:01 AM Josh McKenzie  wrote:

> Congrats Patrick! Well deserved.
>
> On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:
>
> Congrats, Patrick... much deserved!
>
> On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker 
> wrote:
>
> Congrats!
>
> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>
> --

Thanks,
Vinay Chella

Re: Welcome Sumanth Pasupuleti as Apache Cassandra Committer

[Vinay Chella]

Congratulations Sumanth!! Well deserved.


Thanks,
Vinay Chella


On Fri, Nov 5, 2021 at 11:58 AM J. D. Jordan 
wrote:

> Congrats!
>
> > On Nov 5, 2021, at 1:52 PM, Yifan Cai  wrote:
> >
> > Congratulations Sumanth!
> >
> > - Yifan
> >
> >> On Nov 5, 2021, at 11:37 AM, Patrick McFadin 
> wrote:
> >>
> >> Great to see this. Congrats Sumanth!
> >>
> >>>> On Fri, Nov 5, 2021 at 11:34 AM Brandon Williams 
> wrote:
> >>>
> >>> Congratulations Sumanth!
> >>>
> >>>> On Fri, Nov 5, 2021 at 1:17 PM Oleksandr Petrov
> >>>>  wrote:
> >>>>
> >>>> The PMC members are pleased to announce that Sumanth Pasupuleti has
> >>>> recently accepted the invitation to become committer.
> >>>>
> >>>> Sumanth, thank you for all your contributions to the project over the
> >>> years.
> >>>>
> >>>> Congratulations and welcome!
> >>>>
> >>>> The Apache Cassandra PMC members
> >>>
> >>> -
> >>> 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 3.0.25

[Vinay Chella]

+1, for CASSANDRA-16735.
Thanks,
Vinay


On Sun, Jul 25, 2021 at 11:00 AM Scott Andreas  wrote:

> +1nb, primarily for CASSANDRA-16735.
>
> > On Jul 25, 2021, at 10:40 AM, Brandon Williams  wrote:
> >
> > I am proposing the test build of Cassandra 3.0.25 for release.
> >
> > sha1: 06235e93e16d1f483a3b03ba02f8fb29e33305fa
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.25-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1245/org/apache/cassandra/cassandra-all/3.0.25/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/3.0.25/
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no -1's.
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.25-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.25-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: Welcome Dinesh Joshi as Cassandra PMC member

[Vinay Chella]

Congratulations Dinesh.

On Wed, Jun 2, 2021 at 9:18 AM Brandon Williams  wrote:

> Congrats, Dinesh!
>
> On Wed, Jun 2, 2021 at 11:16 AM Benjamin Lerer  wrote:
> >
> >  The PMC's members are pleased to announce that Dinesh Joshi has accepted
> > the invitation to become a PMC member.
> >
> > Thanks a lot, Dinesh, for everything you have done for the project all
> > these years.
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Regards,
Vinay Chella
Engineering Manager, Data Abstractions Platform Team

pronouns: he/him

Re: Sidecar meeting notes from 2020-03-10

[Vinay Chella]

Sidecar discussions so far have been on the dev list, CEP-1[1], JIRA[2],
and seem to be working at its current volume. All the work is currently
tracked under 'sidecar' component in Apache Cassandra jira[2].

So with this context and the low volume, I am +1 on Jon's approach.

[1]: CEP-1 -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
[2]: Sidecar componet -
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20component%20%3D%20Sidecar


Thanks,
Vinay


On Fri, Mar 13, 2020 at 2:12 PM Brandon Williams  wrote:

> I agree with Jon, and dev goes directly to my inbox.
>
> On Fri, Mar 13, 2020 at 4:07 PM Jon Haddad  wrote:
> >
> > I think we're low volume enough across the board that we can continue
> > sidecar discussion on dev, and if we start to see too much noise, split
> > things up.
> >
> > On Fri, Mar 13, 2020 at 1:46 PM Patrick McFadin 
> wrote:
> >
> > > I think Vinay just pinged everyone working on the project, but to
> Josh's
> > > point. is this even traffic for the cassandra dev ml? Or does a new one
> > > need to be created?
> > >
> > > On Fri, Mar 13, 2020 at 1:29 PM Nate McCall 
> wrote:
> > >
> > > > Where was this announced? I didnt hear anything about it (it's
> possible I
> > > > missed an email but don't see anything).
> > > >
> > > > On Sat, Mar 14, 2020 at 8:26 AM Patrick McFadin 
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > This week, a small group of us met on Zoom on how to contribute
> best to
> > > > the
> > > > > sidecar project (CEP-1). DataStax is open sourcing several
> components,
> > > > one
> > > > > of which includes a management sidecar. This was open conversation
> > > about
> > > > > what's being released and how best to participate in CEP-1 in the
> > > future.
> > > > > Thanks to Vinay Chella for organizing such a diverse group!
> > > > >
> > > > > As a matter of tracking any discussions, notes were added to CEP-1
> in
> > > the
> > > > > Apache cwiki.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-1+Online+meeting+2020-03-10
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Patrick
> > > > >
> > > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

[Vinay Chella]

+1

-Vinay Chella

On Sat, Nov 2, 2019 at 5:09 PM Jeff Carpenter 
wrote:

> FYI the audio of the session with Ben Bromhead / Scott Andreas is
> available:
>
> https://feathercast.apache.org/2019/09/12/apache-cassandra-community-health-ben-bromhead-scott-andreas/
> <
> https://feathercast.apache.org/2019/09/12/apache-cassandra-community-health-ben-bromhead-scott-andreas/
> >
>
> Jeff
>
> > On Nov 1, 2019, at 11:19 AM, Scott Andreas  wrote:
> >
> > Hi Michael,
> >
> > Unfortunately not; ASF recorded the keynotes but video/streaming
> facilities weren't available for the individual tracks.
> >
> > A copy of the slides are uploaded here:
> >
> https://github.com/ngcc/ngcc2019/blob/master/Committing%20to%20our%20Users%20-%20Product%20and%20Release%20Management%20in%20Apache%20Cassandra.pdf
> >
> > I also have a version with messy presenters' notes. I'll clean these up
> and put them on Confluence. The outline and notes cover all of the
> presentation's content in detail so the delta between "being there" and
> "reading the notes" should be minimal.
> >
> > 
> > From: Michael Shuler  on behalf of Michael
> Shuler 
> > Sent: Friday, November 1, 2019 9:09 AM
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation
> >
> > +1
> >
> > Scott, was your NGCC talk videoed and uploaded anywhere? I would love to
> > watch, since I missed the event.
> >
> > Kind regards,
> > Michael
> >
> > On 11/1/19 9:07 AM, Scott Andreas wrote:
> >> +1 nb
> >>
> >>> On Nov 1, 2019, at 5:36 AM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >>>
> >>> +1
> >>>
> >>> On 01/11/2019, 12:33, "Mick Semb Wever"  wrote:
> >>>
> >>>Please vote on accepting the Cassandra Enhancement Proposal (CEP)
> document as a starting point and guide towards improving collaboration on,
> and success of, new features and significant improvements. In combination
> with the recently accepted Cassandra Release Lifecycle documentation this
> should help us moving forward as a project and community.
> >>>
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> >>>
> >>>Past discussions on the document/process have been touched on in a
> number of threads in the dev ML.  The most recent thread was
> https://lists.apache.org/thread.html/b5d1b1ca99324f84e4a40b9cba879e8f858f5f6e18447775fcf32155@%3Cdev.cassandra.apache.org%3E
> >>>
> >>>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
> >>
> >
> > -
> > 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
> >
>
> --

Thanks,
Vinay Chella

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

[Vinay Chella]

Update on test runs:

Ran all tests several times, opened followup JIRAs to fix
DatabaseDescriptorRefTest test(
https://issues.apache.org/jira/browse/CASSANDRA-15381) and flaky
testIdleDisconnect
test (https://issues.apache.org/jira/browse/CASSANDRA-15382).

On a different note, I see more than 500 upgrade tests are failing (
https://circleci.com/gh/vinaykumarchella/cassandra/530), assuming it is
something flaky, will investigate more on these and update here if I find
anything.

Thanks,
Vinay Chella


On Fri, Oct 25, 2019 at 2:10 PM Jon Meredith  wrote:

> The DatabaseDescriptorRefTest breakage is on me - there's a fix included as
> part of CASSANDRA-15371.  Sorry for breaking it -  it's benign, just forgot
> to add to the new DistributedTestSnitch to the validClasses list.
>
> On Fri, Oct 25, 2019 at 11:06 AM Vinay Chella 
> wrote:
>
> > Unit test "*testDatabaseDescriptorRef -
> > org.apache.cassandra.config.DatabaseDescriptorRefTest*" is consistently
> > failing across different test suites -
> >
> https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37
> >
> > Java8 tests:
> > https://circleci.com/workflow-run/b74a1510-9ce5-4d09-a448-0f9cb2a23350
> > Java11
> > <
> https://circleci.com/workflow-run/b74a1510-9ce5-4d09-a448-0f9cb2a23350Java11
> >
> > tests:
> > https://circleci.com/workflow-run/9b23de5a-3c5b-41b4-88c4-3495b453eb53
> >
> > <
> >
> https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37
> > >Following
> > tests seems to be flaky, I will be rerunning to confirm and open JIRAs as
> > needed.
> >
> > 1. testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest
> > 2. test_drop_with_stopped_build -
> > materialized_views_test.TestMaterializedViews
> > 3. test_remote_query - cql_test.TestCQLSlowQuery
> >
> > Thanks,
> > Vinay Chella
> >
> >
> > On Fri, Oct 25, 2019 at 9:27 AM Blake Eggleston
> >  wrote:
> >
> > > +1
> > >
> > > > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa  wrote:
> > > >
> > > > +1
> > > >
> > > >
> > > > On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad 
> wrote:
> > > >
> > > >> +1
> > > >>
> > > >> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe 
> > > wrote:
> > > >>
> > > >>> +1
> > > >>>
> > > >>>> On 24 Oct 2019, at 18:26, Michael Shuler 
> > > >> wrote:
> > > >>>>
> > > >>>> I propose the following artifacts for release as 4.0-alpha2.
> > > >>>>
> > > >>>> sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> > > >>>> Git:
> > > >>>
> > > >>
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> > > >>>> Artifacts:
> > > >>>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
> > > >>>> Staging repository:
> > > >>>
> > > >>
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/
> > > >>>>
> > > >>>> 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/4.0-alpha2-tentative
> > > >>>> [2]: NEWS.txt:
> > > >>>
> > > >>
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-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
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

[Vinay Chella]

Unit test "*testDatabaseDescriptorRef -
org.apache.cassandra.config.DatabaseDescriptorRefTest*" is consistently
failing across different test suites -
https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37

Java8 tests:
https://circleci.com/workflow-run/b74a1510-9ce5-4d09-a448-0f9cb2a23350
Java11 tests:
https://circleci.com/workflow-run/9b23de5a-3c5b-41b4-88c4-3495b453eb53

<https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37>Following
tests seems to be flaky, I will be rerunning to confirm and open JIRAs as
needed.

1. testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest
2. test_drop_with_stopped_build -
materialized_views_test.TestMaterializedViews
3. test_remote_query - cql_test.TestCQLSlowQuery

Thanks,
Vinay Chella


On Fri, Oct 25, 2019 at 9:27 AM Blake Eggleston
 wrote:

> +1
>
> > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa  wrote:
> >
> > +1
> >
> >
> > On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad  wrote:
> >
> >> +1
> >>
> >> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe 
> wrote:
> >>
> >>> +1
> >>>
> >>>> On 24 Oct 2019, at 18:26, Michael Shuler 
> >> wrote:
> >>>>
> >>>> I propose the following artifacts for release as 4.0-alpha2.
> >>>>
> >>>> sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> >>>> Git:
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> >>>> Artifacts:
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
> >>>> Staging repository:
> >>>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/
> >>>>
> >>>> 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/4.0-alpha2-tentative
> >>>> [2]: NEWS.txt:
> >>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-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
> >>>
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Contributing cassandra-diff

[Vinay Chella]

This is a great addition to our Cassandra validation framework/tools. I can
see many teams in the community get benefited from tooling like this.

I like the idea of the generic repo (repos/asf/cassandra-contrib.git
or *whatever
the name is*) for tools like this, for the following 2 main reasons.

   1. Easily accessible/ reachable/ searchable
   2. Welcomes community in Cassandra ecosystem to contribute more easily



Thanks,
Vinay Chella


On Wed, Aug 21, 2019 at 11:39 PM Marcus Eriksson  wrote:

> Hi, we are about to open source our tooling for comparing two cassandra
> clusters and want to get some feedback where to push it. I think the
> options are: (name bike-shedding welcome)
>
> 1. create repos/asf/cassandra-diff.git
> 2. create a generic repos/asf/cassandra-contrib.git where we can add more
> contributed tools in the future
>
> Temporary location: https://github.com/krummas/cassandra-diff
>
> Cassandra-diff is a spark job that compares the data in two clusters - it
> pages through all partitions and reads all rows for those partitions in
> both clusters to make sure they are identical. Based on the configuration
> variable “reverse_read_probability” the rows are either read forward or in
> reverse order.
>
> Our main use case for cassandra-diff has been to set up two identical
> clusters, transfer a snapshot from the cluster we want to test to these
> clusters and upgrade one side. When that is done we run this tool to make
> sure that 2.1 and 3.0 gives the same results. A few examples of the bugs we
> have found using this tool:
>
> * CASSANDRA-14823: Legacy sstables with range tombstones spanning multiple
> index blocks create invalid bound sequences on 3.0+
> * CASSANDRA-14803: Rows that cross index block boundaries can cause
> incomplete reverse reads in some cases
> * CASSANDRA-15178: Skipping illegal legacy cells can break reverse
> iteration of indexed partitions
>
> /Marcus
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Unit test fixes

[Vinay Chella]

I can help reviewing these tickets. Thank for bringing up.

On Thu, May 2, 2019 at 9:48 AM Per Otterström 
wrote:

> Hi.
>
> The unit tests have been failing/glitching for a while. There are a couple
> of patches available that should improve the situation. Would be great if
> we could get a couple of reviewers/committers to have a look at them:
> https://issues.apache.org/jira/browse/CASSANDRA-15088
> https://issues.apache.org/jira/browse/CASSANDRA-15105
>
> Thanks!
>
> /pelle
>
>
> --

Thanks,
Vinay Chella

Re: CASSANDRA-14482

[Vinay Chella]

We have been using Zstd compressor across different products/services here
and have seen significant improvements, getting this in 4.0 would be a big
win.

+1

Thanks,
Vinay Chella


On Fri, Feb 15, 2019 at 10:19 AM Jeff Jirsa  wrote:

> +1
>
> --
> Jeff Jirsa
>
>
> > On Feb 15, 2019, at 9:35 AM, Jonathan Ellis  wrote:
> >
> > IMO "add a new compression class that has demonstrable benefits to Sushma
> > and Joseph" is sufficiently noninvasive that we should allow it into 4.0.
> >
> > On Fri, Feb 15, 2019 at 10:48 AM Dinesh Joshi
> >  wrote:
> >
> >> Hey folks,
> >>
> >> Just wanted to get a pulse on whether we can proceed with ZStd support.
> >> The consensus on the ticket was that it’s a very valuable addition
> without
> >> any risk of destabilizing 4.0. It’s ready to go if there aren’t any
> >> objections.
> >>
> >> Dinesh
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> >
> > --
> > 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
>
>

Re: [VOTE] Release Apache Cassandra 3.11.4

[Vinay Chella]

Hi Ariel,

test_simple_bootstrap_mixed_versions issue is related to CASSANDRA-13004
<https://issues.apache.org/jira/browse/CASSANDRA-13004>, which introduced
"cassandra.force_3_0_protocol_version" for schema migrations during
upgrades from 3.0.14 upwards. This flag is missing in
`test_simple_bootstrap_mixed_versions` upgrade test while we are
adding/bootstrapping 3.11.4 node to an existing 3.5 version of C* node.
This resulted in `ks` keyspace schema/data not being bootstrapped to the
new node.

I debugged and confirmed that MigrationManager::is30Compatible
<https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185>
is returning false which is forcing MigrationManager::shouldPullSchemaFrom
<https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177>
to return false as well.

*From debug logs:*
DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 -
Not pulling schema because versions match or shouldPullSchemaFrom returned
false

Here is the updated dtest branch:
https://github.com/vinaykumarchella/cassandra-dtest/tree/fix_failing_upgradetest

dtests on CircleCI: https://circleci.com/gh/vinaykumarchella/cassandra/345

P.S: While MigrationManager
<https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185>
confirms that schema migrations from pre 3.11 are not allowed without
`cassandra.force_3_0_protocol_version` option, release notes for 3.11 are
confusing - docs
<https://github.com/apache/cassandra/blob/cassandra-3.11/NEWS.txt#L173-L174>

Let me know if this looks good to you, I will send a patch to
cassandra-dtest



Thanks,
Vinay Chella


On Wed, Feb 6, 2019 at 8:07 PM Vinay Chella  wrote:

> Hi Ariel,
>
> Sure, I am volunteering to debug this. Will update the progress here.
>
> Thanks,
> Vinay
>
>
> On Wed, Feb 6, 2019 at 1:41 PM Ariel Weisberg  wrote:
>
>> Hi,
>>
>> It fails consistently. I don't know why the data is not evenly
>> distributed. Can someone volunteer to debug this failing test to make sure
>> there isn't an issue with bootstrap in 3.11?
>>
>> https://circleci.com/gh/aweisberg/cassandra/2593
>>
>> Thanks,
>> Ariel
>> On Wed, Feb 6, 2019, at 3:11 PM, Ariel Weisberg wrote:
>> > Hi,
>> >
>> > -0
>> >
>> > bootstrap_upgrade_test.py test_simple_bootstrap_mixed_versions fails
>> > because it doesn't see the expected on disk size within 30% of the
>> > expected value. It's bootstrapping a new version node and runs cleanup
>> > on the existing node. If the data were evenly distributed the on disk
>> > size should be similar.
>> >
>> > https://circleci.com/gh/aweisberg/cassandra/2591#tests/containers/40
>> >
>> > I don't have time to see if this reproduces manually. I kicked off the
>> > tests again to see if reproduces.
>> > https://circleci.com/gh/aweisberg/cassandra/2593
>> >
>> > Ariel
>> >
>> > On Wed, Feb 6, 2019, at 5:02 AM, Marcus Eriksson wrote:
>> > > +1
>> > >
>> > > Den ons 6 feb. 2019 kl 10:52 skrev Benedict Elliott Smith <
>> > > bened...@apache.org>:
>> > >
>> > > > +1
>> > > >
>> > > > > On 6 Feb 2019, at 08:01, Tommy Stendahl <
>> tommy.stend...@ericsson.com>
>> > > > wrote:
>> > > > >
>> > > > > +1 (non-binding)
>> > > > >
>> > > > > /Tommy
>> > > > >
>> > > > > On lör, 2019-02-02 at 18:31 -0600, 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
>> > > > &

Re: [VOTE] Release Apache Cassandra 3.11.4

[Vinay Chella]

Hi Ariel,

Sure, I am volunteering to debug this. Will update the progress here.

Thanks,
Vinay


On Wed, Feb 6, 2019 at 1:41 PM Ariel Weisberg  wrote:

> Hi,
>
> It fails consistently. I don't know why the data is not evenly
> distributed. Can someone volunteer to debug this failing test to make sure
> there isn't an issue with bootstrap in 3.11?
>
> https://circleci.com/gh/aweisberg/cassandra/2593
>
> Thanks,
> Ariel
> On Wed, Feb 6, 2019, at 3:11 PM, Ariel Weisberg wrote:
> > Hi,
> >
> > -0
> >
> > bootstrap_upgrade_test.py test_simple_bootstrap_mixed_versions fails
> > because it doesn't see the expected on disk size within 30% of the
> > expected value. It's bootstrapping a new version node and runs cleanup
> > on the existing node. If the data were evenly distributed the on disk
> > size should be similar.
> >
> > https://circleci.com/gh/aweisberg/cassandra/2591#tests/containers/40
> >
> > I don't have time to see if this reproduces manually. I kicked off the
> > tests again to see if reproduces.
> > https://circleci.com/gh/aweisberg/cassandra/2593
> >
> > Ariel
> >
> > On Wed, Feb 6, 2019, at 5:02 AM, Marcus Eriksson wrote:
> > > +1
> > >
> > > Den ons 6 feb. 2019 kl 10:52 skrev Benedict Elliott Smith <
> > > bened...@apache.org>:
> > >
> > > > +1
> > > >
> > > > > On 6 Feb 2019, at 08:01, Tommy Stendahl <
> tommy.stend...@ericsson.com>
> > > > wrote:
> > > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > /Tommy
> > > > >
> > > > > On lör, 2019-02-02 at 18:31 -0600, 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
> > > > >
> > > > >
> > > >
> > > >
> > > > -
> > > > 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: Request to review feature-freeze proposed tickets

[Vinay Chella]

Thanks for the responses, I think the summary so far is: committers and
reviewers are positive on reviewing the community tickets mentioned in this
email except for a couple of them that Joshua mentioned, with the caution of
not disrupting the current testing efforts.

Thank you, Ariel, for understanding the concerns and helping with reviews.

Thank you, Jon, for picking up CASSANDRA-14303.

@Joshua, if you can comment on the tickets that concern you that would be
helpful, and I will take them off from my list to track for 4.0.

I would like to help drive these tickets to their completion in 4.0 (either
deferred or committed) unless someone has concerns.

Thanks,
Vinay


On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli 
wrote:

> We already should be taking correctness and perf changes and I am +1 on
> taking operational tickets. Agree with Josh that the only exception will be
> if it causes disruption in testing.
>
> I think as a project we should be more open to operational issues as
> having a fork is not ideal.
>
> Regarding time it is taking to review things, I think we should not start
> doing big features post 4.0 but instead review all possible JIRAs first.
> Once we are out of this debt, we should define a  process so that we don’t
> end up in this state. I think this item deserves a separate thread which we
> can start closer to 4.0 being cut.
>
> > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie 
> wrote:
> >
> > Strong +1 on prioritizing community engagement 1st and caution second,
> > though still prioritizing it. I think the right metric for us to
> calibrate
> > around is that "disrupt in-flight testing cycles", i.e. if changes cause
> > significant rework for people that have already begun testing 4.0,
> probably
> > ok to review and get it in but target 4.0.x.
> >
> > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >>> I assume it's obvious to everyone that this should be taken on a
> >>> case-by-case basis. There's at least 2 that were in that list (one of
> >> which
> >>> Marcus bumped off PA) that are potentially big and hairy changes that
> >> would
> >>> disrupt in-flight testing cycles.
> >>
> >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> >>
> >>
> >> -
> >> 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
>
>

Request to review feature-freeze proposed tickets

[Vinay Chella]

Hi,

We still have 15 Patch Available/ open tickets which were requested for
reviews before the Sep 1, 2018 freeze. I am starting this email thread to
resurface and request a review of community tickets as most of these
tickets address vital correctness, performance, and usability bugs that
help avoid critical production issues. I tried to provide context on why we
feel these tickets are important to get into 4.0. If you would like to
discuss the technical details of a particular ticket, let's try to do that
in JIRA.

CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
failures. (Correctness bug, Production impact, Ready to Commit)

CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
breaking latencies, Production impact, Review in progress)

CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
cannot be rebuilt after node failure due to 3.0’s introduction of the
system_auth keyspace with rf of 1. These tickets both fix the regression
introduced in 3.0 by letting operators configure rf=3 and prevent future
outages (Usability bug, Production impact, Patch Available).

CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We believe
this may also impact 3.0 (Title says it all, Production impact, Patch
Available)

CASSANDRA-10023: It is impossible to accurately determine local read/write
calls on C*. This patch allows users to detect when they are choosing
incorrect coordinators. (Usability bug (troubleshoot), Review in progress)

CASSANDRA-10789: There is no way to safely stop bad clients bringing down
C* nodes. This patch would give operators a very important tool to use
during production incidents to mitigate impact. (Usability bug, Production
Impact (recovery), Patch Available)

CASSANDRA-13010: No visibility into which disk is being compacted to.
(Usability bug, Production Impact (troubleshoot), Review in progress)

CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title says
it all, Production Impact, Patch InProgress/ Awaiting Feedback)

CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
datacenters (Usability bug, Production impact, Patch available)

CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be nice
to get it in 4.0. (Production Impact (recovery), Patch Available)

CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
operators. (Cleanup, Patch Available)

CASSANDRA-14309: Hint window persistence across the record. This way hints
that are accumulated over a period of time when nodes are creating are less
likely to take down the entire cluster. (Potential Production Impact, Patch
Available)

CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch Available)

CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need this
to be able to do basic things like repair. The patch needs some rework
after transient replication (Production impact, needs contributor time)

URL for all the tickets: JIRA
<https://issues.apache.org/jira/issues/?filter=12345151=project%20%3D%20CASSANDRA%20AND%20key%20in%20(CASSANDRA-14525%2C%20CASSANDRA-13010%2C%20CASSANDRA-10023%2C%20CASSANDRA-10789%2C%20CASSANDRA-13841%2C%20CASSANDRA-14309%2C%20CASSANDRA-12783%2C%20CASSANDRA-14291%2C%20CASSANDRA-10540%2C%20CASSANDRA-14303%2C%20CASSANDRA-14557%2C%20CASSANDRA-14459%2C%20CASSANDRA-9452%2C%20CASSANDRA-14096%2C%20CASSANDRA-14319)%20ORDER%20BY%20assignee%20ASC%2C%20reporter%20ASC>


Let me know.
Thanks,
Vinay Chella

Re: [VOTE] Development Approach for Apache Cassandra Management process

[Vinay Chella]

+1 for option b, considering the advantages mentioned in dev email thread
that Sankalp linked.

~Vinay


On Wed, Sep 12, 2018 at 10:36 AM Dinesh Joshi
 wrote:

> +1 for piecemeal (option b)
>
> Dinesh
>
> > On Sep 12, 2018, at 8:18 AM, sankalp kohli 
> wrote:
> >
> > Hi,
> >Community has been discussing about Apache Cassandra Management
> process
> > since April and we had lot of discussion about which approach to take to
> > get started. Several contributors have been interested in doing this and
> we
> > need to make a decision of which approach to take.
> >
> > The current approaches being evaluated are
> > a. Donate an existing project to Apache Cassandra like Reaper. If this
> > option is selected, we will evaluate various projects and see which one
> > fits best.
> > b. Take a piecemeal approach and use the features from different OSS
> > projects and build a new project.
> >
> > Available options to vote
> > a. +1 to use existing project.
> > b. +1 to take piecemeal approach
> > c  -1 to both
> > d +0 I dont mind either option
> >
> > You can also just type a,b,c,d as well to chose an option.
> >
> > Dev threads with discussions
> >
> >
> https://lists.apache.org/thread.html/4eace8cb258aab83fc3a220ff2203a281ea59f4d6557ebeb1af7b7f1@%3Cdev.cassandra.apache.org%3E
> >
> >
> https://lists.apache.org/thread.html/4a7e608c46aa2256e8bcb696104a4e6d6aaa1f302834d211018ec96e@%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: Proposing an Apache Cassandra Management process

[Vinay Chella]

 > I think we should accept the reaper project as is and make that
cassandra management process 1.0, then integrate the Netflix scheduler (and
other new features) into that.
Integrating Netflix scheduler into reaper is mostly refactoring reaper code
since they are different architectures.

> Reaper would bring a prod user base that would realistically take 2-3
years to build up with a new project.
IMO, it is great if we have that, but this should not be the deciding factor

> As an operator, switching to a cassandra management process that’s
basically a re-brand of an existing and commonly used management process
isn’t super risky. Asking operators to switch to a new process is a much
harder sell.
Reaper is far away from becoming a "cassandra management process", I
understand it does its job in doing repairs and snapshots (and other things
if I missed any), but as a Cassandra mangement sidecar process,
responsibilities of it are far beyond those just mentioned. All the design
goals mentioned in this thread from Joey (pluggable execution engine,
backup, restore, ring health detection, sstable upgrade, rolling restarts,
topology-aware maintenance, replacements of entire fleet without
compromising availability etc.,) are critical operations of a "cassandra
management process" that are hard to add on to a system which is not
architected for that. It basically makes total rework/refactor of reaper,
if we were to go down that path. And don't get me wrong, Reaper is a great
repair tool available for C* community, with a great visualization which
makes it easy to use.

We prefer what Jeff proposes, starting with something small and isolated
and layering the best of all sidecars incrementally on top.

--Vinay Chella


On Fri, Sep 7, 2018 at 6:11 PM Jeff Jirsa  wrote:

> I’d also like to see the end state you describe: reaper UI wrapping the
> Netflix management process with pluggable scheduling (either as is with
> reaper now, or using the Netflix scheduler), but I don’t think that means
> we need to start with reaper - if personally prefer the opposite direction,
> starting with something small and isolated and layering on top.
>
> --
> Jeff Jirsa
>
>
> > On Sep 7, 2018, at 5:42 PM, Blake Eggleston 
> wrote:
> >
> > I think we should accept the reaper project as is and make that
> cassandra management process 1.0, then integrate the netflix scheduler (and
> other new features) into that.
> >
> > The ultimate goal would be for the netflix scheduler to become the
> default repair scheduler, but I think using reaper as the starting point
> makes it easier to get there.
> >
> > Reaper would bring a prod user base that would realistically take 2-3
> years to build up with a new project. As an operator, switching to a
> cassandra management process that’s basically a re-brand of an existing and
> commonly used management process isn’t super risky. Asking operators to
> switch to a new process is a much harder sell.
> >
> > On September 7, 2018 at 4:17:10 PM, Jeff Jirsa (jji...@gmail.com) wrote:
> >
> > How can we continue moving this forward?
> >
> > Mick/Jon/TLP folks, is there a path here where we commit the
> > Netflix-provided management process, and you augment Reaper to work with
> it?
> > Is there a way we can make a larger umbrella that's modular that can
> > support either/both?
> > Does anyone believe there's a clear, objective argument that one is
> > strictly better than the other? I haven't seen one.
> >
> >
> >
> > On Mon, Aug 20, 2018 at 4:14 PM Roopa Tangirala
> >  wrote:
> >
> >> +1 to everything that Joey articulated with emphasis on the fact that
> >> contributions should be evaluated based on the merit of code and their
> >> value add to the whole offering. I hope it does not matter whether
> that
> >> contribution comes from PMC member or a person who is not a committer.
> I
> >> would like the process to be such that it encourages the new members to
> be
> >> a part of the community and not shy away from contributing to the code
> >> assuming their contributions are valued differently than committers or
> PMC
> >> members. It would be sad to see the contributions decrease if we go
> down
> >> that path.
> >>
> >> *Regards,*
> >>
> >> *Roopa Tangirala*
> >>
> >> Engineering Manager CDE
> >>
> >> *(408) 438-3156 - mobile*
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Aug 20, 2018 at 2:58 PM Joseph Lynch 
> >> wrote:
> >>
> >>>> We are looking to contribute Reaper to the Cassandra project.
> >>>>

Re: Reaper as cassandra-admin

[Vinay Chella]

> I haven’t settled on a position yet (will have more time think about
things after the 9/1 freeze), but I wanted to point out that the argument
that something new should be written because an existing project has tech
debt, and we'll do it the right way this time, is a pretty common software
engineering mistake. The thing you’re replacing usually needs to have some
really serious problems to make it worth replacing.

Agreed, Yes, I don’t think we should write everything from the scratch, but
carry forwarding tech debt (if any) and design decisions which makes new
features in future difficult to develop is something that we need to
consider. I second Dinesh’s thought on taking the best parts from available
projects to move forward with the right solution which works great and
easily pluggable.

-
Vinay Chella


On Tue, Aug 28, 2018 at 10:03 PM Mick Semb Wever  wrote:

>
> > the argument that something new should be written because an existing
> project has tech debt, and we'll do it the right way this time, is a pretty
> common software engineering mistake. The thing you’re replacing usually
> needs to have some really serious problems to make it worth replacing.
>
>
> Thanks for writing this Blake. I'm no fan of writing from scratch. Working
> with other people's code is the joy of open-source, imho.
>
> Reaper is not a big project. None of its java files are large or
> complicated.
> This is not the C* codebase we're talking about.
>
> It comes with strict code style in place (which the build enforces), unit
> and integration tests. The tech debt that I think of first is removing
> stuff that we would no longer want to support if it were inside the
> Cassandra project. A number of recent refactorings  have proved it's an
> easy codebase to work with.
>
> It's also worth noting that Cassandra-4.x adoption is still some away, in
> which time Reaper will only continue to grow and gain users.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Yet another repair solution

[Vinay Chella]

I am excited to see that the community is working on solving the critical
problems in C* operations (e.g., repair, backups etc.,) with different
solutions. Of course, learnings from these systems are key to designing the
robust solution which works for everyone.


Thanks,
Vinay Chella


On Tue, Aug 28, 2018 at 1:23 PM Roopa 
wrote:

> +1 interested in seeing and understanding another repair solution.
>
> > On Aug 28, 2018, at 1:03 PM, Joseph Lynch  wrote:
> >
> > I'm pretty interested in seeing and understanding your solution! When we
> > started on CASSANDRA-14346 reading your design documents and plan you
> > sketched out in CASSANDRA-10070 were really helpful in improving our
> > design. I'm particularly interested in how the Scheduler/Job/Task APIs
> > turned out (we're working on something similar internally and would love
> to
> > compare notes and figure out the best way to implement that kind of
> > abstraction)?
> >
> > -Joey
> >
> >
> > On Tue, Aug 28, 2018 at 6:34 AM Marcus Olsson <
> marcus.ols...@ericsson.com>
> > wrote:
> >
> >> Hi,
> >>
> >> With the risk of stirring the repair/side-car topic  even further I'd
> just
> >> like to mention that we have recently gotten approval to contribute our
> >> repair management side-car solution.
> >> It's based on the proposal in
> >> https://issues.apache.org/jira/browse/CASSANDRA-10070 as a standalone
> >> application sitting next to each instance.
> >> With the recent discussions in mind I'd just like to hear the thoughts
> >> from the community on this before we put in the effort of bringing our
> >> solution into open source.
> >>
> >> Would there be an interest of having yet another repair solution in the
> >> discussion?
> >>
> >> Best Regards
> >> Marcus Olsson
> >>
>
> -
> 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

[Vinay Chella]

You can still use the same repo and go with different release cadence as
Jeremiah mentioned, and yes, you can just pull the management sidecar,
test, and rollout without rolling out the server.

It looks like there are merits to both approaches, but it is going to come
down to the appetite of the team to manage several projects, it's releases,
coordination and without compromising on quality. we are fine with either
of the approaches. If this does not work out in the future, we always have
a decision log to refer, learn and move forward.

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

Regards,
Vinay Chella


On Fri, Aug 17, 2018 at 10:46 AM Rahul Singh 
wrote:

> I understand the issues of managing different versions of two correlated
> components — but it is possible to create unit tests with core components
> of both. It takes more effort but it is possible.
>
> That being said, in my experience using Reaper and in the DataStax
> distribution , using OpsCenter , I prefer a separate project that is
> loosely tied to the system and not connected at the hips. Whenever there is
> an update to Reaper or OpsCenter, I can always pull it down and test it
> before rolling it out - and this is much more frequently than if I were
> rolling out updates to a C* cluster.
>
>
> Rahul
> On Aug 17, 2018, 9:41 AM -0700, Jonathan Haddad ,
> wrote:
> > Speaking from experience (Reaper), I can say that developing a sidecar
> > admin / repair tool out of tree that's compatible with multiple versions
> > really isn't that big of a problem. We've been doing it for a while now.
> >
> >
> https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml
> >
> > On Fri, Aug 17, 2018 at 9:39 AM Joseph Lynch 
> wrote:
> >
> > > While I would love to use a different build system (e.g. gradle) for
> the
> > > sidecar, I agree with Dinesh that a separate repo would make sidecar
> > > development much harder to verify, especially on the testing and
> > > compatibility front. As Jeremiah mentioned we can always choose later
> to
> > > release the sidecar artifact separately or more frequently than the
> main
> > > server regardless of repo choice and as per Roopa's point having a
> separate
> > > release artifact (jar or deb/rpm) is probably a good idea until the
> default
> > > Cassandra packages don't automatically stop and start Cassandra on
> install.
> > >
> > > While we were developing the repair scheduler in a separate repo we
> had a
> > > number of annoying issues that only started surfacing once we started
> > > merging it directly into the trunk tree:
> > > 1. It is hard to compile/test against unreleased versions of Cassandra
> > > (e.g. the JMX interfaces changed a lot with 4.x, and it was pretty
> tricky
> > > to compile against that as the main project doesn't release nightly
> > > snapshots or anything like that, so we had to build local trunk jars
> and
> > > then manually dep them).
> > > 2. Integration testing and cross version compatibility is extremely
> hard.
> > > The sidecar is going to be involved in multi node coordination (e.g.
> > > monitoring, metrics, maintenance) and will be tightly coupled to JMX
> > > interface choices in the server and trying to make sure that it all
> works
> > > with multiple versions of Cassandra is much harder if it's a separate
> repo
> > > that has to have a mirroring release cycle to Cassandra. It seems much
> > > easier to have it in tree and just be like "the in tree sidecar is
> tested
> > > against that version of Cassandra". Every time we cut a Cassandra
> server
> > > branch the sidecar branches with it.
> > >
> > > We experience these pains all the time with Priam being in a separate
> repo,
> > > where every time we support a new Cassandra version a bunch of JMX
> > > endpoints break and we have to refactor the code to either call JMX
> methods
> > > by string or cut a new Priam branch. A separate artifact is pretty
> > > important, but a separate repo just allows drifts. Furthermore from the
> > > Priam experience I also don't think it's realistic to say one version
> of a
> > > sidecar artifact can actually support multiple versions.
> > >
> > > -Joey
> > >
> > > On Fri, Aug 17, 2018 at 12:00 PM Jeremiah D Jordan <
> jerem...@datastax.com>
> > > wrote:
> > >
> > > > Not sure why the two things being in the same repo means they need
&

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

[Vinay Chella]

+1 nb.

Here are the test results.
https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.0.17_tentative

Most of the failed tests are related to snapshot_test.TestArchiveCommitlog.

Regards,
Vinay Chella


On Thu, Jul 26, 2018 at 3:05 PM kurt greaves  wrote:

> +1 nb
>
> On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe,  wrote:
>
> > +1
> >
> > On 25 July 2018 at 08:17, 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)

[Vinay Chella]

+1 nb.

Here are the failed tests (circleci
<https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/3.11.3_tentative>),
if anyone is curious about failed tests.

dtests-no-vnodes  (5 Failed tests)
test_short_read - consistency_test.TestConsistency
test_describecluster_more_information_three_datacenters -
nodetool_test.TestNodetool
test_failure_threshold_deletions - paging_test.TestPagingWithDeletions
test_closing_connections - thrift_hsha_test.TestThriftHSHA
test_mutation_v5 - write_failures_test.TestWriteFailures

dtests-with-vnodes (6 failed tests)
test_14330 - consistency_test.TestConsistency
test_remote_query - cql_test.TestCQLSlowQuery
test_describecluster_more_information_three_datacenters -
nodetool_test.TestNodetool
test_failure_threshold_deletions - paging_test.TestPagingWithDeletions
test_closing_connections - thrift_hsha_test.TestThriftHSHA
test_mutation_v5 - write_failures_test.TestWriteFailures

Regards,
Vinay Chella


On Thu, Jul 26, 2018 at 3:06 PM kurt greaves  wrote:

> +1 nb
>
> On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe,  wrote:
>
> > +1
> >
> > On 25 July 2018 at 08:16, 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: [VOTE] Branching Change for 4.0 Freeze

[Vinay Chella]

+1 nb

Regards,
Vinay Chella


On Fri, Jul 13, 2018 at 11:15 AM Michael Shuler 
wrote:

> +0
>
> There are pros and cons. I do hope the pros work out and the cons aren't
> too impactful. I thought about just abstaining, but figured a "meh,
> whatever" vote was at least worth voicing.
>
> Michael
>
> On 07/11/2018 04:46 PM, 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: Proposing an Apache Cassandra Management process

[Vinay Chella]

This is a good initiative. We have advocated for and run a sidecar for the
past 5+ years, and we've learned and improved it a lot. We look forward to
moving features from Priam (such as backup, HTTP -> JMX, etc) incrementally
to this sidecar as they make sense.


Thanks,
Vinay Chella

On Fri, Apr 13, 2018 at 7:01 AM, Eric Evans <john.eric.ev...@gmail.com>
wrote:

> On Thu, Apr 12, 2018 at 4:41 PM, Dinesh Joshi
> <dinesh.jo...@yahoo.com.invalid> wrote:
> > Hey all -
> > With the uptick in discussion around Cassandra operability and after
> discussing potential solutions with various members of the community, we
> would like to propose the addition of a management process/sub-project into
> Apache Cassandra. The process would be responsible for common operational
> tasks like bulk execution of nodetool commands, backup/restore, and health
> checks, among others. We feel we have a proposal that will garner some
> discussion and debate but is likely to reach consensus.
> > While the community, in large part, agrees that these features should
> exist “in the database”, there is debate on how they should be implemented.
> Primarily, whether or not to use an external process or build on
> CassandraDaemon. This is an important architectural decision but we feel
> the most critical aspect is not where the code runs but that the operator
> still interacts with the notion of a single database. Multi-process
> databases are as old as Postgres and continue to be common in newer systems
> like Druid. As such, we propose a separate management process for the
> following reasons:
> >
> >- Resource isolation & Safety: Features in the management process
> will not affect C*'s read/write path which is critical for stability. An
> isolated process has several technical advantages including preventing use
> of unnecessary dependencies in CassandraDaemon, separation of JVM resources
> like thread pools and heap, and preventing bugs from adversely affecting
> the main process. In particular, GC tuning can be done separately for the
> two processes, hopefully helping to improve, or at least not adversely
> affect, tail latencies of the main process.
> >
> >- Health Checks & Recovery: Currently users implement health checks
> in their own sidecar process. Implementing them in the serving process does
> not make sense because if the JVM running the CassandraDaemon goes south,
> the healthchecks and potentially any recovery code may not be able to run.
> Having a management process running in isolation opens up the possibility
> to not only report the health of the C* process such as long GC pauses or
> stuck JVM but also to recover from it. Having a list of basic health checks
> that are tested with every C* release and officially supported will help
> boost confidence in C* quality and make it easier to operate.
> >
> >- Reduced Risk: By having a separate Daemon we open the possibility
> to contribute features that otherwise would not have been considered before
> eg. a UI. A library that started many background threads and is operated
> completely differently would likely be considered too risky for
> CassandraDaemon but is a good candidate for the management process.
>
> Makes sense IMO.
>
> > What can go into the management process?
> >- Features that are non-essential for serving reads & writes for eg.
> Backup/Restore or Running Health Checks against the CassandraDaemon, etc.
> >
> >- Features that do not make the management process critical for
> functioning of the serving process. In other words, if someone does not
> wish to use this management process, they are free to disable it.
> >
> > We would like to initially build minimal set of features such as health
> checks and bulk commands into the first iteration of the management
> process. We would use the same software stack that is used to build the
> current CassandraDaemon binary. This would be critical for sharing code
> between CassandraDaemon & management processes. The code should live
> in-tree to make this easy.
> > With regards to more in-depth features like repair scheduling and
> discussions around compaction in or out of CassandraDaemon, while the
> management process may be a suitable host, it is not our goal to decide
> that at this time. The management process could be used in these cases, as
> they meet the criteria above, but other technical/architectural reasons may
> exists for why it should not be.
> > We are looking forward to your comments on our proposal,
>
> Sounds good to me.
>
> Personally, I'm a little less interested in things like
> health/availability checks and metrics collection, because there are
> already tools 

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

[Vinay Chella]

Tests are green on our side. +1

Regards,
Vinay Chell
​a​


On Thu, Feb 15, 2018 at 4:30 PM, Nate McCall  wrote:

> Thanks, Jason!!
>
> On Fri, Feb 16, 2018 at 1:18 PM, Jason Brown  wrote:
> > Nate, I can do this.
> >
> > On Thu, Feb 15, 2018 at 2:51 PM, Nate McCall  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: Proposal to retroactively mark materialized views experimental

[Vinay Chella]

We tried perf testing MVs internally here but did not see good results with
it, hence paused its usage. +1 on tagging certain features which are not
PROD ready or not stable enough.

Regards,
Vinay Chella

On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead <b...@instaclustr.com> wrote:

> I'm a fan of introducing experimental flags in general as well, +1
>
>
>
> On Fri, 29 Sep 2017 at 13:22 Jon Haddad <j...@jonhaddad.com> wrote:
>
> > I’m very much +1 on this, and to new features in general.
> >
> > I think having a clear line in which we classify something as production
> > ready would be nice.  It would be great if committers were using the
> > feature in prod and could vouch for it’s stability.
> >
> > > On Sep 29, 2017, at 1:09 PM, Blake Eggleston <beggles...@apple.com>
> > wrote:
> > >
> > > Hi dev@,
> > >
> > > I’d like to propose that we retroactively classify materialized views
> as
> > an experimental feature, disable them by default, and require users to
> > enable them through a config setting before using.
> > >
> > > Materialized views have several issues that make them (effectively)
> > unusable in production. Some of the issues aren’t just implementation
> > problems, but problems with the design that aren’t easily fixed. It’s
> > unfair of us to make features available to users in this state without
> > providing a clear warning that bad or unexpected things are likely to
> > happen if they use it.
> > >
> > > Obviously, this isn’t great news for users that have already adopted
> > MVs, and I don’t have a great answer for that. I think that’s sort of a
> > sunk cost at this point. If they have any MV related problems, they’ll
> have
> > them whether they’re marked experimental or not. I would expect this to
> > reduce the number of users adopting MVs in the future though, and if they
> > do, it would be opt-in.
> > >
> > > Once MVs reach a point where they’re usable in production, we can
> remove
> > the flag. Specifics of how the experimental flag would work can be
> hammered
> > out in a forthcoming JIRA, but I’d imagine it would just prevent users
> from
> > creating new MVs, and maybe log warnings on startup for existing MVs if
> the
> > flag isn’t enabled.
> > >
> > > Let me know what you think.
> > >
> > > Thanks,
> > >
> > > Blake
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr <https://www.instaclustr.com/>
> +1 650 284 9692
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>

Re: [VOTE] Release Apache Cassandra 2.1.19

[Vinay Chella]

+1

On Thu, Sep 28, 2017 at 8:38 PM, Josh McKenzie  wrote:

> +1
>
> On Thu, Sep 28, 2017 at 2:13 PM, Aleksey Yeshchenko 
> wrote:
>
> > +1
> >
> > —
> > AY
> >
> > On 28 September 2017 at 19:12:19, Michael Shuler (mich...@pbandjelly.org
> )
> > 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: Weekly Cassandra Wrap-up

[Vinay Chella]

Priam could go in Cassandra cluster management section.

Priam - https://github.com/Netflix/Priam​

​Thanks,
Vinay​ Chella


On Mon, Apr 3, 2017 at 2:43 PM, Brandon Williams <dri...@gmail.com> wrote:

> Not specific to C*, but still sjk plus a million times over:
>
> https://github.com/aragozin/jvm-tools
>
> On Mon, Apr 3, 2017 at 4:17 PM, Jeff Jirsa <jji...@gmail.com> wrote:
>
> > Monday follow-up:
> >
> > There exist a lot of tools that a lot of people know exist and use for
> > managing clusters. Examples are repair scripts like
> > - https://github.com/spotify/cassandra-reaper
> > - https://github.com/BrianGallew/cassandra_range_repair
> > - https://github.com/thelastpickle/cassandra-reaper
> >
> > Or cassandra puppet modules:
> > - https://github.com/locp/cassandra
> >
> > Or Brian Hess' counter+loader tools:
> > - https://github.com/brianmhess/cassandra-count
> > - https://github.com/brianmhess/cassandra-loader
> >
> > Or Brian Gallew's tools at:
> > - https://github.com/BrianGallew/cassandra_tools
> >
> > I'd like to make a more comprehensive list of these third party tools and
> > include them in the docs - are there any tools you find useful in using
> > Cassandra that should be listed?
> >
> >
> >
> >
> > On Sun, Apr 2, 2017 at 7:53 PM, Jeff Jirsa <jji...@gmail.com> wrote:
> >
> > > From the email list:
> > >
> > > 1) Some grad students are doing some research on Cassandra and have
> open
> > > questions about thread interactions - would be great if someone had
> time
> > to
> > > help answer their questions: https://lists.apache.org/thread.html/
> > > 70ae332f54676352755bcb421b66a56fe27e296f8828eff26727bb58@%
> > > 3Cdev.cassandra.apache.org%3E
> > >
> > > 2) The ongoing discussion of code quality, testing, and coverage
> > continues
> > > - if you haven't read it yet, but you care about release quality, you
> > > probably should ( https://lists.apache.org/thread.html/
> > > 0854341ae3ab41ceed2ae8a03f2486cf2325e4fca6fd800bf4297dd4@%
> > > 3Cdev.cassandra.apache.org%3E )
> > >
> > > 3) As a follow-up to #2, I proposed pushing up some CircleCI and Travis
> > > YML files into the active branches to make testing easier -  (
> > > https://lists.apache.org/thread.html/48e73ff0d2aff5af3d6feb20af5e7f
> > > 4318c17379471abb2c16c2dcdf@%3Cdev.cassandra.apache.org%3E /
> > > https://issues.apache.org/jira/browse/CASSANDRA-13388 ). If anyone has
> > > strong opinions on Circle/Travis, or is great with setting up yaml
> files
> > to
> > > configure parallel CI tests, wouldn't mind having some feedback here
> > (like
> > > "we can split up nosetests like ", or "let's use  instead
> because
> > > it'll be easier", or "just push it as is and we'll iterate on it
> later" -
> > > I'm personally leaning towards "push it and iterate later", since it's
> > not
> > > actually impacting the database at runtime, but other feedback is
> always
> > > great)
> > >
> > >
> > > JIRA stuff:
> > >
> > > - https://issues.apache.org/jira/browse/CASSANDRA-13396 - we use
> SLF4J,
> > > but really only support logback (though we didn't actively exclude
> other
> > > loggers until recently); people with long histories working on the
> > project
> > > (especially you Datastax and TLP folks), may want to throw in their two
> > > cents on this ticket. People commenting should endeavor to keep things
> > fact
> > > based, and not emotional.
> > >
> > > Some more patch-available JIRAs but no reviewers:
> > > - https://issues.apache.org/jira/browse/CASSANDRA-13397 (Return value
> of
> > > CountDownLatch.await() not being checked in Repair )
> > > - https://issues.apache.org/jira/browse/CASSANDRA-13307 (Make CQLSH
> > Great
> > > Again by making CQLSH downgrade native protocol properly)
> > > - https://issues.apache.org/jira/browse/CASSANDRA-12962 (SASI
> needlessly
> > > rebuilding empty indices)
> > > - https://issues.apache.org/jira/browse/CASSANDRA-13067 (Huge AWS
> > > filesystems overflow Long.MAX_INT)
> > > - https://issues.apache.org/jira/browse/CASSANDRA-12748 (GREP_COLOR
> > > environment variable breaks things)
> > > And These two BTree related patches have been around a while, still no
> > > reviewer:
> > > - https://issues.apache.org/jira/browse/CASSANDRA-9989 &
> > > https://issues.apache.org/jira/browse/CASSANDRA-9988
> > >
> > > - Jeff
> > >
> >
>