Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

[Sumanth Pasupuleti]

+1, thank you for your efforts in bringing Harry in-tree. Anything that
improves the testing ecosystem for Cassandra, particularly around complex
scenarios / edge cases  goes a long way in improving reliability, and with
having a powerful tool like Harry in-tree, it is a lot more accessible to
the developers than it has been. Also, thank you for keeping in mind the
onboarding experience of developers.

- Sumanth

On Fri, Dec 22, 2023 at 1:11 AM Alex Petrov  wrote:

> Some follow-up tickets to establish the project direction:
>
> https://issues.apache.org/jira/browse/CASSANDRA-19229
>
> Two other things that we will work on in Tree are:
> https://issues.apache.org/jira/browse/CASSANDRA-18275 (model and in-JVM
> test for partition-restricted 2i queries)
> https://issues.apache.org/jira/browse/CASSANDRA-18667 (multi-threaded SAI
> read and write fuzz test)
>
> If you would like to get your recently added feature tested with Harry
> model, please let me know!
>
> On Fri, Dec 22, 2023, at 12:41 AM, Joseph Lynch wrote:
>
> +1
>
> Sounds like a great change that will help us unify around a common testing
> paradigm, and even pave the path to in-tree load testing plus integrated
> correctness checking which would be extremely valuable!
>
> -Joey
>
> On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe 
> wrote:
>
> +1
>
> Agree w/ all the justifications mentioned above.
>
> As a reviewer on CASSANDRA-19210
> , my goals were to
> a.) look at the directory, naming, and package structure of the ported
> code, b.) make sure IDE integration was working, and c.) make sure any
> modifications to existing code (rather than direct code movements from
> cassandra-harry) were straightforward.
>
> On Thu, Dec 21, 2023 at 3:23 PM Alex Petrov  wrote:
>
>
> Hey folks,
>
> I am mostly done with a patch that brings Harry in-tree [1]. I will
> trigger one more CI run overnight, and my intention was to merge it some
> time soon, but I wanted to give a fair warning here, since this is a
> relatively large patch.
>
> Good news for everyone that it:
>   a) touches no production code whatsoever. Only test (in-jvm dtest
> namely) code that was using Harry already.
>   b) the only tests that are changed are ones that used a duplicate
> version of placement simulator we had both for testing TCM, and in Harry
>   c) in addition, I have converted 3 existing TCM tests to a new API to
> have some base for examples/usage.
>
> Since we were effectively relying on this code for a while now, and the
> intention now is to converge to:
>   a) fewer different generators, and have a shareable version of
> generators for everyone to use accross the base
>   b) a testing tool that can be useful for both trivial cases, and complex
> scenarios
> myself and many other Cassandra contributors have expressed an opinion
> that bringing Harry in-tree will be highly benefitial.
>
> I strongly believe that bringing Harry in-tree will help to lower the
> barrier for fuzz test and simplify co-development of Cassandra and Harry.
> Previously, it has been rather difficult to debug edge cases because I had
> to either re-compile an in-jvm dtest jar and bring it to Harry, or
> re-compile a Harry jar and bring it to Cassandra, which is both tedious and
> time consuming. Moreover, I believe we have missed at very least one RT
> regression [2] because Harry was not in-tree, as its tests would've caught
> the issue even with the model that existed.
>
> For other recently found issues, I think having Harry in-tree would have
> substantially lowered a turnaround time, and allowed me to share repros
> with developers of corresponding features much quicker.
>
> I do expect a slight learning curve for Harry, but my intention is to
> build a web of simple tests (worked on some of them yesterday after
> conversation with David already), which can follow the in-jvm-dtest pattern
> of find-similar-test / copy / modify. There's already copious
> documentation, so I do not believe not having docs for Harry was ever an
> issue, since there have been plenty.
>
> You all are aware of my dedication to testing and quality of Apache
> Cassandra, and I hope you also see the benefits of having a model checker
> in-tree.
>
> Thank you and happy upcoming holidays,
> --Alex
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19210
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18932
>
>
>

Re: [VOTE] Accept java-driver

[Sumanth Pasupuleti]

+1 (nb)

Thank you to everyone involved for reaching this point. Looking forward!!

On Tue, Oct 3, 2023 at 8:19 AM Francisco Guerrero 
wrote:

> +1 (nb)
>
> On 2023/10/03 14:51:04 Joseph Lynch wrote:
> > +1 (nb)
> >
> > I am so grateful for all the hard work that went into getting the java
> > driver accepted into the project, well done to all involved!
> >
> > -Joey
> >
> > On Tue, Oct 3, 2023 at 7:38 AM C. Scott Andreas 
> > wrote:
> >
> > > +1 (nb)
> > >
> > > Accepting this donation would mark a huge milestone for the project.
> > >
> > > On Oct 3, 2023, at 4:25 AM, Josh McKenzie 
> wrote:
> > >
> > >
> > > I see now this will likely be instead apache/cassandra-java-driver
> > >
> > > I was wondering about that. apache/java-driver seemed pretty broad. :)
> > >
> > > From the linked page:
> > > Check that all active committers have a signed CLA on record. TODO –
> > > attach list
> > > I've been part of these discussions and work so am familiar with the
> > > status of it (as well as guidance and clearance from the foundation re:
> > > folks we couldn't reach) - but might be worthwhile to link to the
> sheet or
> > > perhaps instead provide a summary of the 49 java contributors, their
> CLA
> > > signing status, attempts to reach out, etc for other PMC members that
> > > weren't actively involved back when we were working through it.
> > >
> > > As for my vote: +1
> > >
> > > Thanks everyone for the hard work getting to this point. This really
> is a
> > > significant contribution to the project.
> > >
> > > On Tue, Oct 3, 2023, at 6:48 AM, Brandon Williams wrote:
> > >
> > > +1
> > >
> > > Kind Regards,
> > > Brandon
> > >
> > > On Mon, Oct 2, 2023 at 11: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 Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Sumanth Pasupuleti]

Congratulations!!!

On Wed, Feb 16, 2022 at 2:48 PM Joseph Lynch  wrote:

> Woo
>
> Congratulations to the new committers and I am so excited to see the
> project recognizing these contributions!
>
> -Joey
>
>
> On Tue, Feb 15, 2022 at 10:13 AM Benjamin Lerer  wrote:
> >
> > The PMC members are pleased to announce that Anthony Grasso, Erick
> Ramirez and Lorina Poland have accepted the invitation to become committers.
> >
> > Thanks a lot, Anthony, Erick and Lorina for all the work you have done
> on the website and documentation.
> >
> > Congratulations and welcome
> >
> > The Apache Cassandra PMC members
>

Re: [VOTE] CEP-3: Guardrails

[Sumanth Pasupuleti]

+1

On Thu, Nov 11, 2021 at 6:10 AM Gary Dusbabek  wrote:

> +1
>
> On Thu, Nov 11, 2021 at 5:30 AM Andrés de la Peña 
> wrote:
>
> > Hi everyone,
> >
> > I would like to start a vote on this CEP.
> >
> > Proposal:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails
> >
> > Discussion:
> > https://lists.apache.org/thread/7f6lntfdnkpqr7o0h2d2jlg8q7gf54w2
> > https://lists.apache.org/thread/0bd6fo4hdnwc8q2sq4xwvv4nqpxw10ds
> >
> > The vote will be open for 72 hours.
> > A vote passes if there are at least three binding +1s and no binding
> > vetoes.
> >
> > Thanks,
> >
>

Re: [DISCUSS] Creating a new slack channel for newcomers

[Sumanth Pasupuleti]

+1 that existing channels of communication (cassandra-dev slack and mailing
lists) should ideally suffice, and I have not seen prohibitive
communication in those forums thus far that goes against newcomers. I agree
it can be intimidating, but to Bowen's point, the more traffic we see
around newcomers in those forums, the more comfortable it gets.
I agree starting a new channel is a low effort experiment we can do, but
the success depends on finding mentors and the engagement of mentors vs I
believe engagement in #cassandra-dev is almost guaranteed given the high
number of people in the channel.

Thanks,
Sumanth

On Tue, Nov 9, 2021 at 6:47 AM Bowen Song  wrote:

> As a newcomer (made two commits since October) who has been watching
> this mailing list since then, I don't like the idea of a separate
> channel for beginner questions. The volume in this mailing list is
> fairly low, I can't see any legitimate reason for diverting a portion of
> that into another channel, further reducing the volume in the existing
> channel and perhaps not creating much volume in the new channel either.
>
> Personally, I think a clearly written and easy to find community
> guideline highlighting that this mailing list is suitable for beginner
> questions, and give some suggestions/recommendations on when, where and
> how to ask beginner questions would be more useful.
>
> At the moment because the volume of beginner questions is very very low
> in this mailing list, newcomers like me don't feel comfortable asking
> questions here. That's not because there's 600 pair of eyes watching
> this (TBH, if you didn't mention it, I wouldn't have noticed it), but
> because the herd mentality. If not many questions are asked here, most
> people won't start doing that. It's all about creating the environment
> that makes people feel comfortable asking questions here.
>
> On 08/11/2021 16:28, Benjamin Lerer wrote:
> > Hi everybody,
> >
> > Aleksei Zotov mentioned to me that it was a bit intimidating for
> newcomers
> > to ask beginner questions in the cassandra-dev channel as it has over 600
> > followers and that we should probably have a specific channel for
> > newcomers.
> > This proposal makes total sense to me.
> >
> > What is your opinion on this? Do you have any concerns about it?
> >
> > Benjamin
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] CEP-15: General Purpose Transactions

[Sumanth Pasupuleti]

1. +1 nb
2. +1 nb
3. +1 nb

Very excited about the possibilities this CEP will open up. Thanks for
putting this together, Benedict.

On Thu, Oct 14, 2021 at 2:08 PM Mick Semb Wever  wrote:

> >
> > 1. Do you support adopting this CEP?
> > 2. Do you support the transaction semantics proposed by the CEP for
> > Cassandra?
> > 3. Do you support an incremental approach to developing transactions in
> > Cassandra, leaving scope for future development?
> >
>
>
> 1.  -1
>
> There's discussions still ongoing around this CEP. I support the CEP but
> believe it is important that the community takes the patience to let
> everyone say their piece and feel that they have been heard. I do not see
> that waiting a week, or two, before another vote risks the inclusion of
> this CEP in this release cycle. I've certainly appreciated reading through
> every question raised, and wouldn't object to the CEP page being updated to
> include even more (but this is not a blocker for me).
>

Re: Welcome Aleksei Zotov as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Aleksei!!

On Tue, Sep 21, 2021 at 5:39 AM Joshua McKenzie 
wrote:

> Congrats Aleksei!
>
>
> On Tue, Sep 21, 2021 at 7:51 AM Jonathan Ellis  wrote:
>
> > Congratulations, Aleksei!
> >
> > On Tue, Sep 21, 2021 at 3:55 AM Benjamin Lerer 
> wrote:
> >
> > >  The PMC members are pleased to announce that Aleksei Zotov has
> accepted
> > > last Friday the invitation to become committer.
> > >
> > > Thanks a lot, Aleksei, for all your contributions to the project over
> the
> > > years.
> > >
> > > Congratulations and welcome
> > >
> > > The Apache Cassandra PMC members
> > >
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
> >
>

Re: [VOTE] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

With 6 (six) +1 votes and no -1 votes, the vote passes. Thanks everyone!

On Sat, Sep 11, 2021 at 11:41 PM Jordan West  wrote:

> +1
>
> On Wed, Sep 8, 2021 at 11:38 AM Chris Lohfink 
> wrote:
>
> > +1
> >
> > On Wed, Sep 8, 2021 at 11:58 AM bened...@apache.org  >
> > wrote:
> >
> > > +1
> > >
> > > From: Brandon Williams 
> > > Date: Wednesday, 8 September 2021 at 17:57
> > > To: dev@cassandra.apache.org 
> > > Subject: Re: [VOTE] CEP-13: Denylisting partitions
> > > +1
> > >
> > > On Wed, Sep 8, 2021 at 11:31 AM Sumanth Pasupuleti
> > >  wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > I’m proposing this CEP for approval.
> > > >
> > > > Proposal:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> > > > Discussion:
> > > >
> > >
> >
> https://lists.apache.org/thread.html/r1547c5f2fb8548e2f7dcbe1a26da8c2a95ebec81adeeb2ea0545924d%40%3Cdev.cassandra.apache.org%3E
> > > >
> > > > The vote will be open for 72 hours.
> > > > Votes by committers are considered binding.
> > > > A vote passes if there are at least three binding +1s and no binding
> > > vetoes.
> > > >
> > > > Thanks,
> > > > Sumanth
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
>

[VOTE] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

Hi everyone,

I’m proposing this CEP for approval.

Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
Discussion:
https://lists.apache.org/thread.html/r1547c5f2fb8548e2f7dcbe1a26da8c2a95ebec81adeeb2ea0545924d%40%3Cdev.cassandra.apache.org%3E

The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thanks,
Sumanth

Re: [DISCUSS] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

Resolved comment discussions in the design document that are closed.
If there is no further feedback, I will start a voting thread tomorrow.

Thanks,
Sumanth

On Thu, Sep 2, 2021 at 6:54 AM Joshua McKenzie  wrote:

> I'm +1 on where it currently stands after the revisions. Consider resolving
> out comment threads on the design doc that are closed so we can see if
> there's any outstanding discussions from a high level?
>
> ~Josh
>
> On Mon, Aug 30, 2021 at 1:14 AM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > +1. Made changes to the design document linked against the CEP to reflect
> > this feedback. Specifically, the following sections have been updated
> > * Operations to blacklist
> > * Blacklist information store
> >
> > Thanks,
> > Sumanth
> >
> >
> > On Fri, Aug 27, 2021 at 7:57 AM Joshua McKenzie 
> > wrote:
> >
> > > I can see the case for all three:
> > > * Deny both reads and writes to a partition (wide, heavily tombstones,
> > too
> > > many stables, etc) causing disruption to a replica set; don't want
> > further
> > > growth nor reads until operator intervention
> > > * Deny reads but allow writing to rectify problems on a partition
> > > (intervention window; see above)
> > > * Deny writes to a partition but allow reads (prevent partitions
> growing
> > > unbounded, or potentially evolving into a future feature creating a
> > ceiling
> > > on partition sizes that kicks in and demands application intervention
> to
> > > reduce partition size at a guardrail limit)
> > >
> > > So yeah, at least to me at face value it seems like it'd be worth it
> not
> > > only to allow denylisting both reads and writes, but to be able to
> choose
> > > from the set of reads|writes|both on a per-partition basis.
> > >
> > > ~Josh
> > >
> > >
> > > On Thu, Aug 26, 2021 at 2:16 PM Sumanth Pasupuleti <
> > > sumanth.pasupuleti...@gmail.com> wrote:
> > >
> > > > Thank you, Josh for the elaborate explanation of a potential scenario
> > > where
> > > > denylisting writes would make sense.
> > > > I, 100% agree that could benefit in a situation where we would want
> to
> > > deny
> > > > writes to a partition that we do not have much control on (which is
> > true
> > > in
> > > > most situations) and such behavior can eventually lead to
> > unavailability
> > > of
> > > > other partitions too, as you indicate.
> > > >
> > > > Do you think it makes sense to make it configurable per partition
> > though?
> > > > As in, maybe by default, we would want to deny both reads and writes
> > to a
> > > > partition, but for certain partitions, we may still want to allow
> > writes
> > > > just so we can issue a delete against that partition as an example.
> > > > Ofcourse this would make the feature and the interface more heavy,
> and
> > we
> > > > need to think through if its worth it. I personally feel it could be
> > > worth
> > > > it, especially if we agree on the default behavior that makes the
> > > interface
> > > > simple in most cases. Thoughts?
> > > >
> > > > And yes, so good to see CEP process reaping benefits in multiple
> ways -
> > > > especially around collaboration and documentation.
> > > >
> > > >
> > > > On Thu, Aug 26, 2021 at 8:31 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > The design doc and CEP currently pass on blocklisting / denylisting
> > > > writes
> > > > > at this time. In the proposed new patch it states:
> > > > > "Note: We do not want to blacklist writes since it is the reads
> that
> > > > > primarily impact the performance when reading a bad partition, and
> we
> > > may
> > > > > want writes to be allowed to “fix” a bad partition. We could
> revisit
> > > this
> > > > > in the future"
> > > > >
> > > > > In situations where you have an air gap between database ops and
> > > > > application access (ops <> application teams, or more autonomous
> > > > > application access patterns, self-service, etc), you can easily get
> > > into
> > > > a
> > > > > situation where you have either a pathological cli

Re: [VOTE] Release Apache Cassandra 4.0.1

[Sumanth Pasupuleti]

+1 nb

Verified j8 unit tests and dtests pass
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra/98/workflows/52d8cd3f-0062-407e-a3f8-f78935cff0d4

On Wed, Sep 1, 2021 at 10:23 AM Andrés de la Peña 
wrote:

> +1
>
> On Wed, 1 Sept 2021 at 17:37, Ekaterina Dimitrova 
> wrote:
>
> > +1
> >
> > On Wed, 1 Sep 2021 at 12:34, Joshua McKenzie 
> wrote:
> >
> > > +1
> > >
> > > On Wed, Sep 1, 2021 at 11:16 AM Yifan Cai  wrote:
> > >
> > > > +1
> > > >
> > > >
> > > > - Yifan
> > > >
> > > > > On Sep 1, 2021, at 7:57 AM, C. Scott Andreas  >
> > > > wrote:
> > > > >
> > > > > +1nb
> > > > >
> > > > >> On Sep 1, 2021, at 6:54 AM, Jeff Jirsa  wrote:
> > > > >>
> > > > >> +1
> > > > >>
> > > > >>
> > > > >>>> On Wed, Sep 1, 2021 at 4:54 AM Sam Tunnicliffe 
> > > > wrote:
> > > > >>>
> > > > >>> Proposing the test build of Cassandra 4.0.1 for release.
> > > > >>>
> > > > >>> sha1: 6709111ed007a54b3e42884853f89cabd38e4316
> > > > >>> Git:
> > > > >>>
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative
> > > > >>> Maven Artifacts:
> > > > >>>
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1247/org/apache/cassandra/cassandra-all/4.0.1/
> > > > >>>
> > > > >>> The Source and Build Artifacts, and the Debian and RPM packages
> and
> > > > >>> repositories, are available here:
> > > > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.1/
> > > > >>>
> > > > >>> 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/4.0.1-tentative
> > > > >>> [2]: NEWS.txt:
> > > > >>>
> > > >
> > >
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.1-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: [DISCUSS] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

+1. Made changes to the design document linked against the CEP to reflect
this feedback. Specifically, the following sections have been updated
* Operations to blacklist
* Blacklist information store

Thanks,
Sumanth


On Fri, Aug 27, 2021 at 7:57 AM Joshua McKenzie 
wrote:

> I can see the case for all three:
> * Deny both reads and writes to a partition (wide, heavily tombstones, too
> many stables, etc) causing disruption to a replica set; don't want further
> growth nor reads until operator intervention
> * Deny reads but allow writing to rectify problems on a partition
> (intervention window; see above)
> * Deny writes to a partition but allow reads (prevent partitions growing
> unbounded, or potentially evolving into a future feature creating a ceiling
> on partition sizes that kicks in and demands application intervention to
> reduce partition size at a guardrail limit)
>
> So yeah, at least to me at face value it seems like it'd be worth it not
> only to allow denylisting both reads and writes, but to be able to choose
> from the set of reads|writes|both on a per-partition basis.
>
> ~Josh
>
>
> On Thu, Aug 26, 2021 at 2:16 PM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Thank you, Josh for the elaborate explanation of a potential scenario
> where
> > denylisting writes would make sense.
> > I, 100% agree that could benefit in a situation where we would want to
> deny
> > writes to a partition that we do not have much control on (which is true
> in
> > most situations) and such behavior can eventually lead to unavailability
> of
> > other partitions too, as you indicate.
> >
> > Do you think it makes sense to make it configurable per partition though?
> > As in, maybe by default, we would want to deny both reads and writes to a
> > partition, but for certain partitions, we may still want to allow writes
> > just so we can issue a delete against that partition as an example.
> > Ofcourse this would make the feature and the interface more heavy, and we
> > need to think through if its worth it. I personally feel it could be
> worth
> > it, especially if we agree on the default behavior that makes the
> interface
> > simple in most cases. Thoughts?
> >
> > And yes, so good to see CEP process reaping benefits in multiple ways -
> > especially around collaboration and documentation.
> >
> >
> > On Thu, Aug 26, 2021 at 8:31 AM Joshua McKenzie 
> > wrote:
> >
> > > The design doc and CEP currently pass on blocklisting / denylisting
> > writes
> > > at this time. In the proposed new patch it states:
> > > "Note: We do not want to blacklist writes since it is the reads that
> > > primarily impact the performance when reading a bad partition, and we
> may
> > > want writes to be allowed to “fix” a bad partition. We could revisit
> this
> > > in the future"
> > >
> > > In situations where you have an air gap between database ops and
> > > application access (ops <> application teams, or more autonomous
> > > application access patterns, self-service, etc), you can easily get
> into
> > a
> > > situation where you have either a pathological client hammering writes
> > to a
> > > specific partition causing impact to other clients or in the worst
> case,
> > > the replica set, or unbounded partition growth that again leads to
> > > performance degradation or replica set unavailability. The tradeoff
> there
> > > becomes "do we interrupt the application's ability to write to this
> > > partition now, or do we instead defer and risk losing access to *all*
> > > partitions on this replica set and still interrupt their access
> > eventually
> > > anyway?"
> > >
> > > Given this, I strongly advocate for support of denylisting both reads
> > *and*
> > > writes on these grounds; operators need another tool in their toolbox
> to
> > > deal with situations where specific partition writing has wider
> negative
> > > impacts on the replicas.
> > >
> > > Acknowledging of course that there was extensive discussion on this
> back
> > in
> > > 2018, and that would have been a *great* time to engage in the
> > discussion.
> > > =/ Good thing we have this new CEP process! :)
> > >
> > > Curious what you think about this perspective Sumanth.
> > >
> > > ~Josh
> > >
> > >
> > > On Tue, Aug 17, 2021 at 2:04 PM Joshua McKenzie 
> > > wrote:
> > >
> > > &

Re: [DISCUSS] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

Thank you, Josh for the elaborate explanation of a potential scenario where
denylisting writes would make sense.
I, 100% agree that could benefit in a situation where we would want to deny
writes to a partition that we do not have much control on (which is true in
most situations) and such behavior can eventually lead to unavailability of
other partitions too, as you indicate.

Do you think it makes sense to make it configurable per partition though?
As in, maybe by default, we would want to deny both reads and writes to a
partition, but for certain partitions, we may still want to allow writes
just so we can issue a delete against that partition as an example.
Ofcourse this would make the feature and the interface more heavy, and we
need to think through if its worth it. I personally feel it could be worth
it, especially if we agree on the default behavior that makes the interface
simple in most cases. Thoughts?

And yes, so good to see CEP process reaping benefits in multiple ways -
especially around collaboration and documentation.


On Thu, Aug 26, 2021 at 8:31 AM Joshua McKenzie 
wrote:

> The design doc and CEP currently pass on blocklisting / denylisting writes
> at this time. In the proposed new patch it states:
> "Note: We do not want to blacklist writes since it is the reads that
> primarily impact the performance when reading a bad partition, and we may
> want writes to be allowed to “fix” a bad partition. We could revisit this
> in the future"
>
> In situations where you have an air gap between database ops and
> application access (ops <> application teams, or more autonomous
> application access patterns, self-service, etc), you can easily get into a
> situation where you have either a pathological client hammering writes to a
> specific partition causing impact to other clients or in the worst case,
> the replica set, or unbounded partition growth that again leads to
> performance degradation or replica set unavailability. The tradeoff there
> becomes "do we interrupt the application's ability to write to this
> partition now, or do we instead defer and risk losing access to *all*
> partitions on this replica set and still interrupt their access eventually
> anyway?"
>
> Given this, I strongly advocate for support of denylisting both reads *and*
> writes on these grounds; operators need another tool in their toolbox to
> deal with situations where specific partition writing has wider negative
> impacts on the replicas.
>
> Acknowledging of course that there was extensive discussion on this back in
> 2018, and that would have been a *great* time to engage in the discussion.
> =/ Good thing we have this new CEP process! :)
>
> Curious what you think about this perspective Sumanth.
>
> ~Josh
>
>
> On Tue, Aug 17, 2021 at 2:04 PM Joshua McKenzie 
> wrote:
>
> > Certainly. I'll take on distilling a high level view of the feature from
> > what Jon and I are working on to bring to this discussion.
> >
> >
> > On Tue, Aug 17, 2021 at 1:40 PM Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> >> +1 to collaborating on the patch, Josh. My 2 cents would be to continue
> to
> >> pursue this CEP in the community through Discuss and Vote phases and
> then
> >> invest further on the patch (based on the Vote phase outcome), so we can
> >> reflect any additional feedback we may gather from the community through
> >> this CEP.
> >>
> >> Thanks,
> >> Sumanth
> >>
> >> On Tue, Aug 17, 2021 at 10:13 AM Joshua McKenzie 
> >> wrote:
> >>
> >> > Sumanth,
> >> >
> >> > Jon Meredith and I are recently working on an OSS patch of one of
> those
> >> "ad
> >> > hoc" implementations of this feature that's been running at scale for
> >> > awhile like Jirsa mentioned; sorry for not catching the discussion on
> >> > https://issues.apache.org/jira/browse/CASSANDRA-12106 and engaging
> >> > earlier!
> >> >
> >> > I believe I can have a tidied up patch on 4.0 of this by early next
> >> week -
> >> > then we can look at the two implementations and take best of both.
> What
> >> do
> >> > you think?
> >> >
> >> > ~Josh
> >> >
> >> > On Mon, Aug 16, 2021 at 2:14 PM Sumanth Pasupuleti <
> >> > sumanth.pasupuleti...@gmail.com> wrote:
> >> >
> >> > > Starting a discussion thread for CEP-13
> >> > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> >> > >
> >> > > This CEP proposes adding a new feature to Cassandra to be able to
> >> > denylist
> >> > > partitions.
> >> > >
> >> > > Looking forward to any feedback/ thoughts.
> >> > >
> >> > > Thanks,
> >> > > Sumanth
> >> > >
> >> >
> >>
> >
>

Re: [DISCUSS] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

+1 to collaborating on the patch, Josh. My 2 cents would be to continue to
pursue this CEP in the community through Discuss and Vote phases and then
invest further on the patch (based on the Vote phase outcome), so we can
reflect any additional feedback we may gather from the community through
this CEP.

Thanks,
Sumanth

On Tue, Aug 17, 2021 at 10:13 AM Joshua McKenzie 
wrote:

> Sumanth,
>
> Jon Meredith and I are recently working on an OSS patch of one of those "ad
> hoc" implementations of this feature that's been running at scale for
> awhile like Jirsa mentioned; sorry for not catching the discussion on
> https://issues.apache.org/jira/browse/CASSANDRA-12106 and engaging
> earlier!
>
> I believe I can have a tidied up patch on 4.0 of this by early next week -
> then we can look at the two implementations and take best of both. What do
> you think?
>
> ~Josh
>
> On Mon, Aug 16, 2021 at 2:14 PM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Starting a discussion thread for CEP-13
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> >
> > This CEP proposes adding a new feature to Cassandra to be able to
> denylist
> > partitions.
> >
> > Looking forward to any feedback/ thoughts.
> >
> > Thanks,
> > Sumanth
> >
>

Re: Welcome Adam Holmberg as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Adam!!

On Mon, Aug 16, 2021 at 10:32 PM Berenguer Blasi 
wrote:

> Well done Adam, congrats!
>
> On 16/8/21 18:27, Andrés de la Peña wrote:
> > Congrats Adam, well deserved!
> >
> > On Mon, 16 Aug 2021 at 17:14, Patrick McFadin 
> wrote:
> >
> >> Great to see you on the committer list Adam!
> >>
> >> On Mon, Aug 16, 2021 at 7:06 AM Jonathan Ellis 
> wrote:
> >>
> >>> Well deserved.  Congratulations!
> >>>
> >>> On Mon, Aug 16, 2021 at 5:57 AM Benjamin Lerer 
> >> wrote:
>   The PMC members are pleased to announce that Adam Holmberg has
> >> accepted
>  the invitation to become committer.
> 
>  Thanks a lot, Adam, for everything you have done for the project all
> >>> these
>  years.
> 
>  Congratulations and welcome
> 
>  The Apache Cassandra PMC members
> 
> >>>
> >>> --
> >>> 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] CEP-13: Denylisting partitions

[Sumanth Pasupuleti]

Starting a discussion thread for CEP-13
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions

This CEP proposes adding a new feature to Cassandra to be able to denylist
partitions.

Looking forward to any feedback/ thoughts.

Thanks,
Sumanth

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

[Sumanth Pasupuleti]

+1 (nb)
Confirmed passing j8 UTs and dtests
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra/77/workflows/7b0ad00d-7ae3-41d2-b1a7-82fa63b7

On Wed, Jul 14, 2021 at 11:03 AM Jeremy Hanna 
wrote:

> +1 (nb)
>
> > On Jul 15, 2021, at 3:42 AM, Blake Eggleston
>  wrote:
> >
> > +1
> >
> >> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko 
> wrote:
> >>
> >> +1
> >>
> >>>> On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> >>>
> >>> +1
> >>>
> >>>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever 
> wrote:
> >>>>
> >>>> Proposing the test build of Cassandra 4.0.0 for release.
> >>>>
> >>>> sha1: 924bf92fab1820942137138c779004acaf834187
> >>>> Git:
> >>>>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> >>>> Maven Artifacts:
> >>>>
> >>>>
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> >>>>
> >>>> The Source and Build Artifacts, and the Debian and RPM packages and
> >>>> repositories, are available here:
> >>>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> >>>>
> >>>> 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/4.0.0-tentative
> >>>> [2]: NEWS.txt:
> >>>>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> >>>>
> >>>> -
> >>>> 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
> >>
> >
> > -
> > 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] CIP-9: Make SSLContext creation pluggable

[Sumanth Pasupuleti]

+1 non-binding

On Tue, Jul 13, 2021 at 10:05 PM Berenguer Blasi 
wrote:

> +1
>
> On 14/7/21 0:34, Nate McCall wrote:
> > +1
> >
> >
> > On Wed, Jul 14, 2021 at 2:49 AM Benjamin Lerer 
> wrote:
> >
> >> Hi everyone,
> >>
> >> I am proposing the CIP-9 (Make SSLContext creation pluggable) for
> adoption
> >>
> >> Discussion thread:
> >>
> >>
> https://lists.apache.org/thread.html/rbf99c0108a65f5e31a8f8f0ee525816ee0a387a6fae64de86ceb1495%40%3Cdev.cassandra.apache.org%3E
> >>
> >>
> >> The vote will be open for 72 hours.
> >> Votes by PMC members are considered binding. A
> >> vote passes if there are at least three binding +1s and no binding
> vetoes.
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Obfuscation of passwords in audit loging, in or not in 4.0?

[Sumanth Pasupuleti]

> I am on the side of "this sounds like a really bad bug" for the audit
pieces, maybe less so than FQL. Anyone using audit for real probably has
meaningful audit requirements, which means they're in an industry where
they get audited for security, which means logging passwords is a big deal.

+1. Given we are shipping audit logging feature for the first time with
4.0, it would be great if this rather low complex patch can be included in
the 4.0 RC and thereby ship a "complete feature".

On Thu, Jun 3, 2021 at 4:04 PM Vinay Chella 
wrote:

> > I think it can be argued that this is a pretty serious bug for a newly
> introduced feature, and qualifies for inclusion in an RC, but I don’t
> personally have a strong opinion on if this should happen.
>+1
>
> > One more point - if we keep the workaround, that should be documented
> with
> > big red letters for the users.
>
> Yes, heavy +1, if we are not merging it. Another idea, if we are not
> merging this in, is to put DCL(CREATE ROLE/USER, ALTER ROLE/USER etc.,)
> queries in the default configuration (cassandra.yaml) exclude list to avoid
> oops for operators, since that is the only query type that log passwords in
> plain text and all other places they are not.
>
>
> Thanks,
> Vinay
>
>
> On Thu, Jun 3, 2021 at 3:58 PM bened...@apache.org 
> wrote:
>
> > I think it can be argued that this is a pretty serious bug for a newly
> > introduced feature, and qualifies for inclusion in an RC, but I don’t
> > personally have a strong opinion on if this should happen.
> >
> > I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> > though.
> >
> > From: Mick Semb Wever 
> > Date: Thursday, 3 June 2021 at 22:45
> > To: dev@cassandra.apache.org 
> > Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
> > Thanks for raising this Stefan.
> >
> >
> >
> > > While I humbly think this is 4.0-worthy, the process we have, as far
> > > as I know, is that there should be only critical fixes in 4.0 so I
> > > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > > still?
> > >
> >
> >
> > I believe the question here is whether this patch is worthy of an
> exception
> > to go to 4.0.x. (i.e. 4.0.1)
> > At this point in time all improvements would be by default slated for 4.x
> > (i.e. 4.1)
> >
> > It does not qualify as a RC critical bug for 4.0.0.
> >
> > Looking at the patch it is simple, and one could almost consider it a
> > security fix on a new 4.0 feature, so I'd say it's a valid exception for
> > 4.0.x.
> > Keen to hear what others think. And how we should go about requesting
> such
> > exceptions for non-bugs during each annual release cycle.
> >
>

Re: Welcome Dinesh Joshi as Cassandra PMC member

[Sumanth Pasupuleti]

Congratulations Dinesh!!

On Wed, Jun 2, 2021 at 4:21 PM J. D. Jordan 
wrote:

> Congrats! Well deserved addition
>
> > On Jun 2, 2021, at 6:10 PM, Paulo Motta 
> wrote:
> >
> > Very happy to see Dinesh as a PMC member, congratulations!
> >
> >> Em qua., 2 de jun. de 2021 às 17:52, Joseph Lynch <
> joe.e.ly...@gmail.com>
> >> escreveu:
> >>
> >> Congratulations Dinesh! Well deserved!
> >>
> >> -Joey
> >>
> >>> On Wed, Jun 2, 2021 at 12:23 PM 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
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Caleb Rackliffe as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Caleb!!

On Sun, May 16, 2021 at 6:29 PM Jeremy Hanna 
wrote:

> Congratulations Caleb!
>
> > On May 14, 2021, at 11:02 PM, Mick Semb Wever  wrote:
> >
> > The PMC members are pleased to announce that Caleb Rackliffe has
> > accepted the invitation to become committer.
> >
> > Thanks heaps Caleb for helping make Cassandra awesome!
> >
> > 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
>
>

Re: Welcome Stefan Miklosovic as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Stefan!!

On Mon, May 3, 2021 at 8:41 AM Brandon Williams  wrote:

> Congratulations, Stefan!
>
> On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer  wrote:
> >
> >  The PMC's members are pleased to announce that Stefan Miklosovic has
> > accepted the invitation to become committer last Wednesday.
> >
> > Thanks a lot, Stefan,  for all your contributions!
> >
> > 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
>
>

Re: [DISCUSSION] Next release roadmap

[Sumanth Pasupuleti]

I plan to work on the following

   1. CASSANDRA-12106
    Blacklisting bad
   partitions - Rework patch and solicit for feedback/review and have it
   committed
   2. CASSANDRA-14557
    Default and
   required keyspace RF - Patch available; solicit for feedback/review and
   have it committed
   3. CASSANDRA-15433
    Pending ranges
   are not recalculated on keyspace creation - patch available; work on jvm
   dtests, solicit for feedback/review, have it committed.
   4. CASSANDRA-8877 
   Querying TTL and writetime for collections
   5. CASSANDRA-15472
    Read failure due
   to exception from metrics-core dependency


On Sun, Apr 11, 2021 at 7:15 PM guo Maxwell  wrote:

>  besides do we need a table level backup and restore solution for cassandra
> ? https://issues.apache.org/jira/browse/CASSANDRA-15402
>

Re: [DISCUSSION] When should we branch 4.0 and unfreeze trunk?

[Sumanth Pasupuleti]

(mostly reiterating) +1 to branching and unfreezing trunk, and to codifying
the release cadence.
Excited about the 4.0 rc! and looking forward to the roadmap discussion!!

On Thu, Mar 25, 2021 at 8:18 AM Paulo Motta 
wrote:

> > My thinking was talking about when to lift the freeze was moot if we
> hadn't branched, and the agreed upon release lifecycle is pretty clear that
> we don't branch until GA. Am I misunderstanding the relationship there?
>
> The proposal of this thread is to branch and lift the freeze before GA.
>
> I agree to this proposal but I'm suggesting we close and codify the release
> cadence discussion from [1] before we lift the freeze, and maybe kick off
> the roadmap discussion but we probably shouldn't block the unfreeze on
> this.
>
> Looking back at the thread from [1] I saw that while we reached an
> agreement on the release cadence, we haven't discussed how we plan to
> ensure the quality of the releases moving forward, so we should also kick
> off this discussion but also don't need to block branching on this.
>
> [1] -
>
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/202101.mbox/%3ccabxe4tqrft9yn9tscd0jcs4qxe4vfeezqqtkbcw16d+3rgg...@mail.gmail.com%3e
>
>
> Em qui., 25 de mar. de 2021 às 12:00, Joshua McKenzie <
> jmcken...@apache.org>
> escreveu:
>
> > >
> > > be very practical and codify our existing agreements
> > > discussed on the mentioned threads before lifting the freeze
> >
> > Ah. My thinking was talking about when to lift the freeze was moot if we
> > hadn't branched, and the agreed upon release lifecycle is pretty clear
> that
> > we don't branch until GA. Am I misunderstanding the relationship there?
> >
> > On Thu, Mar 25, 2021 at 10:56 AM Paulo Motta 
> > wrote:
> >
> > > > That said, I think freezing feature contribution and not branching
> > until
> > > GA like we've newly done with 4.0 is bad for the health of the project
> > >
> > > +1. I think the freeze and branching until GA was atypical and unique
> to
> > > 4.0 and won't be repeated in the upcoming releases. I agree with
> > Sumanth's
> > > proposal on the release doc that branching should not be tied to a
> > specific
> > > release phase but decided independently by the community during the
> > release
> > > process (as it's being done now).
> > >
> > > > I think we should probably discuss the release process separately and
> > > revise our agreements and process based on learnings from this release.
> > >
> > > Just to clarify: I'm not proposing we make a lengthy revision of the
> > > release process, but be very practical and codify our existing
> agreements
> > > discussed on the mentioned threads before lifting the freeze and
> discuss
> > > any remaining concerns (just to ensure we will not leave this for later
> > and
> > > have clear expectations for the next release cycles).
> > >
> > > Em qui., 25 de mar. de 2021 às 11:10, Joshua McKenzie <
> > > jmcken...@apache.org>
> > > escreveu:
> > >
> > > > The current "Release Lifecycle" wiki doc speaks to when we branch:
> > > >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> > > >
> > > > Specifically under "General Availability (GA)":
> > > >
> > > >- A new branch is created for the release with the new major
> > version,
> > > >limiting any new feature addition to the new release branch, with
> > new
> > > >feature development will continue to happen only on trunk.
> > > >
> > > >
> > > > That said, I think freezing feature contribution and not branching
> > until
> > > GA
> > > > like we've newly done with 4.0 is bad for the health of the project.
> > > Also,
> > > > I don't think the project can survive another release cycle as long
> and
> > > as
> > > > exclusionary as the 4.0 release has been (judging by declining
> > > contribution
> > > > volume, declining external ticket creation and interactions, and
> > > db-engine
> > > > indicators of popularity declining), so I think we should probably
> > > discuss
> > > > the release process separately and revise our agreements and process
> > > based
> > > > on learnings from this release.
> > > >
> > > > Just my .02 though as I'm no longer actively involved.
> > > >
> > > > On Thu, Mar 25, 2021 at 9:15 AM Paulo Motta <
> pauloricard...@gmail.com>
> > > > wrote:
> > > >
> > > > > I agree we should start considering branching 4.0 and unfreezing
> > soon,
> > > > but
> > > > > before I think we should:
> > > > > - Close the loop on the agreed points of the "releases after 4.0"
> [1]
> > > and
> > > > > "project roadmap" [2] threads and document the new release
> guidelines
> > > > > post-4.0 so we have a good starting point.
> > > > > - Revisit the previous discussions on unfreezing 4.0 and address
> any
> > > > > remaining concerns that may still be open.
> > > > >
> > > > > Looking forward to this exciting milestone!
> > > > >
> > > > > [1] -
> > > > >
> > > > >
> > > >
> > >
> >
> 

Re: Welcome Berenguer Blasi as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Berenguer!!

On Thu, Mar 25, 2021 at 6:18 AM Paulo Motta 
wrote:

> Congratulations Berenguer, well deserved! Happy to see the project
> recognizing more contributors!
>
> Em qui., 25 de mar. de 2021 às 10:09, Brandon Williams 
> escreveu:
>
> > Congratulations Berenguer! Thank you for your work.
> >
> > On Thu, Mar 25, 2021 at 5:10 AM Benjamin Lerer 
> wrote:
> > >
> > >  The PMC's members are pleased to announce that Berenguer Blasi has
> > > accepted the invitation to become committer today.
> > >
> > > Thanks a lot,  Berenguer,  for all the work you have done!
> > >
> > > 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
> >
> >
>

Re: Project Roadmap

[Sumanth Pasupuleti]

+1 to the idea of the project roadmap and the said benefits for planning.
In my opinion, it certainly does a world of good for visibility on what is
in the works/ what to look forward to for both the developers as well as
users. So long as "allowed work" is not restricted to items in the project
roadmap and developers can still make contributions to work unlisted in the
project roadmap, I think having a project roadmap is certainly a step in
the right direction.

Thanks,
Sumanth

On Mon, Mar 1, 2021 at 1:18 AM Benedict Elliott Smith 
wrote:

> A while back somebody privately raised the idea of a project roadmap to
> me, and I’d like to propose we formally consider it as a project now that
> 4.0 is approaching completion.
>
>
>
> I think there are two major benefits to agreeing a roadmap:
>
>
>
> 1) It helps us to coordinate finite project resources between multiple
> entities, as we can signal to each other what our priorities are, agree to
> prioritise items on the roadmap, and plan cross-organisation capacity
> necessary for each roadmap item.
>
> 2) It signals to the wider user community what to expect, facilitating
> confidence in project health and direction. I think this will be
> particularly helpful as 4.0 is announced, given the extraordinary amount of
> time that passed between 3.11 and 4.0.
>
>
>
> I think of a roadmap as a pre-CEP activity for upcoming releases, items
> thereon beginning the CEP process, with target releases being assigned by
> the roadmap (subject to revision) and project members opting-in to the
> endeavour to deliver for that release.  I don’t think it should lead to
> work progressing only on roadmap items, but that other major endeavours
> (i.e. those entailing large impact to the project, or requiring lots of
> cross-org input) could be put on hold until the earlier roadmap items were
> properly resourced (or the roadmap revised).
>
>
>
> What do people think?
>
>

Re: New Cassandra website for review

[Sumanth Pasupuleti]

Awesome!!

On Fri, Feb 26, 2021 at 3:32 PM Benedict Elliott Smith 
wrote:

> Very nice.
>
> On 26/02/2021, 21:36, "Melissa Logan"  wrote:
>
> Hi all,
>
> We are excited to share the almost-complete Cassandra website design
> (CASSANDRA-16115). Huge thanks to Lorina Poland, Anthony Grosso, Mick
> Semb
> Weaver, Josh Levy, Chris Thornett, Diogenese Topper, and a few others
> who
> contributed to this effort.
>
> Note: There are a few updates to be made prior to launch, but we
> wanted to
> share to get initial input and signoff to begin the final port to
> Antora.
>
> To be completed:
>
>- *Homepage: *The logos are placeholders -- they're being updated
> and
>resized (pulled from case studies page).
>- *Docs* will be added once 4.0 documentation is complete. Design
>will match new site.
>- *Case Studies * logos are being updated and resized, so ignore
> broken
>links.
>
> If you have case studies or resources -- or community photos --
> please reply to me and we'll add.
>
> Site for review: https://cassandra.staged.apache.org/
>
> https://issues.apache.org/jira/browse/CASSANDRA-16115
>
> Melissa Logan
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Welcome Paulo Motta as Cassandra PMC member

[Sumanth Pasupuleti]

Congratulations Paulo!

On Tue, Feb 9, 2021 at 8:10 AM Jasonstack Zhao Yang <
jasonstack.z...@gmail.com> wrote:

> Congrats Paulo!
>
> On Wed, 10 Feb 2021 at 00:03, Ekaterina Dimitrova 
> wrote:
>
> > Congrats! Well done!
> >
> > On Tue, 9 Feb 2021 at 11:02, J. D. Jordan 
> > wrote:
> >
> > > Congrats Paulo! A great addition to the PMC.
> > >
> > > > On Feb 9, 2021, at 9:59 AM, Jonathan Ellis 
> wrote:
> > > >
> > > > Congratulations, Paulo!  Well deserved.
> > > >
> > > >> On Tue, Feb 9, 2021 at 9:54 AM Benjamin Lerer <
> > > benjamin.le...@datastax.com>
> > > >> wrote:
> > > >>
> > > >> The PMC's members are pleased to announce that Paulo Motta has
> > accepted
> > > >> the invitation to become a PMC member yesterday.
> > > >>
> > > >> Thanks a lot, Paulo, for everything you have done for the project
> all
> > > these
> > > >> years.
> > > >>
> > > >> Congratulations and welcome
> > > >>
> > > >> The Apache Cassandra PMC members
> > > >>
> > > >
> > > >
> > > > --
> > > > 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: [DISCUSS] When to stop supporting Python 2

[Sumanth Pasupuleti]

>From the "Supported upgrade path for 4.0" discussion, it seems like there
was consensus around supporting the "3.0 -> 4.0" upgrade path as well (in
addition to 3.11 -> 4.0), so we may need to add python3 support for 3.0 as
well?

Internally. we had a need to make 3.0 cqlsh python3 compatible, and I ended
up backporting trunk pylib, cqlsh, cqlsh.py for python3 support and
reverted https://issues.apache.org/jira/browse/CASSANDRA-14825 (this
backport is currently being tested). Haven't assessed the impact on dtest
environment yet. This approach was much less effort vs cherry-picking
individual changes, but involves probably equal or more testing effort. If
we decide to add python3 support for 3.0, I am happy to contribute this
once we have enough confidence from testing (but unsure if we have
the appetite for this big a change in 3.0).



On Thu, Jan 28, 2021 at 3:01 AM Benjamin Lerer 
wrote:

> Considering the issue with pip. I agree that we should remove support for
> 3.0 and ensure that python 3 is supported by 3.11.
>
> On Wed, Jan 27, 2021 at 8:18 PM Jonathan Ellis  wrote:
>
> > Python 2 was EOLed over a year ago.  I think it's fine to (1) require
> > python 3 to run cqlsh and (2) remove code that supports python 2 whenever
> > it's convenient.
> >
> > Angelo has the right idea that rather than trying to finesse a
> deprecation
> > cycle into 4.0 at this late date, a better migration path can be provided
> > by backporting python3 support to 3.11.
> >
> > On Wed, Jan 27, 2021 at 12:36 PM Brandon Williams 
> > wrote:
> >
> > > On Wed, Jan 27, 2021 at 12:09 PM Adam Holmberg
> > >  wrote:
> > > > I want to emphasize here: to my way of thinking, "dropping support"
> at
> > > this
> > > > juncture is just a matter of documenting it, and maybe introducing a
> > > > warning. We don't need to *remove* support for python2. It will
> > continue
> > > to
> > > > work as-is. This would just guide us in deciding whether to work on
> > flaws
> > > > that are python2-specific, and whether new things are developed with
> > > > backwards compatibility as a forcing concern.
> > >
> > > Actually, I think we have to go a little bit further, and at least as
> > > far as packaging is concerned, remove support for python2.  Recently
> > > pip updated to 21.0 and removed python2 support, which broke any
> > > builds that built artifacts requiring pip.  We now pin pip:
> > >
> > >
> >
> https://github.com/apache/cassandra-builds/commit/54c45a9bcf9b36a3f78b7d773eaf1067483b49b8
> > > to get around this, but highlights that we too need to move away from
> > > anything using python2.  So while we would not modify code to *remove*
> > > python2 support, you would have to invoke python2 on the code in your
> > > own way, since the packages would depend on python3.
> > >
> > > -
> > > 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
> >
>

Re: [DISCUSS] When to stop supporting Python 2

[Sumanth Pasupuleti]

+1 (nb) for dropping support for python2; I agree 4.0 major release is a
good time to do this, given python2 is already EOL.

On Mon, Jan 25, 2021 at 2:00 PM Yifan Cai  wrote:

> +1 nb.
> We probably also want to set a milestone to get rid of the python2
> compatible code completely, if we are going in the direction that drops
> python2 support in 4.0 and retains the python2 compatible code. In 4.x or
> 5.0?
>
> On Mon, Jan 25, 2021 at 9:24 AM Ekaterina Dimitrova  >
> wrote:
>
> > I support the idea,  we are not removing python2-compatible code
> > +1
> >
> > On Fri, 22 Jan 2021 at 15:14, Adam Holmberg 
> > wrote:
> >
> > > As you may recall, CASSANDRA-10190 [1] introduced Python 3 support for
> > > cqlsh. This change will be landing in 4.0. In the course of development
> > and
> > > discussion spanning years, it was decided to retain support for Python
> 2.
> > > In the meantime, Python 2 sunsetted (a year ago [2]). I hadn't seen a
> > > discussion about whether we intend to carry on support for Python 2, so
> > I'm
> > > raising one here.
> > >
> > > 4.0 is a major release and we have an opportunity to drop support at
> this
> > > milestone. It has been mentioned that it will not be acceptable to do
> in
> > a
> > > minor or patch release, so if it's not done for 4.0, we will need to
> wait
> > > for the next major. I do understand that many in the project would like
> > > majors on a more frequent interval post-4.0, but at this time we don't
> > know
> > > when that will be.
> > >
> > > I advocate for dropping support ASAP. I expect that users should not be
> > > inconvenienced by this -- I am not aware of a major distro that has not
> > had
> > > python3 for years. Dropping python2 support does not mean that we would
> > do
> > > work to rip out python2-compatible code, just that we wouldn't
> advertise
> > > support and any package requirements would be adjusted. We benefit by
> > > removing the need to test multiple runtimes, and we wouldn't be
> concerned
> > > with fixing python2-specific issues that may arise on the EOL runtime
> > [3].
> > >
> > > I look forward to the discussion.
> > >
> > > --
> > > Adam Holmberg
> > > e. adam.holmb...@datastax.com
> > > w. www.datastax.com
> > >
> > > [1] https://issues.apache.org/jira/browse/CASSANDRA-10190
> > > [2] https://www.python.org/doc/sunset-python-2/
> > > [3] https://issues.apache.org/jira/browse/CASSANDRA-16400
> > >
> >
>

Re: Welcome Yifan Cai as Cassandra committer

[Sumanth Pasupuleti]

Congratulations Yifan!

On Fri, Dec 25, 2020 at 3:45 AM Berenguer Blasi 
wrote:

> Congrats Yifan!
>
> On 23/12/20 23:59, Wei Deng wrote:
> > Congrats Yifan! So happy to see you taking a bigger role in the
> community!
> >
> > -Wei
> >
> > On Mon, Dec 21, 2020 at 10:10 AM Benjamin Lerer <
> benjamin.le...@datastax.com>
> > wrote:
> >
> >>  The PMC's members are pleased to announce that Yifan Cai has accepted
> the
> >> invitation to become committer last Friday.
> >>
> >> Thanks a lot, Yifan,  for everything you have done!
> >>
> >> 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
>
>

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

[Sumanth Pasupuleti]

Hearty congratulations everyone!!

On Wed, Dec 16, 2020 at 2:53 PM Joshua McKenzie 
wrote:

> Congrats everyone! Great to see new folks joining the project.
>
> On Wed, Dec 16, 2020 at 3:55 PM Dinesh Joshi  wrote:
>
> > Congratulations everyone!
> >
> > Dinesh
> >
> > > On Dec 16, 2020, at 8:55 AM, Benjamin Lerer <
> benjamin.le...@datastax.com>
> > wrote:
> > >
> > > The PMC's members are pleased to announce that Jordan West, David
> > Capwell,
> > > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to
> become
> > > committers this year.
> > >
> > > Jordan West accepted the invitation in April
> > > David Capwell accepted the invitation in July
> > > Zhao Yang accepted the invitation in September
> > > Ekaterina Dimitrova accepted the invitation in December
> > >
> > > Thanks a lot for everything you have done.
> > >
> > > 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
> >
> >
>

Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sumanth Pasupuleti]

+1 to moving v5-beta changes in trunk to new protocol v6.

Regarding 3.11 and v5, I suppose we could say, v5 could never get matured
beyond beta, but not sure if it would be confusing to see v6 while v5 is
still in beta (curious on others' thoughts as well)

On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever  wrote:

> > …move to v6 for the new protocol to avoid this issue
>
>
> +1,  feels more the "grown-up thing to do".
>
>
> > > Perhaps we should skip v5…
> > We could finalise v5 as it was prior to the new framing format, then
> create v6-beta in trunk only with the 15299 changes.
>
>
> Would v5 come out of beta then in 3.11?, or would it stay as beta forever,
> with the focus on maturing v6 in 4.0+?
>

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

[Sumanth Pasupuleti]

Knowing there is a correctness issue in LWT, and given users use LWT
primarily for correctness, my opinion is we should commit the correctness
patch (makes it one of #1, #3 or #4)

I agree we should not cause further delay to 4.0 release (making it one of
#3 or #4).

Con for #3 would be, applications may have to rework their (and
downstreams') configuration(s) to potentially accommodate for the
performance regression which may not be ideal for a seamless 4.0 upgrade
that we expect users to experience.

Now, given this correctness issue has been since the beginning, existing
LWT users would notice no new difference potentially w.r.t. correctness
since they may have already worked around this bug (if they noticed), so +1
to option #4.

On Wed, Nov 11, 2020 at 1:49 PM Benedict Elliott Smith 
wrote:

> In my opinion, a similar calculus should be applied to 3.0 and 3.11.  This
> is a(n arguably quite serious) bug, so whatever is not overly onerous to
> backport should be considered while they are supported. The work under
> discussion has two components: a replacement to the core consensus
> algorithm, and mechanisms to ensure safety across range movements. The
> latter might be more invasive for 3.x, but the former should be quite easy
> to backport and as such probably quite well justified.
>
> > can it also pluggable (either opt-in or opt-out)?
>
> I think pluggable means something different to opt-in/opt-out, at least to
> me.  I'm all for more pluggability, and also for more optionality, but the
> decision is very sensitive to context. We need to be able to select between
> our options, which for consensus practically means supporting live
> migration - which is exceptionally challenging in any general sense (and
> perhaps inherently non-pluggable).
>
> As to future development for consensus, I personally hope the work we are
> discussing here will be a strong platform for it, but obviously that's for
> the community to decide later on. I think the work to take it forwards to
> something epaxos-like will not be that herculean, with some incremental
> milestones en route. But that's a totally different discussion for the
> future, and either a CEP or a small intercollegiate working group.
>
>
> On 11/11/2020, 18:48, "Michael Semb Wever"  wrote:
>
>
> > Regarding CASSANDRA-12126 and 4.0 we are facing several options and
> > Benedict, Sylvain and I wanted to get the community feedback on them.
> >
> > We can:
> >
> >1. Try to use Benedict proposal for 4.0 if the community has the
> >appetite for it. The main issue there is some potential extra
> delay for 4.0
> >2. Do nothing for 4.0. Meaning do not commit the current patch.
> We have
> >lived a long time with that issue and we can probably wait a bit
> more for a
> >proper solution.
> >3. Commit the patch as such, fixing the correctness but
> introducing
> >potentially some performance issue until we release a better
> solution.
> >4. Changing the patch to default to the current behavior but
> allowing
> >people to enable the new one if the correctness is a problem for
> them.
> >
>
>
> If these options are for 4.0, is it then (4) that it is getting
> applied to 3.0 and 3.11 ?
>
> If that is the case then I would vote on also applying (4) to 4.0,
> given we are now in front of beta4. Please let's not further delay 4.0.
>
> Post 4.0, if (1) is as described "a parallel implementation of the
> same underlying Paxos algorithm" can it also pluggable (either opt-in or
> opt-out)? And would/could EPaxos become pluggable too in a similar manner
> (if it eventuates)? I'm in favour on providing more pluggable interfaces
> into C*, along with the code quality improvements that's going to have to
> be accompanied with.
>
>
>
> -
> 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.11.9

[Sumanth Pasupuleti]

Verified unit tests and dtests
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra?branch=3119_tentative
1 Unit test fails (testIndexMemtableSwitching -
org.apache.cassandra.index.sasi.SASIIndexTest), it succeeds on local
isolated execution though.
1 dtest failure (test_closing_connections - thrift_hsha_test.TestThriftHSHA)

+1 (non-binding)


On Thu, Oct 29, 2020 at 5:30 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 3.11.9 for release.
>
> sha1: 5ef75dd96cb693e4041e9ecb61a6852276f0eca4
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.9-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1223/org/apache/cassandra/cassandra-all/3.11.9/
>
> 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.11.9/
>
> 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.11.9-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.9-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.23

[Sumanth Pasupuleti]

Verified Unit tests and DTests.
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra?branch=3023_tentative
One dtest fails (test_closing_connections -
thrift_hsha_test.TestThriftHSHA).

+1 (non binding)

On Thu, Oct 29, 2020 at 5:36 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 3.0.23 for release.
>
> sha1: 31530ff5ac6bd3bacd4b378573a2d191bdab8cd7
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.23-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1222/org/apache/cassandra/cassandra-all/3.0.23/
>
> 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.23/
>
> 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.23-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.23-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 4.0-beta3

[Sumanth Pasupuleti]

Verified unit tests and dtests
https://app.circleci.com/pipelines/github/sumanth-pasupuleti/cassandra?branch=40_beta3_tentative
Observed a dtest failure that seems flaky
test_insert_data_during_replace_same_address -
replace_address_test.TestReplaceAddress
java.lang.IllegalStateException: Unable to contact any seeds!

+1 (non-binding)


On Fri, Oct 30, 2020 at 6:23 AM Jorge Bay Gondra 
wrote:

> Driver smoke tests look good:
>
> https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/36049940
>
> +1 (non-binding)
>
> On Thu, Oct 29, 2020 at 1:29 PM Mick Semb Wever  wrote:
>
> > Proposing the test build of Cassandra 4.0-beta3 for release.
> >
> > sha1: be716b46f2cb3b2d1f01dc225396c6284d5a35de
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta3-tentative
> > Maven Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1224/org/apache/cassandra/cassandra-all/4.0-beta3/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta3/
> >
> > 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/4.0-beta3-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta3-tentative
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supported upgrade path for 4.0

[Sumanth Pasupuleti]

+1 to officially supporting 3.0 to 4.0, in addition to 3.11 to 4.0 upgrade
paths

On Thu, Oct 8, 2020 at 10:33 PM Jeff Jirsa  wrote:

>
> I assumed it would be 3.0.x and 3.11.x
>
> I don’t know why we’d make 3.0-4.0 unofficial/unsupported - there’s no
> technical reason I’ve seen
>
> > On Oct 8, 2020, at 9:21 PM, Anthony Grasso 
> wrote:
> >
> > Hi Josh,
> >
> > This is a really good question. I agree with David about making sure this
> > is clearly documented.
> >
> > As far as the supported upgrade path goes, I think we should officially
> > support only 3.11.x. I do understand the idea of giving users the
> > flexibility to upgrade from 3.0.x. However, the simpler we can make the
> > upgrade path the better. As you mentioned, historically there have been
> > numerous upgrade bugs. To that, having one upgrade path will make
> > maintenance and support easier.
> >
> > Kind regards,
> >
> >> On Fri, 9 Oct 2020 at 07:36, David Capwell  wrote:
> >>
> >> Thanks for bringing this up, we really should document this and make
> sure
> >> the different upgrade paths are clearly documented and have proper
> >> coverage.
> >>
> >> There was a conversation in slack a while back (started from
> >> https://the-asf.slack.com/archives/CK23JSY2K/p1595906733435000) but not
> >> formal or voted on, but the current upgrade targets were 3.0.x and
> 3.11.x
> >> (do others feel we should support other versions as well and if so
> what?).
> >>
> >> For features, COMPACT STORAGE is getting a lot of attention right now,
> so
> >> would love to see clarity on how we go from a cluster with COMPACT
> STORAGE
> >> to 4.0 (is there min version support, what is the upgrade path, what
> about
> >> deleted rows, etc.).
> >>
> >> This is what I know about the current state of 4.0 upgrades at least.
> >>
> >> On Thu, Oct 8, 2020 at 11:48 AM Joshua McKenzie 
> >> wrote:
> >>
> >>> Related JIRA ticket:
> >> https://issues.apache.org/jira/browse/CASSANDRA-15588
> >>>
> >>> Description:
> >>>
> >>> "We've historically had numerous bugs concerning upgrading clusters
> from
> >>> one version to the other. Let's establish the supported upgrade path
> and
> >>> ensure that users can safely perform the upgrades in production."
> >>>
> >>> So the topic of discussion here: what is our supported upgrade path to
> >> 4.0?
> >>> Is this actually documented on our site or in our documentation? Spent
> a
> >>> few minutes poking around and didn't find anything.
> >>>
> >>> Anyone have an opinion here or any formal prior art for us to build on?
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Accept the Harry donation

[Sumanth Pasupuleti]

+1 (non-binding)

On Wed, Sep 16, 2020 at 7:41 AM Jon Meredith  wrote:

> +1 (non-binding)
>
> On Wed, Sep 16, 2020 at 8:28 AM David Capwell
>  wrote:
> >
> > +1
> >
> > Sent from my iPhone
> >
> > > On Sep 16, 2020, at 6:34 AM, Brandon Williams 
> wrote:
> > >
> > > +1
> > >
> > >> On Wed, Sep 16, 2020, 4:45 AM Mick Semb Wever  wrote:
> > >>
> > >> This vote is about officially accepting the Harry donation from Alex
> Petrov
> > >> and Benedict Elliott Smith, that was worked on in CASSANDRA-15348.
> > >>
> > >> The Incubator IP Clearance has been filled out at
> > >> http://incubator.apache.org/ip-clearance/apache-cassandra-harry.html
> > >>
> > >> This vote is a required part of the IP Clearance process. It follows
> the
> > >> same voting rules as releases, i.e. from the PMC a minimum of three
> +1s and
> > >> no -1s.
> > >>
> > >> Please cast your votes:
> > >>   [ ] +1 Accept the contribution into Cassandra
> > >>   [ ] -1 Do not
> > >>
> >
> > -
> > 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: [DISCUSS] CEP-8 Drivers Donation

[Sumanth Pasupuleti]

This is great! +1 to the phased approach mentioned in the document of
starting with the Java driver, and then including the learnings if any into
the rest of the drivers' donation.
Also excited about the documentation donation - it will be nice to not have
to depend on the mentioned proprietary tool, but I guess we will have to
weigh that against the current void in Apache C* documentation and as long
as there is a good path forward by at least identifying a replacement tool
(if not migrating), it should fine I suppose.

Thanks,
Sumanth

On Mon, Jul 27, 2020 at 2:54 PM Dinesh Joshi  wrote:

> Alexandre,
>
> I gave the document a quick read and TL;DR seems to be that we'd like to:
>
> 1. Bring in all drivers
> 2. They're part of the C* project
>
> If so, I would prefer if we add the Java driver first to the project.
> Based on that experience we can move forward with other drivers. However, I
> am open to the idea of adding all the drivers to the project.
>
> Please correct me if I misunderstood something.
>
> Thanks,
>
> Dinesh
>
> > On Jul 26, 2020, at 8:41 PM, Nate McCall  wrote:
> >
> > This is fantastic, Alexandre, thanks for putting this together!
> >
> > I put an initial set of comments/concerns on there and will loop back
> later
> > this week after other folks have  a go.
> >
> > Cheers,
> > -Nate
> >
> > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra <
> > alexandre.du...@datastax.com> wrote:
> >
> >> Hi,
> >>
> >> As per the CEP process guidelines, I'm starting a formal DISCUSS
> >> thread to resume the conversation
> >> started here[1].
> >>
> >> On behalf of the developers who maintain the DataStax drivers, I
> >> confirm that we are offering to
> >> donate to the Apache Software Foundation all seven DataStax-funded
> >> drivers, and are therefore
> >> opening this CEP[2] to discussion.
> >>
> >> In the CEP document linked above, we tried our best to address all the
> >> issues that we anticipate
> >> going forward with this endeavor, but the task is big: your
> >> suggestions, remarks and comments are
> >> most welcome.
> >>
> >> As stated previously, we understand that we're all primarily focused
> >> on the C* 4.0 release
> >> currently; therefore we don't mind deferring any concrete progress on
> >> this until after C* 4.0 is
> >> out.
> >>
> >> However, as you can judge from the CEP draft document, the donation is
> >> likely to have many
> >> implications on sensitive areas, e.g. on project governance; which is
> >> why we think best to open the
> >> discussion as early as possible, so that we all have enough time to
> >> determine what we think best
> >> suits the project going forward.
> >>
> >> Kind regards,
> >>
> >> Alex Dutra
> >>
> >> [1]
> >>
> https://lists.apache.org/thread.html/ra7caa1dd42ccaa04bcabfbc33233995c125c655f9a3cdb2c7bd8e9f7%40%3Cdev.cassandra.apache.org%3E
> >> [2]
> >>
> https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit?usp=sharing
> >>
> >> --
> >> Alexandre Dutra
> >> alexandre.du...@datastax.com
> >>
> >> -
> >> 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.11.7

[Sumanth Pasupuleti]

Ran following circleCI tests
j8_unit_tests (1 failing) - testIndexMemtableSwitching -
org.apache.cassandra.index.sasi.SASIIndexTest with exception
junit.framework.AssertionFailedError: expected:<0> but was:<1>, at
org.apache.cassandra.index.sasi.SASIIndexTest.testIndexMemtableSwitching(SASIIndexTest.java:2379)
j8_jvm_dtests (PASS)
j8_dtests (3 failing, each in with vnodes and no-vnodes)


On Wed, Jul 15, 2020 at 12:23 PM Eric Evans  wrote:

> +1
>
> On Tue, Jul 14, 2020 at 5:47 PM Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 3.11.7 for release.
> >
> > sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.7/
> >
> > 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.11.7/
> >
> > 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.
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative
>
>
>
> --
> Eric Evans
> eev...@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.21

[Sumanth Pasupuleti]

Ran following circleCI tests
j8_unit_tests (PASS)
j8_jvm_dtests (PASS)
j8_dtests (5 failures, in each of with vnodes, and no-vnodes)

On Tue, Jul 14, 2020 at 3:50 PM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 3.0.21 for release.
>
> sha1: e39d1da325f5853ab3a64d92ecf52f8271239b9e
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.21-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1208/org/apache/cassandra/cassandra-all/3.0.21/
>
> 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.21/
>
> 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.
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.21-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.21-tentative
>

Re: [VOTE] Release Apache Cassandra 2.2.17

[Sumanth Pasupuleti]

Ran following CircleCI tests
j8_unit_tests (PASS)
j8_jvm_dtests (1 failure "namedDcTest -
org.apache.cassandra.distributed.test.NetworkTopologyTest" with
"java.util.concurrent.TimeoutException")
j8_dtests (60 failures in no-vnodes (all of them are
from cqlsh_tests/test_cqlsh.py), 62 failures in vnodes
(cqlsh_tests/test_cqlsh.py, bootstrap_test.py, rebuild_test.py)

On Thu, Jul 16, 2020 at 9:41 AM Brandon Williams  wrote:

> +1
>
> On Tue, Jul 14, 2020 at 5:53 PM Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 2.2.17 for release.
> >
> > sha1: cd006d275aa9b6e937c6ebd036d4d27c4ed18dbe
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.17-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1207/org/apache/cassandra/cassandra-all/2.2.17/
> >
> > The Source and Build Artifacts, and the Debian and RPM packages and
> > repositories, are available here:
> > https://dist.apache.org/repos/dist/dev/cassandra/2.2.17/
> >
> > 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.
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.17-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.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 4.0-beta1

[Sumanth Pasupuleti]

+1 nb
Ran following CircleCI tests
j8_unit_tests (PASS)
j8_jvm_dtests (PASS)
j8_dtests (PASS)

On Thu, Jul 16, 2020 at 10:18 AM Jordan West  wrote:

> +1 nb
>
> On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai  wrote:
>
> > +1 nb
> >
> > 
> > From: Robert Stupp 
> > Sent: Thursday, July 16, 2020 2:59:34 AM
> > To: dev@cassandra.apache.org 
> > Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1
> >
> > +1 (nb)
> >
> > —
> > Robert Stupp
> > @snazy
> >
> > > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang <
> > zhaoyangsingap...@gmail.com> wrote:
> > >
> > > +1 (nb)
> > >
> > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams 
> wrote:
> > >
> > >> +1 (binding)
> > >>
> > >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever  wrote:
> > >>
> > >>> Proposing the test build of Cassandra 4.0-beta1 for release.
> > >>>
> > >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004
> > >>> Git:
> > >>>
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> > >>> Maven Artifacts:
> > >>>
> > >>>
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/
> > >>>
> > >>> The Source and Build Artifacts, and the Debian and RPM packages and
> > >>> repositories, are available here:
> > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/
> > >>>
> > >>> 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
> > >> -1s.
> > >>>
> > >>> Eventual publishing and announcement of the 4.0-beta1 release will be
> > >>> coordinated, as described in
> > >>>
> > >>>
> > >>
> >
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> > >>>
> > >>> [1]: CHANGES.txt:
> > >>>
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> > >>> [2]: NEWS.txt:
> > >>>
> > >>>
> > >>
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
> > >>>
> > >>
> >
> >
>

Re: [DISCUSS] Revisiting Java 11's experimental status

[Sumanth Pasupuleti]

We at Netflix have been testing 4.0 on Java 8, and we do not plan to
use Java 11 yet for C*, since we are, and for the considerable future will
be running Java 8 only in production.

On Mon, Jul 13, 2020 at 2:41 PM Patrick McFadin  wrote:

> JDK8 seems like the safe devil we know, but in the interest of trying to
> gather a bit of data, I just posted a twitter poll.
>
> https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
>
>
> On Mon, Jul 13, 2020 at 12:26 PM Elliott Sims 
> wrote:
>
> > Personally, I'd planned to upgrade to 4.0 on JDK8 but only wait a few
> weeks
> > before starting to update to JDK11 afterwards.  Everything else we run's
> > been updated to JDK11, so the Cassandra clusters are the odd one out at
> > this point.
> >
> > On Mon, Jul 13, 2020 at 12:19 PM Jordan West  wrote:
> >
> > > Thanks for bringing this up Jon! My current thinking is we should
> > > officially support both 8 and 11. That increases the surface area we
> need
> > > to test but I think its hard to predict what different users will run
> > given
> > > the current transition in the Java landscape.
> > >
> > > Jordan
> > >
> > > On Mon, Jul 13, 2020 at 11:42 AM Jon Haddad  wrote:
> > >
> > > > Support for Java 11 was added a long time ago, and it's been about 2
> > > years
> > > > since it was released (Sept 2018).  Had we released Cassandra 4 close
> > to
> > > > that date, I'd be fine with keeping the status as experimental, but
> at
> > > this
> > > > point I'm wondering if releasing a new major version of C* that's
> > > primarily
> > > > targeting Java 8 as the only "official" supported version is a good
> > idea.
> > > >
> > > > To those of you that are planning on rolling out C* 4.0, are you
> > planning
> > > > on using Java 8 still, or moving to 11?  Speaking for myself, I can
> > say I
> > > > don't think I'd want to use 8 anymore.  If most folks are testing
> with
> > 11
> > > > at this point, I think we should consider making 11 the recommended
> > > version
> > > > and really only encouraging Java 8 for legacy purposes - teams who
> > have a
> > > > restriction that prevents them from upgrading.
> > > >
> > > > To those of you planning on moving to 4.0 soon after it's release,
> are
> > > you
> > > > planning on deploying to JDK 11 or 8?
> > > >
> > > > [1]
> > > https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > > >
> > >
> >
>

Re: Scope of CASSANDRA-14557 (Default and Minimum RF)

[Sumanth Pasupuleti]

I agree. I've updated the patch in 14557 to include a note about
application to system keyspaces in cassandra.yaml.

On Mon, May 18, 2020 at 1:59 AM Oleksandr Petrov 
wrote:

> I think it is reasonable that system keyspaces would get initialized with a
> default replication factor, assuming ones that were already
> initalized would remain intact (however, this should be the same for
> user-created keyspaces).
>
> Assuming it doesn't change the current behaviour, and default and min rf,
> when unset, act the same way current version would, the only thing we
> should probably add is a line in cassandra.conf that default and min
> replication factors will also apply to system keyspaces.
>
> On Wed, May 13, 2020 at 9:01 PM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Hi,
> >
> > Based on Alex's suggestion on the ticket, wanted to reach out to clarify
> on
> > the current scope of  default and minimum replication factors that 14557
> > defines, and gather thoughts to farm for dissent.
> >
> > Both the configurations (default and minimum) apply not just to user
> > keyspaces, but also to system keyspaces. For instance, this can be handy
> in
> > deployments that use authenticated C* clusters where operators have to
> > "remember" to set system_auth keyspace's RF to a value higher than 1. In
> > such cases, setting default_rf = 3 for example (which I suppose is common
> > in most deployments) would ensure all the system keyspaces (including
> > system_auth) come up with RF=3.
> >
> > It can be helpful to note that, this patch by default does not cause any
> > change to the replication factors, reason being, the default values of
> > these configurations are set to [defaultRF=1, minimumRF=0] to not induce
> > any changes that folks may not expect, but rather offers knobs to define
> > what a sane default RF should be, and have a gate on any new keyspaces
> > being created with an RF lower than minimumRF.
> >
> > Curious to know your thoughts.
> >
> > Thanks,
> > Sumanth
> >
>
>
> --
> alex p
>

Scope of CASSANDRA-14557 (Default and Minimum RF)

[Sumanth Pasupuleti]

Hi,

Based on Alex's suggestion on the ticket, wanted to reach out to clarify on
the current scope of  default and minimum replication factors that 14557
defines, and gather thoughts to farm for dissent.

Both the configurations (default and minimum) apply not just to user
keyspaces, but also to system keyspaces. For instance, this can be handy in
deployments that use authenticated C* clusters where operators have to
"remember" to set system_auth keyspace's RF to a value higher than 1. In
such cases, setting default_rf = 3 for example (which I suppose is common
in most deployments) would ensure all the system keyspaces (including
system_auth) come up with RF=3.

It can be helpful to note that, this patch by default does not cause any
change to the replication factors, reason being, the default values of
these configurations are set to [defaultRF=1, minimumRF=0] to not induce
any changes that folks may not expect, but rather offers knobs to define
what a sane default RF should be, and have a gate on any new keyspaces
being created with an RF lower than minimumRF.

Curious to know your thoughts.

Thanks,
Sumanth

Re: Discussion: addition to CEP guide

[Sumanth Pasupuleti]

+1 (nb)

On Fri, Apr 24, 2020 at 8:01 PM Dinesh Joshi  wrote:

> +1
>
> > On Apr 24, 2020, at 5:37 PM, Joshua McKenzie 
> wrote:
> >
> > Updated. Thanks for the feedback.
> >
> > On Fri, Apr 24, 2020 at 8:08 PM sankalp kohli 
> > wrote:
> >
> >> +1
> >>
> >> On Thu, Apr 23, 2020 at 6:07 AM Andrés de la Peña <
> >> a.penya.gar...@gmail.com>
> >> wrote:
> >>
> >>> +1 (nb)
> >>>
> >>> On Thu, 23 Apr 2020 at 13:09, Aleksey Yeshchenko
> >>  
> >>> wrote:
> >>>
>  +1
> 
> > On 23 Apr 2020, at 12:58, Benjamin Lerer <
> >> benjamin.le...@datastax.com>
>  wrote:
> >
> > +1 for both
> >
> >
> >
> > On Thu, Apr 23, 2020 at 3:49 AM Jordan West 
> >>> wrote:
> >
> >> +1 (nb) on both counts. Thanks for bringing this up!
> >>
> >> Jordan
> >>
> >> On Wed, Apr 22, 2020 at 11:53 AM Joshua McKenzie <
> >>> jmcken...@apache.org>
> >> wrote:
> >>
> 
>  Maybe put it high up the list, e.g. after Description of Approach?
> >>>
> >>> Really great point. Definitely not the lowest priority item.
> >>>
> >>> I'll leave this thread open for another 24 or 48 for feedback; if
> >>> noncontroversial I'll edit then.
> >>>
> >>> On Wed, Apr 22, 2020 at 1:45 PM Scott Andreas <
> >> sc...@paradoxica.net>
> >>> wrote:
> >>>
>  Sounds good to me as well, thanks for suggesting.
> 
>  
>  From: Jon Haddad 
>  Sent: Wednesday, April 22, 2020 9:54 AM
>  To: dev@cassandra.apache.org
>  Subject: Re: Discussion: addition to CEP guide
> 
>  Great idea Josh, +1
> 
>  On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith <
>  bened...@apache.org>
>  wrote:
> 
> > +1.  This might also serve to produce specific points of
> >> discussion
>  around
> > the topic as the CEP progresses.
> >
> > Maybe put it high up the list, e.g. after Description of
> >> Approach?
> >
> >
> >
> > On 22/04/2020, 17:40, "Joshua McKenzie" 
> >> wrote:
> >
> >   Link to CEP guide:
> >
> >
> 
> >>>
> >>
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> >
> >   Currently the CEP guide reads:
> >   ---
> >
> >   *A CEP should contain the following sections: *
> >
> >  -
> >
> >  *Scope,*
> >  -
> >
> >  *Goals (and non-goals),*
> >  -
> >
> >  *Description of Approach,*
> >  -
> >
> >  *Timeline,*
> >  -
> >
> >  *Mailing list / Slack channels,*
> >  -
> >
> >  *Related JIRA tickets.*
> >
> >   --
> >   What does everyone think about adding another bullet item as
> >>> follows:
> >
> >  - A test plan covering performance, correctness, failure,
> >> and
> > boundary
> >  conditions (as applicable)
> >
> >   --
> >   Or some variation thereof. I personally think it's worth
> >> calling
> >>> out
> > "We
> >   should think about and discuss how we're going to test
> >> something
>  from a
> >   high level collectively before we dive into it", since we've
> >> had
> >>> some
> > pain
> >   in the past in that area.
> >
> >   Thoughts?
> >
> >
> >
> >
> >
> >>> -
> > 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
>
>

Re: [VOTE] Release Apache Cassandra 2.2.16

[Sumanth Pasupuleti]

+1 non-binding

All UTs and Dtests pass except for two (thrift_hsha_test.TestThriftHSHA,
bootstrap_test.TestBootstrap)
https://circleci.com/workflow-run/f4e396c5-36f8-4db4-ac8c-6f0578f217a0

On Thu, Feb 13, 2020 at 2:16 AM Mick Semb Wever  wrote:

>
> > 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.
>
>
>
> +1 (non-binding)
>
> Checked:
>  - gpg signatures (maven artefacts, dist artefacts, deb/rpm packages and
> repositories),
>  - sha checksums (maven artefacts, dist artefacts, deb/rpm packages and
> repositories),
>  - binary convenience artefact runs
>  - src convenience artefacts builds with one command, and runs
>  - deb and rpm install and run
>
> Remaining issues:
>  - deb package built fresh from git sha, instead of re-using the dist src
> artefact (CASSANDRA-14962)
>  - sha256 and sha512 files don't include the original filename (they are a
> bit clumsy to verify)
>  - binary convenience artefact contains javadoc (CASSANDRA-15561)
>  - lib/ directory (binary files) bundled into the src artefact
>
> Test Results:
>  -
> https://builds.apache.org/view/A-D/view/Cassandra%202.2/job/Cassandra-2.2/16/testReport/
>  -
> https://lists.apache.org/thread.html/r54e549fde8efe400233fd3d3ad7e7d60f97ce8f7039ec462dce1009e%40%3Cbuilds.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.6

[Sumanth Pasupuleti]

+1 non-binding

All UTs and Dtests pass except for two (thrift_hsha_test.TestThriftHSHA,
bootstrap_test.TestBootstrap)
https://circleci.com/workflow-run/6fa3a0ac-98c9-40d9-be07-058b80b99738


On Thu, Feb 13, 2020 at 7:44 AM Jorge Bay Gondra 
wrote:

> I've run part of the node.js driver integration test suite against it,
> looks good.
>
> +1 (non-binding)
>
> On Thu, Feb 13, 2020 at 1:18 PM Tommy Stendahl
>  wrote:
>
> > +1 NB
> >
> > On tis, 2020-02-11 at 09:38 +0100, Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.11.6 for release.
> >
> > sha1: cb779ab9a631c13a245926f55320392c4468c6f0
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.6-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1194/org/apache/cassandra/cassandra-all/3.11.6/
> >
> > 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.11.6/
> >
> > 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.
> >
> > Again note the release process is undergoing improvements to deal with
> > sha256|512 checksums and to use the ASF dev dist staging location. Please
> > be extra critical. The deb and rpm repositories are also now available to
> > verify before the vote.
> >
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.6-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.6-tentative
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > dev-unsubscr...@cassandra.apache.org>
> > For additional commands, e-mail: dev-h...@cassandra.apache.org > dev-h...@cassandra.apache.org>
> >
> >
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

[Sumanth Pasupuleti]

Java8 Test run summary for 4.0-alpha3-tentative
Passing UTs: https://circleci.com/gh/sumanth-pasupuleti/cassandra/852
Passing jvm_dtests: https://circleci.com/gh/sumanth-pasupuleti/cassandra/853
1 failing dtest (
https://circleci.com/gh/sumanth-pasupuleti/cassandra/855#tests/containers/92
,
https://circleci.com/gh/sumanth-pasupuleti/cassandra/854#tests/containers/96
)
test_datetime_values - cqlsh_tests.test_cqlsh.TestCqlsh
cqlsh_tests/test_cqlsh.py

more
AssertionError: Failed to execute cqlsh: :13:InvalidRequest:
Error from server: code=2200 [Invalid query] message="Unable to coerce
'1582-1-1' to a formatted date (long)"   :15:InvalidRequest:
Error from server: code=2200 [Invalid query] message="Unable to coerce
'0-1-1' to a formatted date (long)"   :17:InvalidRequest: Error
from server: code=2200 [Invalid query] message="Unable to coerce
'1-1-1' to a formatted date (long)"   :19:InvalidRequest: Error
from server: code=2200 [Invalid query] message="Unable to coerce
'-1-1' to a formatted date (long)"   :21:InvalidRequest:
Error from server: code=2200 [Invalid query] message="Unable to coerce
'1-1-1' to a formatted date (long)"assert 0 == 680  +  where
680 = len(':13:InvalidRequest: Error from server: code=2200
[Invalid query] message="Unable to coerce \'1582-1-1\' to a f...st:
Error from server: code=2200 [Invalid query] message="Unable to coerce
\'1-1-1\' to a formatted date (long)"\n')


Thanks,
Sumanth

On Mon, Feb 3, 2020 at 7:09 PM Michael Shuler 
wrote:

> On 2/3/20 5:21 PM, Mick Semb Wever wrote:
> >
> >> Summary of notes:
> >> - Artifact set checks out OK with regards to key sigs and checksums.
> >> - CASSANDRA-14962 is an issue when not using the current deb build
> >> method (using new docker method results in different source artifact
> >> creation & use). The docker rpm build suffers the same source problem
> >> and the src.rpm is significantly larger, since I think it copies all the
> >> downloaded maven artifacts in. It's fine for now, though :)
> >> - UNRELEASED deb build
> >
> >
> > Thanks for the thorough review Michael.
> >
> > I did not know about CASSANDRA-14962, but it should be easy to fix now
> that the -src.tar.gz is in the dev dist location and easy to re-use. I'll
> see if I can create a patch for that (aiming to use it on alpha4).
>
> Yep! Similarly, the rpm build has been wrong all along, but it's what we
> have. The -src.tar.gz should get copied to /$build/$path/SOURCE dir, I
> think it is(?). I think that might cure the larger .src.rpm.
>
> > And I was unaware of the UNRELEASED version issue. I can put a patch in
> for that too, going into the prepare_release.sh script.
>
> `dch -r` is usually a step I do before building, also checking NEWS and
> CHANGES and build.xml versions all align. Then the correct commit gets
> -tentative tagged. Building `dch -r` in would be OK, if all the other
> ducks are in a row.
>
> >> Next step
> >> would be to do each package-type install and startup functional testing,
> >> but I don't have that time right now :)
> >
> >
> > I'm going to presume others that have voted have done package-type
> installs and the basic testing, and move ahead. If I close the vote, I will
> need your help Michael with the final steps running the patched
> finish_release.sh from the `mck/14970_sha512-checksums` branch, found in
> https://github.com/thelastpickle/cassandra-builds/blob/mck/14970_sha512-checksums/
> >  Because only PMC can `svn move` the files into
> dist.apache.org/repos/dist/release/
>
> I usually do this before vote. I don't know how many other people, if
> any, test that all the packages can install and start.
>
> > And for the upload_bintray.sh script, how do I get credentials, an infra
> ticket i presume? (ie to https://bintray.com/apache )
>
> If I recall, I did an infra ticket with my github user id - this is how
> I log in. Once logged into bintray, you can find a token down in the
> user profile somewhere, which is used in the script.
>
> Thanks again for walking through these steps.
>
> Michael
>
> -
> 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

[Sumanth Pasupuleti]

+1

On Fri, Nov 1, 2019 at 2:55 PM Joseph Lynch  wrote:

> +1
>
> -Joey
>
> On Fri, Nov 1, 2019 at 5:33 AM 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
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.11.5

[Sumanth Pasupuleti]

CircleCi test runs (
https://circleci.com/workflow-run/92c41011-b4d1-4dc5-9d21-8fbb2950a5f1):
j8_unit_tests: Pass
j8_jvm_dtests: Pass
j8_dtests-no-vnodes: 1 failure (test_closing_connections -
thrift_hsha_test.TestThriftHSHA)
j8_dtests-no-vnodes: 1 failure (test_closing_connections -
thrift_hsha_test.TestThriftHSHA)

On Fri, Oct 25, 2019 at 6:34 AM Aleksey Yeshchenko
 wrote:

> +1
>
> > On 24 Oct 2019, at 18:26, Michael Shuler  wrote:
> >
> > I propose the following artifacts for release as 3.11.5.
> >
> > sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
> > Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/
> > Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/
> >
> > 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.5-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-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: [VOTE] Release Apache Cassandra 3.0.19

[Sumanth Pasupuleti]

CircleCi test runs (
https://circleci.com/workflow-run/b8abe6cf-1584-4937-958c-0dc1280e2f3a):
j8_unit_tests: Pass
j8_jvm_dtests: Pass
j8_dtests-no-vnodes: 1 failures (test_closing_connections -
thrift_hsha_test.TestThriftHSHA)
j8_dtests-no-vnodes: 1 failures (test_closing_connections -
thrift_hsha_test.TestThriftHSHA)

On Fri, Oct 25, 2019 at 6:41 AM Aleksey Yeshchenko
 wrote:

> +1
>
> > On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> >
> > I propose the following artifacts for release as 3.0.19.
> >
> > sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
> > Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/
> > Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/
> >
> > 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.19-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.19-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: [VOTE] Release Apache Cassandra 2.2.15

[Sumanth Pasupuleti]

CircleCi test runs (
https://circleci.com/workflow-run/2ca1a202-7505-431d-87d3-c0f93b14bddd):
j8_unit_tests: Pass
j8_jvm_dtests: Pass
j8_dtests-no-vnodes: 3 failures (test_short_read_delete -
consistency_test.TestConsistency, test_simple_rebuild -
rebuild_test.TestRebuild, test_closing_connections -
thrift_hsha_test.TestThriftHSHA)
j8_dtests-no-vnodes: 3 failures (test_short_read_delete -
consistency_test.TestConsistency, test_simple_rebuild -
rebuild_test.TestRebuild, test_closing_connections -
thrift_hsha_test.TestThriftHSHA)



On Fri, Oct 25, 2019 at 6:33 AM Aleksey Yeshchenko
 wrote:

> +1
>
> > On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> >
> > I propose the following artifacts for release as 2.2.15.
> >
> > sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
> > Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
> > Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/
> > Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/
> >
> > 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.15-tentative
> > [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-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: Can we kick off a release?

[Sumanth Pasupuleti]

Looks like https://issues.apache.org/jira/browse/CASSANDRA-15363 is in
"Ready to Commit" state. Can we have this committed, before cutting the
next set of releases?

Thanks,
Sumanth

On Wed, Oct 23, 2019 at 8:13 AM Blake Eggleston
 wrote:

> Looks like 15193 has been committed. Are we waiting on anything else
> before cutting the next set of releases?
>
> > On Oct 8, 2019, at 1:11 PM, Jon Haddad  wrote:
> >
> > I forgot to mention, we should also release alpha2 of 4.0.
> >
> >
> > On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler 
> > wrote:
> >
> >> Thanks Sam, I'm following #15193 and should catch the status change
> there.
> >>
> >> Michael
> >>
> >> On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe  wrote:
> >>>
> >>> CASSANDRA-15193 just got +1’d yesterday and would be good to include in
> >> the 3.0 and 3.11 releases. If you don’t mind holding off while I add a
> >> cqlsh test and merge it, that’d be good.
> >>>
> >>> Thanks,
> >>> Sam
> >>>
>  On 7 Oct 2019, at 22:54, Michael Shuler 
> >> wrote:
> 
>  Will do! I probably won't get this done this evening, so will send out
>  the emails tomorrow.
> 
>  Thanks,
>  Michael
> 
>  On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad  wrote:
> >
> > Michael,
> >
> > Would you mind kicking off builds and starting a vote thread for the
> >> latest
> > 2.2, 3.0 and 3.11 builds?
> >
> > Much appreciated,
> > Jon
> 
>  -
>  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
>
>

Re: [VOTE] Apache Cassandra Release Lifecycle

[Sumanth Pasupuleti]

Thank you, Scott!
I've moved the document content (along with outstanding comments) into
cwiki at
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle.
Made the GDoc deprecated and view-only, and left breadcrumbs to the cwiki
in both the jira  as
well as the GDoc

.

On Mon, Oct 7, 2019 at 12:26 PM Jordan West  wrote:

> +1 nb — to both the document and the benefits listed in Scott’s email.
>
> Jordan
>
> On Fri, Oct 4, 2019 at 2:26 PM Scott Andreas  wrote:
>
> > There are two main benefits to agreeing on this:
> >
> > 1. Providing clarity for contributors on release phases – i.e., what
> types
> > of changes are expected to land or be deferred during a particular point
> in
> > that cycle.
> >
> > 2. Providing semantic clarity to users of Cassandra in terms of what they
> > can expect from a given release.
> >
> > The second one is more important. The document stands as a commitment
> > between the Cassandra project and its users regarding what can be
> expected
> > from each type of release. It defines GA releases as "recommended for
> > production deployment for all users," setting a standard of quality that
> we
> > aim to uphold together and that users can depend on. Affirming what it
> > means for a release to be EOL, deprecated, or in maintenance signals
> > importance of upgrading to a GA version.
> >
> > The prerelease phases set expectations for us as contributors to produce
> a
> > more stable release: what type of testing/validation is needed at what
> > time, at which point interfaces/protocols solidify, when a release is
> > considered feature complete, etc.
> >
> > Creating clarity for ourselves will help us build a better database, and
> > creating clarity for our users will help give them the confidence to run
> it.
> >
> > I want to thank Sumanth for his work on this document and to everyone
> else
> > who's contributed.
> >
> > I support it (+1 nb).
> >
> > – Scott
> >
> > 
> > From: Stefan Podkowinski 
> > Sent: Tuesday, October 1, 2019 1:43 PM
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE] Apache Cassandra Release Lifecycle
> >
> > What exactly will be the implication of the outcome of this vote, in
> > case the content is agreed upon? What's the proposal of the voting?
> >
> > The document seems to be informative rather then formal. It's verbose on
> > definitions that should be commonly understood or can only broadly
> > defined (what is alpha/beta/RC, GA for production, etc.), while at the
> > same time is unclear and weasel-wordy on our actual commitment and rules.
> >
> >
> > On 30.09.19 20:51, sankalp kohli wrote:
> > > Hi,
> > >  We have discussed in the email thread[1] about Apache Cassandra
> > Release
> > > Lifecycle. We came up with a doc[2] for it. Please vote on it if you
> > agree
> > > with the content of the doc[2].
> > >
> > > Thanks,
> > > Sankalp
> > >
> > > [1]
> > >
> >
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > > [2]
> > >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> > >
> >
> > -
> > 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] Apache Cassandra Release Lifecycle

[Sumanth Pasupuleti]

I made a couple of additional changes to the document based on the
comments, and there are a couple more that need to be addressed.

I will work on moving this document to cwiki.

Thanks,
Sumanth

On Tue, Oct 1, 2019 at 10:02 AM Dinesh Joshi  wrote:

> There are a few points that need to be clarified in doc. I am also fine if
> we want to adopt the document as-is and then refine it as we build
> experience with the process.
>
> Dinesh
>
> > On Sep 30, 2019, at 3:24 PM, sankalp kohli 
> wrote:
> >
> > Sure..lets do that.
> >
> > On Mon, Sep 30, 2019 at 3:21 PM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >> Perhaps we should move the proposed document to the cwiki for purposes
> of
> >> voting?  That way it's in a place owned by the project, with a permanent
> >> history.  Otherwise it's not entirely clear what was voted on.
> >>
> >>
> >> On 30/09/2019, 20:10, "Sumanth Pasupuleti" <
> >> sumanth.pasupuleti...@gmail.com> wrote:
> >>
> >>+1
> >>
> >>On Mon, Sep 30, 2019 at 12:00 PM Nate McCall 
> >> wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, Oct 1, 2019 at 7:52 AM sankalp kohli  >>>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>We have discussed in the email thread[1] about Apache Cassandra
> >>> Release
> >>>> Lifecycle. We came up with a doc[2] for it. Please vote on it if
> >> you
> >>> agree
> >>>> with the content of the doc[2].
> >>>>
> >>>> Thanks,
> >>>> Sankalp
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> >>>> [2]
> >>>>
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >> -
> >> 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] Apache Cassandra Release Lifecycle

[Sumanth Pasupuleti]

+1

On Mon, Sep 30, 2019 at 12:00 PM Nate McCall  wrote:

> +1
>
> On Tue, Oct 1, 2019 at 7:52 AM sankalp kohli 
> wrote:
>
> > Hi,
> > We have discussed in the email thread[1] about Apache Cassandra
> Release
> > Lifecycle. We came up with a doc[2] for it. Please vote on it if you
> agree
> > with the content of the doc[2].
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/c610b23f9002978636b66d09f0e0481ed3de9b78895050da22c91c6f@%3Cdev.cassandra.apache.org%3E
> > [2]
> >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#heading=h.633eppni91tw
> >
>

Re: 4.0 Max TTL

[Sumanth Pasupuleti]

We will have to deal with fixing this TTL issue eventually as more users
start to deal with the boundaries of currently allowed TTL (which keeps
declining). It will be neat if we can get this into 4.0 before it is
released - be it in beta or future 4.0 alpha(s) - the sooner the better, as
everyone in the community gets busy validating 4.0 bits.

Thanks,
Sumanth

On Tue, Sep 17, 2019 at 7:33 AM Benedict Elliott Smith 
wrote:

> 1.During ApacheCon, Laxmikant approached me to discuss
> CASSANDRA-14227.  It was also raised on the list back in January.
>
>
>
> Taking a closer look, it probably is not very difficult for us to fix this
> – either by treating the int as unsigned, or by widening it to a long
> value.  Since this can only easily be done once per major version, and the
> number of representable dates is steadily declining, there’s a strong case
> to be made for delivering this for 4.0-beta.
>
>
>
> The least invasive change is probably to simply permit negative values,
> and to treat them as unsigned.  However, this or using long would both be
> modest changes.
>
>
>
> Does anyone have any strong thoughts or opinions on this?
>
>

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

One more call for any additional comments/ feedback on the release
lifecycle document
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#

Thanks,
Sumanth

On Sat, Jul 27, 2019 at 1:01 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Submitted patch to add release lifecycle information to the website
> https://issues.apache.org/jira/browse/CASSANDRA-15249
>
> On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov <
> oleksandr.pet...@gmail.com> wrote:
>
>> Maybe a bit off-topic:
>>
>> Before we cut a release, we should make sure we take care of beta protocol
>> [1], include released driver versions [2] and remove compact storage
>> remainders [3]. Third one is optional, but I'd argue we should do it
>> sooner
>> rather than later.
>>
>> [1] https://issues.apache.org/jira/browse/CASSANDRA-14973
>> [2] https://issues.apache.org/jira/browse/CASSANDRA-13951
>> [3] https://issues.apache.org/jira/browse/CASSANDRA-13994
>>
>>
>>
>> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti <
>> sumanth.pasupuleti...@gmail.com> wrote:
>>
>> > Thanks for the feedback Scott. I have incorporated all the incremental
>> > feedback I have thus far.
>> >
>> > Looking for any additional feedback folks may have.
>> >
>> >
>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
>> >
>> > On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas 
>> > wrote:
>> >
>> > > Thanks for starting this discussion, Sumanth! Added a round of
>> comments
>> > as
>> > > well.
>> > >
>> > > Summarizing my non-binding feedback: I feel that many of the items
>> under
>> > > "Alpha" and "Beta" should be achieved prior to the release of an
>> alpha,
>> > > especially those related to correctness/safety, scope lock, feature
>> > > completeness, deprecation, and backwards compatibility. Establishing a
>> > > higher standard for official project releases (even at the alpha and
>> beta
>> > > stage) will help us really polish the final build together.
>> > >
>> > > Ideally, I feel that contributors should have completed extensive
>> > > testing/validation to ensure that no critical or severe bugs exist
>> prior
>> > to
>> > > the release of an alpha (e.g., data loss, consistency violations,
>> > incorrect
>> > > responses to queries, etc). Perhaps we can add a line to this effect.
>> > >
>> > > Ensuring that we've met that bar prior to alpha will help us focus the
>> > > final stages of the release on gathering feedback from users +
>> developers
>> > > to validate tooling and automation; compatibility with less
>> commonly-used
>> > > client libraries, testing new features, evaluating performance and
>> > > stability under their workloads, etc.
>> > >
>> > > – Scott
>> > >
>> > > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" <
>> > > sumanth.pasupuleti...@gmail.com> wrote:
>> > >
>> > > Thanks for the feedback on the product stages/ release life cycle
>> > > document.
>> > > I have incorporated the suggestions and looking for any additional
>> > > feedback
>> > > folks may have.
>> > >
>> > >
>> >
>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
>> > >
>> > > Thanks,
>> > > Sumanth
>> > >
>> > > On Tue, May 28, 2019 at 10:43 PM Scott Andreas <
>> sc...@paradoxica.net
>> > >
>> > > wrote:
>> > >
>> > > > Echoing Jon’s point here –
>> > > >
>> > > > JH: “My thinking is I'd like to be able to recommend 4.0.0 as a
>> > > production
>> > > > ready
>> > > > database for business critical cases”
>> > > >
>> > > > I feel that this is a standard that is both appropriate and
>> > > achievable,
>> > > > and one I’m legitimately excited about.
>> > > >
>> > > > Re: the current state of the test plan wiki in Confluence, I owe
>> > > another
>> > > > pass through. There has been a lot of progress here, but I’ve
>> let
>>

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

[Sumanth Pasupuleti]

I have started running fuzz tests (
https://github.com/Netflix/ndbench/wiki/Fuzz-Testing), will update in case
of any interesting findings.

Thanks,
Sumanth

On Fri, Sep 6, 2019 at 4:01 AM Benedict Elliott Smith 
wrote:

> I think anybody can run these tests locally.  It's just possible to pay to
> offload them.
>
> And when I say anybody, I don't mean me, because I always fail to get
> dtests to run due to environmental problems.  But I'm reliably informed
> that others manage.
>
>
> On 06/09/2019, 11:48, "Mick Semb Wever"  wrote:
>
>
>
> > Can we have a vote once the tests pass? I know we all are including
> me
> > are excited about cutting this alpha but we cannot cut a release
> with
> > test failing or not being run due to some Java home issue.
>
>
> I agree.
> I'm -0 (non-binding anyway) on the release for this reason.
>
>
> > If people have already started using the alpha artifacts, then I
> > suggest we make test passing a blocker for next alpha
>
>
> There's no requirement for any alpha to pass a successful vote, or to
> be voted on at all. It remains available in the staging repository for
> everyone that wants to test it. That is in itself a great way of saying
> it's "alpha". Ofc if you want it tested in more hands then it makes sense
> it is easier to get.
>
> Also,  is CircleCI is expected to pass without an account that breaks
> the bank? Or are we in a situation where only certain people with paid
> subscriptions to CircleCI can do the full test run?
>
> -
> 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

[Sumanth Pasupuleti]

No hard preference on the repo, but just excited about this tool! Looking
forward to employing this for upgrade testing (very timely :))

On Thu, Aug 22, 2019 at 3:38 AM Sam Tunnicliffe  wrote:

> My own weak preference would be for a dedicated repo in the first
> instance. If/when additional tools are contributed we should look at
> co-locating common stuff, but rushing toward a monorepo would be a mistake
> IMO.
>
> > On 22 Aug 2019, at 11:10, Jeff Jirsa  wrote:
> >
> > I weakly prefer contrib.
> >
> >
> > On Thu, Aug 22, 2019 at 12:09 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
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

Submitted patch to add release lifecycle information to the website
https://issues.apache.org/jira/browse/CASSANDRA-15249

On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov 
wrote:

> Maybe a bit off-topic:
>
> Before we cut a release, we should make sure we take care of beta protocol
> [1], include released driver versions [2] and remove compact storage
> remainders [3]. Third one is optional, but I'd argue we should do it sooner
> rather than later.
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-14973
> [2] https://issues.apache.org/jira/browse/CASSANDRA-13951
> [3] https://issues.apache.org/jira/browse/CASSANDRA-13994
>
>
>
> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Thanks for the feedback Scott. I have incorporated all the incremental
> > feedback I have thus far.
> >
> > Looking for any additional feedback folks may have.
> >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
> >
> > On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas 
> > wrote:
> >
> > > Thanks for starting this discussion, Sumanth! Added a round of comments
> > as
> > > well.
> > >
> > > Summarizing my non-binding feedback: I feel that many of the items
> under
> > > "Alpha" and "Beta" should be achieved prior to the release of an alpha,
> > > especially those related to correctness/safety, scope lock, feature
> > > completeness, deprecation, and backwards compatibility. Establishing a
> > > higher standard for official project releases (even at the alpha and
> beta
> > > stage) will help us really polish the final build together.
> > >
> > > Ideally, I feel that contributors should have completed extensive
> > > testing/validation to ensure that no critical or severe bugs exist
> prior
> > to
> > > the release of an alpha (e.g., data loss, consistency violations,
> > incorrect
> > > responses to queries, etc). Perhaps we can add a line to this effect.
> > >
> > > Ensuring that we've met that bar prior to alpha will help us focus the
> > > final stages of the release on gathering feedback from users +
> developers
> > > to validate tooling and automation; compatibility with less
> commonly-used
> > > client libraries, testing new features, evaluating performance and
> > > stability under their workloads, etc.
> > >
> > > – Scott
> > >
> > > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" <
> > > sumanth.pasupuleti...@gmail.com> wrote:
> > >
> > > Thanks for the feedback on the product stages/ release life cycle
> > > document.
> > > I have incorporated the suggestions and looking for any additional
> > > feedback
> > > folks may have.
> > >
> > >
> >
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
> > >
> > > Thanks,
> > > Sumanth
> > >
> > > On Tue, May 28, 2019 at 10:43 PM Scott Andreas <
> sc...@paradoxica.net
> > >
> > > wrote:
> > >
> > > > Echoing Jon’s point here –
> > > >
> > > > JH: “My thinking is I'd like to be able to recommend 4.0.0 as a
> > > production
> > > > ready
> > > > database for business critical cases”
> > > >
> > > > I feel that this is a standard that is both appropriate and
> > > achievable,
> > > > and one I’m legitimately excited about.
> > > >
> > > > Re: the current state of the test plan wiki in Confluence, I owe
> > > another
> > > > pass through. There has been a lot of progress here, but I’ve let
> > > perfect
> > > > be the enemy of the good in getting updates out. I’ll complete
> that
> > > pass
> > > > later this week.
> > > >
> > > > Cheers,
> > > >
> > > > — Scott
> > > >
> > > > > On May 28, 2019, at 10:48 AM, Dinesh Joshi 
> > > wrote:
> > > > >
> > > > > +1. Wiki could be useful to document what the overall plan.
> Jira
> > to
> > > > track progress.
> > > > >
> > > > > Dinesh
> > > > >
> > > > >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie <
> > > jmck

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

Thanks for the feedback Scott. I have incorporated all the incremental
feedback I have thus far.

Looking for any additional feedback folks may have.
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#

On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas  wrote:

> Thanks for starting this discussion, Sumanth! Added a round of comments as
> well.
>
> Summarizing my non-binding feedback: I feel that many of the items under
> "Alpha" and "Beta" should be achieved prior to the release of an alpha,
> especially those related to correctness/safety, scope lock, feature
> completeness, deprecation, and backwards compatibility. Establishing a
> higher standard for official project releases (even at the alpha and beta
> stage) will help us really polish the final build together.
>
> Ideally, I feel that contributors should have completed extensive
> testing/validation to ensure that no critical or severe bugs exist prior to
> the release of an alpha (e.g., data loss, consistency violations, incorrect
> responses to queries, etc). Perhaps we can add a line to this effect.
>
> Ensuring that we've met that bar prior to alpha will help us focus the
> final stages of the release on gathering feedback from users + developers
> to validate tooling and automation; compatibility with less commonly-used
> client libraries, testing new features, evaluating performance and
> stability under their workloads, etc.
>
> – Scott
>
> On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> Thanks for the feedback on the product stages/ release life cycle
> document.
> I have incorporated the suggestions and looking for any additional
> feedback
> folks may have.
>
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
>
> Thanks,
> Sumanth
>
> On Tue, May 28, 2019 at 10:43 PM Scott Andreas 
> wrote:
>
> > Echoing Jon’s point here –
> >
> > JH: “My thinking is I'd like to be able to recommend 4.0.0 as a
> production
> > ready
> > database for business critical cases”
> >
> > I feel that this is a standard that is both appropriate and
> achievable,
> > and one I’m legitimately excited about.
> >
> > Re: the current state of the test plan wiki in Confluence, I owe
> another
> > pass through. There has been a lot of progress here, but I’ve let
> perfect
> > be the enemy of the good in getting updates out. I’ll complete that
> pass
> > later this week.
> >
> > Cheers,
> >
> > — Scott
> >
> > > On May 28, 2019, at 10:48 AM, Dinesh Joshi 
> wrote:
> > >
> > > +1. Wiki could be useful to document what the overall plan. Jira to
> > track progress.
> > >
> > > Dinesh
> > >
> > >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie <
> jmcken...@apache.org>
> > wrote:
> > >>>
> > >>>
> > >>> The unofficial rule is to not upgrade to prod till .10 is cut.
> > >>
> > >> FWIW, I believe it's historically .6. Which is still not a great
> look
> > for
> > >> the project.
> > >>
> > >> There's a ton of work going into testing 4.0 already.
> > >>
> > >> While I intuitively and anecdotally (from the people I've
> backchanneled
> > >> with) believe this to be true as well, the referenced wiki
> page[1] and
> > >> jql[2] doesn't look like it's an up to date reflection of the
> testing
> > >> efforts going on. Is there another place this information is
> stored /
> > >> queryable we can surface to people to keep us all coordinated?
> > >>
> > >> [1]
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> > >> [2]
> > >>
> >
> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
> > >>
> > >> On Tue, May 28, 2019 at 12:57 PM sankalp kohli <
> kohlisank...@gmail.com>
> > >> wrote:
> > >>
> > >>> Hi Jon,
> > >>>  When you say 4.0 release, how do u match it with 3.0
> minor
> > >>> releases. The unofficial rule is to not upgrade to prod till .10
> is
>

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

Thanks for the feedback on the product stages/ release life cycle document.
I have incorporated the suggestions and looking for any additional feedback
folks may have.
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#

Thanks,
Sumanth

On Tue, May 28, 2019 at 10:43 PM Scott Andreas  wrote:

> Echoing Jon’s point here –
>
> JH: “My thinking is I'd like to be able to recommend 4.0.0 as a production
> ready
> database for business critical cases”
>
> I feel that this is a standard that is both appropriate and achievable,
> and one I’m legitimately excited about.
>
> Re: the current state of the test plan wiki in Confluence, I owe another
> pass through. There has been a lot of progress here, but I’ve let perfect
> be the enemy of the good in getting updates out. I’ll complete that pass
> later this week.
>
> Cheers,
>
> — Scott
>
> > On May 28, 2019, at 10:48 AM, Dinesh Joshi  wrote:
> >
> > +1. Wiki could be useful to document what the overall plan. Jira to
> track progress.
> >
> > Dinesh
> >
> >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie 
> wrote:
> >>>
> >>>
> >>> The unofficial rule is to not upgrade to prod till .10 is cut.
> >>
> >> FWIW, I believe it's historically .6. Which is still not a great look
> for
> >> the project.
> >>
> >> There's a ton of work going into testing 4.0 already.
> >>
> >> While I intuitively and anecdotally (from the people I've backchanneled
> >> with) believe this to be true as well, the referenced wiki page[1] and
> >> jql[2] doesn't look like it's an up to date reflection of the testing
> >> efforts going on. Is there another place this information is stored /
> >> queryable we can surface to people to keep us all coordinated?
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> >> [2]
> >>
> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
> >>
> >> On Tue, May 28, 2019 at 12:57 PM sankalp kohli 
> >> wrote:
> >>
> >>> Hi Jon,
> >>>  When you say 4.0 release, how do u match it with 3.0 minor
> >>> releases. The unofficial rule is to not upgrade to prod till .10 is
> cut.
> >>> Also due to heavy investment in testing, I dont think it will take as
> long
> >>> as 3.0 but want to know what is your thinking with this.
> >>>
> >>> Thanks,
> >>> Sankalp
> >>>
> >>>> On Tue, May 28, 2019 at 9:40 AM Jon Haddad  wrote:
> >>>>
> >>>> Sept is a pretty long ways off.  I think the ideal case is we can
> >>> announce
> >>>> 4.0 release at the summit.  I'm not putting this as a "do or die"
> date,
> >>> and
> >>>> I don't think we need to announce it or make promises.  Sticking with
> >>> "when
> >>>> it's ready" is the right approach, but we need a target, and this is
> imo
> >>> a
> >>>> good one.
> >>>>
> >>>> This date also gives us a pretty good runway.  We could cut our first
> >>>> alphas in mid June / early July, betas in August and release in Sept.
> >>>> There's a ton of work going into testing 4.0 already.
> >>>> Landing CASSANDRA-15066 will put us in a pretty good spot.  We've
> >>> developed
> >>>> tooling at TLP that will make it a lot easier to spin up dev clusters
> in
> >>>> AWS as well as stress test them.  I've written about this a few times
> in
> >>>> the past, and I'll have a few blog posts coming up that will help show
> >>> this
> >>>> in more details.
> >>>>
> >>>> There's some other quality of life things we should try to hammer out
> >>>> before then.  Updating our default JVM settings would be nice, for
> >>>> example.  Improving documentation (the data modeling section in
> >>>> particular), fixing the dynamic snitch issues [1], and some
> improvements
> >>> to
> >>>> virtual tables like exposing the sstable metadata [2], and exposing
> table
> >>>> statistics [3] come to mind.  The dynamic snitch improvement will help
> >>>> performance in a big way, and the virtual tables will go a long way to
> >>>> helping with quality of life.  I showed a few folk

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

I have taken an initial stab at documenting release types and exit criteria
in a google doc, to get us started, and to collaborate on.
https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit?usp=sharing

Thanks,
Sumanth

On Thu, May 23, 2019 at 12:04 PM Dinesh Joshi  wrote:

> Sankalp,
>
> Great point. This is the page created for testing.
>
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
>
> I think we need to define the various release types and the exit criteria
> for each type of release. Anybody want to take a stab at this or start a
> thread to discuss it?
>
> Thanks,
>
> Dinesh
>
>
> > On May 23, 2019, at 11:57 AM, sankalp kohli 
> wrote:
> >
> > Hi,
> >Is there a page where it is written what is expected from an alpha,
> > beta, rc and a 4.0 release?
> > Also how are we coming up with Q4 2019 timeline. Is this for alpha, beta,
> > rc or 4.0 release?
> >
> > Thanks,
> > Sankalp
> >
> > On Thu, May 23, 2019 at 11:27 AM Attila Wind 
> wrote:
> >
> >> +1+1+1 I read a blog post was talking about last sept(?) to freeze
> >> features and start extensive testing. Maybe its really time to hit it!
> :-)
> >>
> >> Attila Wind
> >>
> >> http://www.linkedin.com/in/attilaw
> >> Mobile: +36 31 7811355
> >>
> >>
> >> On 2019. 05. 23. 19:30, ajs6f wrote:
> >>> +1 in the fullest degree. A date that needs to be changed is still
> >> enormously more attractive than no date at all.
> >>>
> >>> Adam Soroka
> >>>
> >>>> On May 23, 2019, at 12:01 PM, Sumanth Pasupuleti <
> >> spasupul...@netflix.com.INVALID> wrote:
> >>>>
> >>>> Having at least a ballpark target on the website will definitely help.
> >> +1
> >>>> on setting it to Q4 2019 for now.
> >>>>
> >>>> On Thu, May 23, 2019 at 8:52 AM Dinesh Joshi 
> wrote:
> >>>>
> >>>>> +1 on setting a date.
> >>>>>
> >>>>> Dinesh
> >>>>>
> >>>>>> On May 23, 2019, at 11:07 AM, Michael Shuler <
> mich...@pbandjelly.org>
> >>>>> wrote:
> >>>>>> We've had 4.0 listed as TBD release date for a very long time.
> >>>>>>
> >>>>>> Yesterday, Alexander Dejanovski got a "when's 4.0 going to release?"
> >>>>> question after his repair talk and he suggested possibly Q4 2019.
> This
> >>>>> morning Nate McCall hinted at possibly being close by ApacheCon Las
> >> Vegas
> >>>>> in September. These got me thinking..
> >>>>>> Think we can we shoot for having a 4.0 alpha/beta/rc ready to
> >>>>> announce/release at ApacheCon? At that time, we'll have been frozen
> >> for 1
> >>>>> year, and I think we can. We'll GA release when it's ready, but I
> >> think Q4
> >>>>> could be an realistic target.
> >>>>>> With that said, I'd like to change "TBD" on the downloads page to
> >> "Est.
> >>>>> Q4 2019". We can always push or pull the estimate, but I think it's
> >> time to
> >>>>> have a goal line. This lines up with ApacheCon nicely for a preview
> >> release.
> >>>>>> Any concerns or objections to editing the download page? Have some
> >> other
> >>>>> goal timeframe in mind?
> >>>>>> --
> >>>>>> Warm 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
> >>>>>
> >>>>>
> >>>
> >>> -
> >>> 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: "4.0: TBD" -> "4.0: Est. Q4 2019"?

[Sumanth Pasupuleti]

Having at least a ballpark target on the website will definitely help. +1
on setting it to Q4 2019 for now.

On Thu, May 23, 2019 at 8:52 AM Dinesh Joshi  wrote:

> +1 on setting a date.
>
> Dinesh
>
> > On May 23, 2019, at 11:07 AM, Michael Shuler 
> wrote:
> >
> > We've had 4.0 listed as TBD release date for a very long time.
> >
> > Yesterday, Alexander Dejanovski got a "when's 4.0 going to release?"
> question after his repair talk and he suggested possibly Q4 2019. This
> morning Nate McCall hinted at possibly being close by ApacheCon Las Vegas
> in September. These got me thinking..
> >
> > Think we can we shoot for having a 4.0 alpha/beta/rc ready to
> announce/release at ApacheCon? At that time, we'll have been frozen for 1
> year, and I think we can. We'll GA release when it's ready, but I think Q4
> could be an realistic target.
> >
> > With that said, I'd like to change "TBD" on the downloads page to "Est.
> Q4 2019". We can always push or pull the estimate, but I think it's time to
> have a goal line. This lines up with ApacheCon nicely for a preview release.
> >
> > Any concerns or objections to editing the download page? Have some other
> goal timeframe in mind?
> >
> > --
> > Warm 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: CASSANDRA-14482

[Sumanth Pasupuleti]

+1

On Fri, Feb 15, 2019 at 12:14 PM Dikang Gu  wrote:

> +1
>
> On Fri, Feb 15, 2019 at 10:27 AM Vinay Chella 
> wrote:
>
> > 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
> > >
> > >
> >
>
>
> --
> Dikang
>

Re: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti]

Another note about 14557 - this also lets us fix 3.0 regression where we
cannot bootstrap new nodes until system_auth keyspace (that comes up with
RF=1) is "altered" to a higher RF. Instead, with 14557, one can set yaml
property minimum_keyspace_rf to, say, 3 and system keyspaces would honor it
(more in the JIRA).

Thanks,
Sumanth

On Tue, Jan 15, 2019 at 8:46 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
> it makes it further easy to create keyspaces (without having to always
> mention RF) and provides a way to ensure keyspaces are created with a
> minimum required RF.
>
> Thanks,
> Sumanth
>
> On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella 
> wrote:
>
>> 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
>> >
>> >
>>
>

Re: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti]

With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
it makes it further easy to create keyspaces (without having to always
mention RF) and provides a way to ensure keyspaces are created with a
minimum required RF.

Thanks,
Sumanth

On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella  wrote:

> 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
> >
> >
>

Feedback request for Message Flusher bug found in 3.0.17

[Sumanth Pasupuleti]

Hi,

We recently found this issue on one of our 3.0.17 clusters, where the
Message Flusher falls off the event loop, eventually resulting in OOM on a
bunch of nodes. We saw this happen twice so far.

CASSANDRA-14855  has
all the details (including heap dump analysis). Backported ImmediateFlusher
from trunk as a fix for this. Would like to get feedback (on the JIRA) if
this fix is recommended, or if there is a suggestion for a better fix.

Thanks,
Sumanth

Feedback request for Message Flusher bug found in 3.0.17 (CASSANDRA-14855)

[Sumanth Pasupuleti]

Hi,

We recently found this issue on one of our 3.0.17 clusters, where the
Message Flusher falls off the event loop, eventually resulting in OOM on a
bunch of nodes. We saw this happen twice so far.

CASSANDRA-14855  has
all the details (including heap dump analysis). Backported ImmediateFlusher
from trunk as a fix for this. Would like to get feedback (on the JIRA) if
this fix is recommended, or if there is a suggestion for a better fix.

Thanks,
Sumanth

Re: Proposed changes to CircleCI testing workflow

[Sumanth Pasupuleti]

Hi Stefan,

+1 on the CircleCI changes.

A few months ago, I took a shot at CircleCI to add support for Java 1.7 and
in the process (perhaps the more important takeaway), explored adding
"aliases" to avoid code duplication in the yml file (
https://github.com/apache/cassandra/pull/248/commits/47855675f4805a09b78059f7231311566f0e66f0).
I believe we can do similar optimization to
https://github.com/spodkowinski/cassandra/blob/WIP-14806/.circleci/config.yml
.

Also, with your changes, I believe we can close out CASSANDRA-14609.

I was also planning to work on CASSANDRA-14718 to validate artifacts
generation - let me know what you think.

Thanks,
Sumanth


On Fri, Oct 26, 2018 at 10:05 AM Ariel Weisberg  wrote:

> Hi,
>
> Thank you for working on this. These all sound like good changes to me.
>
> Ariel
>
> On Fri, Oct 26, 2018, at 10:49 AM, Stefan Podkowinski wrote:
> > I'd like to give you a quick update on the work that has been done
> > lately on running tests using CircleCI. Please let me know if you have
> > any objections or don't think this is going into the right direction, or
> > have any other feedback!
> >
> > We've been using CircleCI for a while now and results are used on
> > constant basis for new patches. Not only by committers, but also by
> > casual contributors to run unit tests. Looks like people find the
> > service valuable and we should keep using it. Therefor I'd like to make
> > some improvements that will make it easier to add new tests and to
> > continue making CircleCI an option for all contributors, both on paid
> > and free plans.
> >
> > The general idea of the changes implemented in #14806, is to consolidate
> > the existing config to make it more modular and have smaller jobs that
> > can be scheduled ad-hoc by the developer, instead of running a few big
> > jobs on every commit. Reorganizing and breaking up the existing config
> > was done using the new 2.1 config features. Starting jobs on request,
> > instead of automatically, is done using the manual approval feature,
> > i.e. you now have to click on that job in the workflow page in order to
> > start it. I'd like to see us having smaller, more specialized groups of
> > tests that we can run more selectively during development, while still
> > being able to run bigger tests before committing, or firing up all of
> > them during testing and releasing. Other example of smaller jobs would
> > be testing coverage (#14788) or cqlsh tests (#14298). But also
> > individual jobs for different ant targets, like burn, stress or
> benchmarks.
> >
> > We'd now also be able to run tests using different docker images and
> > different JDKs. I've already updated the used image to also include Java
> > 11 and added unit and dtest jobs to the config for that. It's now really
> > easy to run tests on Java 11, although these won't pass yet. It seems to
> > be important to me to have this kind of flexibility, given the
> > increasingly diverse ecosystem of Java distributions. We can also add
> > jobs for packaging and doing smoke tests by installing and starting
> > packages on different docker images (Redhat, Debian, Ubuntu,..) at a
> > later point.
> >
> > As for the paid vs free plans issue, I'd also like us to discuss how we
> > can make tests faster and less resource intensive in general. As a
> > desired consequence, we'd be able to move away from multi-node dtests,
> > to something that can be run using the free plan. I'm looking forward to
> > see if #14821 can get us into that direction. Ideally we can add these
> > tests into a job that can be completed on the free plan and encourage
> > contributors to add new tests there, instead of having to write a dtest,
> > which they won't be able to run on CircleCI without a paid plan.
> >
> > Whats changing for you as a CircleCI user?
> > * All tests, except unit tests, will need to be started manually and
> > will not run on every commit (this can be further discussed and changed
> > anytime if needed)
> > * Updating the config.yml file now requires using the CircleCI cli tool
> > and should not be done directly (see #14806 for technical details)
> > * High resource settings can be enabled using a script/patch, either run
> > manually or as commit hook (again see ticket for details)
> > * Both free and paid plan users now have more tests to run
> >
> > As already mentioned, please let me know if you have any thoughts on
> > this, or if you think this is going into the wrong direction.
> >
> > Thanks.
> >
> >
> > -
> > 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] Accept GoCQL driver donation and begin incubation process

[Sumanth Pasupuleti]

+1

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

> +1
>
> Dinesh
>
> > On Sep 12, 2018, at 10:23 AM, Jaydeep Chovatia <
> chovatia.jayd...@gmail.com> wrote:
> >
> > +1
> >
> > On Wed, Sep 12, 2018 at 10:00 AM Roopa Tangirala
> >  wrote:
> >
> >> +1
> >>
> >>
> >> *Regards,*
> >>
> >> *Roopa Tangirala*
> >>
> >> Engineering Manager CDE
> >>
> >> *(408) 438-3156 - mobile*
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Sep 12, 2018 at 8:51 AM Sylvain Lebresne 
> >> wrote:
> >>
> >>> -0
> >>>
> >>> The project seems to have a hard time getting on top of reviewing his
> >>> backlog
> >>> of 'patch available' issues, so that I'm skeptical adopting more code
> to
> >>> maintain is the thing the project needs the most right now. Besides,
> I'm
> >>> also
> >>> generally skeptical that augmenting the scope of a project makes it
> >> better:
> >>> I feel
> >>> keeping this project focused on the core server is better. I see risks
> >>> here, but
> >>> the upsides haven't been made very clear for me, even for end users:
> yes,
> >>> it
> >>> may provide a tiny bit more clarity around which Golang driver to
> choose
> >> by
> >>> default, but I'm not sure users are that lost, and I think there is
> other
> >>> ways to
> >>> solve that if we really want.
> >>>
> >>> Anyway, I reckon I may be overly pessimistic here and it's not that
> >> strong
> >>> of
> >>> an objection if a large majority is on-board, so giving my opinion but
> >> not
> >>> opposing.
> >>>
> >>> --
> >>> Sylvain
> >>>
> >>>
> >>> On Wed, Sep 12, 2018 at 5:36 PM Jeremiah D Jordan <
> >>> jeremiah.jor...@gmail.com>
> >>> wrote:
> >>>
>  +1
> 
>  But I also think getting this through incubation might take a while/be
>  impossible given how large the contributor list looks…
> 
> > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa  wrote:
> >
> > +1
> >
> > (Incubation looks like it may be challenging to get acceptance from
> >> all
>  existing contributors, though)
> >
> > --
> > Jeff Jirsa
> >
> >
> >> On Sep 12, 2018, at 8:12 AM, Nate McCall 
> >> wrote:
> >>
> >> This will be the same process used for dtest. We will need to walk
> >> this through the incubator per the process outlined here:
> >>
> >>
> 
> >>>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__incubator.apache.org_guides_ip-5Fclearance.html=DwIFAg=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=g-MlYFZVJ7j5Dj_ZfPfa0Ik8Nxco7QsJhTG1TnJH7xI=rk5T_t1HZY6PAhN5XgflBhfEtNrcZkVTIvQxixDlw9o=
> >>
> >> 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
> >>
> >
> > -
> > 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] Development Approach for Apache Cassandra Management process

[Sumanth Pasupuleti]

Option "b".

Thanks,
Sumanth

On Wed, Sep 12, 2018 at 9:59 AM Roopa Tangirala
 wrote:

> +1 to b Take the best from existing side cars and make a great side car
> which ships with cassandra
>
>
> *Regards,*
>
> *Roopa Tangirala*
>
> Engineering Manager CDE
>
> *(408) 438-3156 - mobile*
>
>
>
>
>
>
> On Wed, Sep 12, 2018 at 8:19 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
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> I also can't remember any reports on regressions in 2.2 bug fix releases
specific to 1.7. So what's the actual problem we want to solve here?

Discussion for 2.2 came up from the ticket CASSANDRA-14563
<https://issues.apache.org/jira/browse/CASSANDRA-14563>, which I think came
up from an incident where a JDK1.7 incompatible commit was made into 2.2
branch. But I see the consensus on 2.2 that, there is no ROI on spending
time on 2.2 given that its reaching EOL, which can mean (CASSANDRA-14563
<https://issues.apache.org/jira/browse/CASSANDRA-14563> (in discussion
state) and CASSANDRA-14625
<https://issues.apache.org/jira/browse/CASSANDRA-14625> (in patch available
state) may be resolved as won't fix)

As for 4.0/4.x, I think there are a couple of takeaways from this thread,
and I am happy to pursue them.
1. Make CI jobs use "_build_multi_java" and adding optional workflow to run
tests against JAVA 11 - CASSANDRA-14609
<https://issues.apache.org/jira/browse/CASSANDRA-14609>
2. Add CI job to validate "ant artifacts" - CASSANDRA-14718
<https://issues.apache.org/jira/browse/CASSANDRA-14718>
3. Auto-update of documentation from CI builds - CASSANDRA-14719
<https://issues.apache.org/jira/browse/CASSANDRA-14719>

Thanks,
Sumanth

On Sat, Sep 8, 2018 at 4:59 AM Stefan Podkowinski  wrote:

> I really don't see any benefit at all in having any additional Java 1.7
> specific build and testing changes for the 2.2 branch. The 2.2 version
> is reaching EOL and will only get critical patches until then anyways. I
> also can't remember any reports on regressions in 2.2 bug fix releases
> specific to 1.7. So what's the actual problem we want to solve here?
>
> As for 4.0, we're going to ship multi-release jars, which are targeted
> against Java 8, but also contain Java 11 classes that will only be used
> when executed under Java 11 (also currently just a single class). I can
> see two issues that need our attention with that:
>  * We should make sure to use the "_build_multi_java" target for our CI
> jobs, so we're really testing the same build that we would ship. It's
> probably not going to make a real difference, but who knows..
>  * It would also be nice to have the option to run tests on CI under
> Java 11, although we only provide "experimental" support for that Java
> version. Nice to have at this point, as there will be plenty of bugs in
> 4.0 to fix, until we should spend time looking more closely for more
> subtle Java 11 issues. But if someone wants to contribute any work to
> make this happen, I'd be glad to have that option running tests on Java
> 11, so don't get me wrong.
>
>
> On 07.09.18 04:10, Sumanth Pasupuleti wrote:
> >> And I would suggest to go further and crash the build with JDK1.7 so we
> > can take away the possibility for users to shoot their foot off this way.
> >
> > I like this suggestion. Either we should be on the side of NO support to
> > JDK 1.7, or if we say we support JDK1.7, I believe we should be building
> > against JDK1.7 to make sure we are compliant.
> > I have a quick clarifying question here - I believe origin of
> > CASSANDRA-14563 is from the introduction of an API in 2.2 that is
> > incompatible with 1.7, that has then been manually detected and fixed.
> Are
> > you suggesting, going further, we would not support 1.7?
> >
> >> Currently I'm unclear on how we would make a stable release using only
> > JDK8, maybe their are plans on the table i don't know about?
> >
> > From the current state of build.xml and from the past discussions, I do
> > believe as well, that we need both JDKs to make a 4.0 release using
> > ‘_build_multi_java’. Bonus would be that, the release would also be able
> to
> > run against Java11, but that would be an experimental release.
> >
> >> I'm not familiar with optional jobs or workflows in CircleCi, do you
> have
> > an example of what you mean at hand?
> >
> > By optional, I was referring to having workflow definitions in place, but
> > calls to those workflows commented out. Basically similar to what we have
> > today.
> > workflows:
> > version: 2
> > build_and_run_tests: *default_jobs
> > #build_and_run_tests: *with_dtest_jobs_only
> > #build_and_run_tests_java11: *with_dtest_jobs_java11
> > Jason created CASSANDRA-14609 for this purpose I believe.
> >
> >> Off-topic, but what are your thoughts on this? Can we add `ant
> > artifacts`, and the building of the docs, as a separate jobs into the
> > existing default CircleCI workflow? I think we should also be looking
> into
> > getting https://cassandra.apache.org/doc/latest/ automatically updated
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> And I would suggest to go further and crash the build with JDK1.7 so we
can take away the possibility for users to shoot their foot off this way.

I like this suggestion. Either we should be on the side of NO support to
JDK 1.7, or if we say we support JDK1.7, I believe we should be building
against JDK1.7 to make sure we are compliant.
I have a quick clarifying question here - I believe origin of
CASSANDRA-14563 is from the introduction of an API in 2.2 that is
incompatible with 1.7, that has then been manually detected and fixed. Are
you suggesting, going further, we would not support 1.7?

> Currently I'm unclear on how we would make a stable release using only
JDK8, maybe their are plans on the table i don't know about?

>From the current state of build.xml and from the past discussions, I do
believe as well, that we need both JDKs to make a 4.0 release using
‘_build_multi_java’. Bonus would be that, the release would also be able to
run against Java11, but that would be an experimental release.

> I'm not familiar with optional jobs or workflows in CircleCi, do you have
an example of what you mean at hand?

By optional, I was referring to having workflow definitions in place, but
calls to those workflows commented out. Basically similar to what we have
today.
workflows:
version: 2
build_and_run_tests: *default_jobs
#build_and_run_tests: *with_dtest_jobs_only
#build_and_run_tests_java11: *with_dtest_jobs_java11
Jason created CASSANDRA-14609 for this purpose I believe.

> Off-topic, but what are your thoughts on this? Can we add `ant
artifacts`, and the building of the docs, as a separate jobs into the
existing default CircleCI workflow? I think we should also be looking into
getting https://cassandra.apache.org/doc/latest/ automatically updated
after each successful trunk build, and have
https://cassandra.apache.org/doc/X.Y versions on the docs in place (which
are only updated after each patch release).

I like all these ideas! I believe we should be able to add a workflow to
test out artifact generation. Will create a JIRA for this. Your suggestions
around auto-update of docs provides a way to keep our website docs
up-to-date. Not sure what it takes to do it though. Will be happy to
explore (as part of separate JIRAs).

Thanks,
Sumanth

On Wed, Sep 5, 2018 at 9:30 PM Mick Semb Wever  wrote:

>
>
> > How would we be sure users will never encounter bugs unless we build
> > against that JDK?
>
>
> Apache Cassandra does not distribute JDK1.7 built releases.
>
> The only way a user could repeat such a bug is if they have built C*
> themselves.
>
> I don't think the project should be responsible for every possible build
> combination tom, dick and harry can do.
> That's my 2cents anyway.
>
> And I would suggest to go further and crash the build with JDK1.7 so we
> can take away the possibility for users to shoot their foot off this way.
>
>
> > > The time it takes for tests to run is a headache, so to have to run
> > dtests four times over makes me grimace.
> > It takes only about 25min with default 4x parallelism to run unit tests
> in
> > CircleCI.
>
> I referred to dtests, how would you do this on CircleCI?
> Today dtests take 5-9 hours on builds.apache.org, not including re-runs
> for offheap, large, novnode.
>
>
> > We definitely can build against JDK 8 alone, however from the thread you
> > linked and from 9608, we wanted to do a stable release that uses JDK8,
> and
> > an experimental release, which uses JDK8 to build most files, and JDK11
> to
> > build the Java 11 specific AtomicBTreePartitionBase file.
>
> Currently I'm unclear on how we would make a stable release using only
> JDK8, maybe their are plans on the table i don't know about?
>
> The current build.xml requires both JDKs to run `ant artifacts`.
> That is any release will have compiled in ant all but one class with
> `_build_multi_java` instead of `_build_java8_only`.
>
>
> > My proposal is not to necessarily run UTs and DTests against JDK11 always
> > with every commit but to have workflows in place that can be used
> whenever
> > we deem necessary.
>
>
> I'm not familiar with optional jobs or workflows in CircleCi, do you have
> an example of what you mean at hand?
> I like the idea of having a collection of CircleCi workflows, even if I'd
> rather see less JDKs supported at compile-time.
>
>
> > I think building the artefacts should be part of the CI build step
> because patches are not always about java code.
>
> Off-topic, but what are your thoughts on this? Can we add `ant artifacts`,
> and the building of the docs, as a separate jobs into the existing default
> CircleCI workflow? I think we should also be looking into getting
> https://cassandra.apache.org/doc/latest/ automatically updated after each
> successful trunk build, and have https://cassandra.apache.org/doc/X.Y
> versions on the docs in place (which are only updated after each patch
> release).
>
> regards,
> Mick
>
> 

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

C* 2.2
> I'm still left wondering why we want to use CI resources to find bugs
that the users will never encounter.
How would we be sure users will never encounter bugs unless we build
against that JDK? This is the reason I propose having a CircleCI build
against 1.7.

> If you take out "and optionally run UTs and Dtests against 1.7" from
workflow1 then I'm fine with it.
I don't think it hurts to have workflows that "can" do UTs and DTests
against 1.7. We can run them only when we make a release.
> The time it takes for tests to run is a headache, so to have to run
dtests four times over makes me grimace.
It takes only about 25min with default 4x parallelism to run unit tests in
CircleCI.


4.0
> Currently afaik we can't build the artifacts against only either JDK8 or
JDK11, hence the hybrid JDK setup.
We definitely can build against JDK 8 alone, however from the thread you
linked and from 9608, we wanted to do a stable release that uses JDK8, and
an experimental release, which uses JDK8 to build most files, and JDK11 to
build the Java 11 specific AtomicBTreePartitionBase file.

> In that thread it was mentioned the concerns about the cost of running
tests twice, and whether we should avoid running tests with JDK11 until
we're closer to formally supporting JDK11 at run-time.
My proposal is not to necessarily run UTs and DTests against JDK11 always
with every commit but to have workflows in place that can be used whenever
we deem necessary.

Thanks,
Sumanth

On Thu, Aug 30, 2018 at 12:34 AM Mick Semb Wever  wrote:

>
> Hey Sumanth,
>  could you clear a few things up for me…
>
> > C* 2.2
>
> > > I'm still a bit confused as to what's the benefit in compiling with
> > > jdk1.7 and then testing with jdk1.7 or jdk1.8
> >
> > I meant two separate workflows for each JDK i.e.
> > Workflow1: Build against jdk1.7, and optionally run UTs and Dtests
> against
> > 1.7
>
> I'm still left wondering why we want to use CI resources to find bugs that
> the users will never encounter.
> If you take out "and optionally run UTs and Dtests against 1.7" from
> workflow1 then I'm fine with it.
>
> The time it takes for tests to run is a headache, so to have to run dtests
> four times over makes me grimace.
>
>
> > C* 4.0
>
> I'm not quite clear on what the change you intend here is.
>
> Currently afaik we can't build the artefacts against only either JDK8 or
> JDK11, hence the hybrid jdk setup.
> I think building the artefacts should be part of the CI build step because
> patches are not always about java code.
>
> And that unit and dtests are run only against these 'release' built
> artefacts. Presuming the plan remains that the hybrid approach would be the
> 'release' process so long as jdk11 was GA before Cassandra-4.0.
>
>
> https://lists.apache.org/thread.html/45b3f12885f881d211f79368bdd5046e504e0149757cf19c8747bcb2@%3Cdev.cassandra.apache.org%3E
>
> In that thread it was mentioned the concerns about the cost of running
> tests twice, and whether we should avoid running tests with JDK11 until
> we're closer to formally supporting JDK11 at run-time.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: upgrade guava on trunk before 9/1?

[Sumanth Pasupuleti]

Thanks to Andy for suggestions on working around the issues, I now have
build and UTs passing with Guava 26, and driver 3.6.0.
Not sure if we can accommodate this in 4.0 since this is yet to be reviewed
and includes quite a few changes.
Updated https://issues.apache.org/jira/browse/CASSANDRA-14655 with the
Github branch and CircleCI details.

Thanks,
Sumanth

On Fri, Aug 17, 2018 at 2:32 PM Sumanth Pasupuleti
 wrote:

> Thanks for the confirmation Andy.
>
> Created a JIRA to track the guava upgrade
> https://issues.apache.org/jira/browse/CASSANDRA-14655.
>
> I current put target version as 4.x. If a compatible version of the driver
> happens to be released soon enough, and if there is a consensus that we
> should merge this into 4.0, will change the target version accordingly.
> Otherwise, it seems unlikely for 4.0 purely from dependencies perspective.
>
> Thanks,
> Sumanth
>
> On Thu, Aug 16, 2018 at 6:47 PM, Andy Tolbert  >
> wrote:
>
> > Hi Sumanth,
> >
> > I gave a shot at upgrading to Guava 26.0; resolved build issues; about 63
> > > Unit Tests fail - a lot of them due to a NPE and another bunch due to
> > > the driver using a method that does not exist in latest Guava.
> > >
> >
> > Unfortunately the driver doesn't currently work with Guava 26.0.  We
> have a
> > fix (JAVA-1928 <https://datastax-oss.atlassian.net/browse/JAVA-1928>)
> that
> > addresses this that will be in version 3.6.0 which should be released in
> > the coming weeks.  After that the driver will work with Guava 16.0.1
> > through 26 (We've run our full test suite against all versions in that
> > range).
> >
> > Thanks,
> > Andy
> >
> > On Thu, Aug 16, 2018 at 6:55 PM, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> > > I am +1 on upgrading to latest Guava, given that we would be on 4.0
> for a
> > > while, and we would have a relatively big testing phase that follows
> the
> > > freeze date, which would hopefully iron out (as much as possible) any
> > > issues we may have with the upgrade.
> > >
> > > I gave a shot at upgrading to Guava 26.0; resolved build issues; about
> 63
> > > Unit Tests fail - a lot of them due to a NPE and another bunch due to
> > > the driver using a method that does not exist in latest Guava.
> > >
> > > Github Branch:
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.
> > > com_sumanth-2Dpasupuleti_cassandra_tree_guava-5F26-5Ftrunk=DwIFaQ=
> > > adz96Xi0w1RHqtPMowiL2g=VHsWqsWT2MoX5jRZ0xZfdAWZxBsrn5KzowynGYCJaXE=
> > > NBUK9LYIuBLTb2_dn7ZZnfqkFQuWmAr69kTsiLgthN8=
> > > upEwsGydoKbFV9vnRLMO9LEy4YaSlVXBiPoChzsJfCE=
> > > Failing Unit Tests: https://urldefense.proofpoint.
> > com/v2/url?u=https-3A__
> > > circleci.com_gh_sumanth-2Dpasupuleti_cassandra_84=DwIFaQ=
> > > adz96Xi0w1RHqtPMowiL2g=VHsWqsWT2MoX5jRZ0xZfdAWZxBsrn5KzowynGYCJaXE=
> > > NBUK9LYIuBLTb2_dn7ZZnfqkFQuWmAr69kTsiLgthN8&
> > s=oKPrxl_zBsIcuZoHkzS2MZOi9U5_
> > > lF3DaNldTbMQsBU=
> > >
> > > Thanks,
> > > Sumanth
> > >
> > > On Thu, Aug 16, 2018 at 8:22 AM, Jonathan Haddad 
> > > wrote:
> > >
> > > > Pushing it back means it’s a bigger risk later on. I’m +.5 on
> upgrading
> > > now
> > > >
> > > > On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
> > > >  wrote:
> > > >
> > > > > Jason,
> > > > > Given that we're so close to the 9/1 date, I would err on the side
> of
> > > > > caution especially given the low value prop. If someone does run
> into
> > > > Guava
> > > > > compatibility issues (and someone somewhere will), we can revisit
> > this
> > > > > question then.
> > > > > Dinesh
> > > > >
> > > > > On Wednesday, August 15, 2018, 11:42:31 PM PDT, Dinesh A.
> Joshi <
> > > > > dinesh.jo...@gatech.edu> wrote:
> > > > >
> > > > >  Jason,
> > > > > Given that we're so close to the 9/1 date, I would err on the side
> of
> > > > > caution especially given the low value prop. If someone does run
> into
> > > > Guava
> > > > > compatibility issues (and someone somewhere will), we can revisit
> > this
> > > > > question then.
> > > > > Dinesh
> > > > >
> > > > > On Wednesday, August 15, 2018, 8:22:28 AM PDT, Salih Ge

Re: [Discuss] Accept GoCQL driver donation

[Sumanth Pasupuleti]

It sounds great to have an official GoCQL driver. I like the mentioned end
goal of having a reference implementation that evolves with the core C*
project.

Thanks,
Sumanth



On Fri, Aug 31, 2018 at 7:45 AM Michael Shuler 
wrote:

> On 08/31/2018 09:34 AM, Jay Zhuang wrote:
> > That's great. Could that be in the same repo as Cassandra or a
> > separate repo?
>
> For similar reasons as discussed for an admin tool, separate
> repositories are quick and simple to create, as well as allow handling
> contribution, CI, build, release, etc. mechanics more flexibly. I see
> little to no advantage to including allthethings in-tree. If there comes
> a time that particular contrib items do make sense to include in the
> main repository, dropping them in would be no problem.
>
> --
> Michael
>
> > On Fri, Aug 31, 2018 at 7: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.
> >>
> >> 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
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Reaper as cassandra-admin

[Sumanth Pasupuleti]

IMO, I am glad to see there are at least three solutions here to address
repair and can be potential candidates for sidecar. As Joey pointed out,
all of them may not be great at everything they do, and to me, it makes
sense to "cherry pick" the best each product has, and build a good C*
sidecar.

Thanks,
Sumanth

On Tue, Aug 28, 2018 at 2:45 PM, Blake Eggleston 
wrote:

> 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.
>
> I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless
> mess. It would bring a relatively mature project as well as a community of
> users and developers that the other options won’t. It’s probably a lot less
> work to rework whatever shortcomings reaper has, add new-hotness repair
> schedulers to it, and get people to actually use them than it would be to
> write something from scratch and build community confidence in it and get
> reaper users to switch.
>
> On August 28, 2018 at 1:40:59 PM, Roopa Tangirala 
> (rtangir...@netflix.com.invalid)
> wrote:
> I share Dinesh's concern too regarding tech debt with existing codebase.
> Its good we have multiple solutions for repairs which have been always
> painful in Cassandra. It would be great to see the community take the
> best
> pieces from the available solutions and roll it into the fresh side car
> which will help ease Cassandra's maintenance for lot of folks.
>
> My main concern with starting with an existing codebase is that it comes
> with tech debt. This is not specific to Reaper but to any codebase that
> is
> imported as a whole. This means future developers and patches have to
> work
> within the confines of the decisions that were already made. Practically
> speaking once a codebase is established there is inertia in making
> architectural changes and we're left dealing with technical debt.
>
>
>
> *Regards,*
>
> *Roopa Tangirala*
>
> Engineering Manager CDE
>
> *(408) 438-3156 - mobile*
>
>
>
>
>
>
> On Mon, Aug 27, 2018 at 10:49 PM Dinesh Joshi
>  wrote:
>
> > > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad 
> wrote:
> > > We're hoping to get some feedback on our side if that's something
> people
> > > are interested in. We've gone back and forth privately on our own
> > > preferences, hopes, dreams, etc, but I feel like a public discussion
> > would
> > > be healthy at this point. Does anyone share the view of using Reaper
> as
> > a
> > > starting point? What concerns to people have?
> >
> >
> > I have briefly looked at the Reaper codebase but I am yet to analyze it
> > better to have a real, meaningful opinion.
> >
> > My main concern with starting with an existing codebase is that it
> comes
> > with tech debt. This is not specific to Reaper but to any codebase that
> is
> > imported as a whole. This means future developers and patches have to
> work
> > within the confines of the decisions that were already made.
> Practically
> > speaking once a codebase is established there is inertia in making
> > architectural changes and we're left dealing with technical debt.
> >
> > As it stands I am not against the idea of using Reaper's features and I
> > would very much like using mature code that has been tested. I would
> > however like to propose piece-mealing it into the codebase. This will
> give
> > the community a chance to review what is going in and possibly change
> some
> > of the design decisions upfront. This will also avoid a situation where
> we
> > have to make many breaking changes in the initial versions due to
> > refactoring.
> >
> > I would also like it if we could compare and contrast the functionality
> > with Priam or any other interesting sidecars that folks may want to
> call
> > out. In fact it would be great if we could bring in the best
> functionality
> > from multiple implementations.
> >
> > Dinesh
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

Correct me if I am wrong, but I see the following consensus so far, on the
proposal.

C* 2.2
AnimalSniffer
Use AnimalSniffer for compile-time feedback on JDK 1.7 compatibility -
complete consensus so far
Circle CI Builds
In addition to existing JDK 1.8 support, build against JDK 1.7, and
[optionally] run unit tests and DTests against JDK 1.7 - Dinesh and
Sumanth +1 so far. Mick - I am not sure if you are +0 or -1 on this.

C* 4.0
Circle CI Builds
In addition to existing JDK 1.8 support, build against JDK 11 and
[optionally] run unit tests and DTests against JDK 11. - complete consensus
so far

If anyone has any further feedback, please comment.

Thanks,
Sumanth

On Fri, Aug 24, 2018 at 7:27 AM Sumanth Pasupuleti
 wrote:

> > I'm still a bit confused as to what's the benefit in compiling with
> jdk1.7 and then testing with jdk1.7 or jdk1.8
> I meant two separate workflows for each JDK i.e.
> Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against
> 1.7
> Workflow2: Build against jdk1.8, and run UTs and DTests against 1.8.
>
> > If you find breakages here that otherwise don't exist when it's compiled
> with jdk1.8 then that's just false-positives. As well as generally wasting
> CI resources.
> If we find breakages in workflow1, and not in workflow 2, how would they be
> false positives? we will need to then look into whats causing breakages
> with 1.7, isn't it?
>
> Thanks,
> Sumanth
>
> On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:
>
> > > However, in addition to using such a
> > > tool, I believe, when we make a release, we should build against the
> > actual
> > > JDKs we support (that way, we are not making a release just based on
> the
> > > result of an external tool), and we should be able to optionally run
> UTs
> > > and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).
> >
> >
> > I'm still a bit confused as to what's the benefit in compiling with
> jdk1.7
> > and then testing with jdk1.7 or jdk1.8
> >
> > If you find breakages here that otherwise don't exist when it's compiled
> > with jdk1.8 then that's just false-positives. As well as generally
> wasting
> > CI resources.
> >
> > Either way, there's not much point discussing this as Cassandra-2.1 is
> > about EOL, and Cassandra-4.0 is stuck with a very specific compile.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

> I'm still a bit confused as to what's the benefit in compiling with
jdk1.7 and then testing with jdk1.7 or jdk1.8
I meant two separate workflows for each JDK i.e.
Workflow1: Build against jdk1.7, and optionally run UTs and Dtests against
1.7
Workflow2: Build against jdk1.8, and run UTs and DTests against 1.8.

> If you find breakages here that otherwise don't exist when it's compiled
with jdk1.8 then that's just false-positives. As well as generally wasting
CI resources.
If we find breakages in workflow1, and not in workflow 2, how would they be
false positives? we will need to then look into whats causing breakages
with 1.7, isn't it?

Thanks,
Sumanth

On Thu, Aug 23, 2018 at 7:59 PM, Mick Semb Wever  wrote:

> > However, in addition to using such a
> > tool, I believe, when we make a release, we should build against the
> actual
> > JDKs we support (that way, we are not making a release just based on the
> > result of an external tool), and we should be able to optionally run UTs
> > and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).
>
>
> I'm still a bit confused as to what's the benefit in compiling with jdk1.7
> and then testing with jdk1.7 or jdk1.8
>
> If you find breakages here that otherwise don't exist when it's compiled
> with jdk1.8 then that's just false-positives. As well as generally wasting
> CI resources.
>
> Either way, there's not much point discussing this as Cassandra-2.1 is
> about EOL, and Cassandra-4.0 is stuck with a very specific compile.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Supporting multiple JDKs

[Sumanth Pasupuleti]

I am not against using a compile-time quick-feedback tool like Animal
Sniffer either. It is great to have such a tool to know of any obvious bad
changes right away during development. However, in addition to using such a
tool, I believe, when we make a release, we should build against the actual
JDKs we support (that way, we are not making a release just based on the
result of an external tool), and we should be able to optionally run UTs
and DTests against the JDK  (i.e. Java7 and Java8 for C* 2.2).

> What do we mean "support multiple JDKs" ?
> Are we talking Run-time or Compile-time?
I am talking both - compile-time can for Build, run-time for UTs and DTests.

> I think that dtests are always going to be the important defence here,
and that we simplify it by running dtests on a standardised JDK compile.
I agree, but its good to have an optional workflow in CircleCI to be able
to run DTest against the non-standardized JDK as well, which we support
(Java7 for example, for C*2.2, and Java11 for C* 4.0)

Thanks,
Sumanth

On Thu, Aug 23, 2018 at 12:06 AM Mick Semb Wever  wrote:

>
> > > There's a cost-optimisation here in reducing what we have to support.
> >
> > I agree and animal sniffer is a great way to ferret out obvious issues.
> > I am not against using animal sniffer. I'm concerned that there are
> > various incompatibilities[1] between JDK versions and I am not 100%
> > certain that animal sniffer will catch all of them.
>
>
> Yeah, but is compiling (and unit tests) really any more effective against
> behavioural incompatibilities (which also occur from one patch JDK version
> to the next)?
>
> I think that dtests are always going to be the important defence here, and
> that we simplify it by running dtests on a standardised JDK compile.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Supporting multiple JDKs

[Sumanth Pasupuleti]

Hi,

The goal of this email is to arrive at a solution (probably resulting in a
few follow-ups) to ensure support for multiple JDKs for different versions
of Cassandra.
This comes out of Jason's comment in
https://issues.apache.org/jira/browse/CASSANDRA-14563.

Below is the proposal. Please provide your thoughts.

C* 2.2
Goal:
Need to support Java7 and Java8.
Current State:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* Add CircleCI workflow to build against Java7 (
https://issues.apache.org/jira/browse/CASSANDRA-14625), and optionally run
UTs and DTests against Java7
* Add a tool like AnimalSniffer into build process (proposed by Mick in
https://issues.apache.org/jira/browse/CASSANDRA-14563), so that build would
fail as part of the development process in case of JDK incompatibility.


C* 3.0 and 3.11
Goal:
Support Java8.
Current state:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* No change. Same as current.


C* 4.0
Goal:
Support Java8 and Java11.
Current state:
CircleCI workflow to build, run UTs and DTests against Java8 (run by
default)
Proposed State:
* Add CircleCI workflow to build against Java11, and optionally run UTs and
DTests against Java11

Looking forward to any feedback.

Thanks,
Sumanth

Re: upgrade guava on trunk before 9/1?

[Sumanth Pasupuleti]

Thanks for the confirmation Andy.

Created a JIRA to track the guava upgrade
https://issues.apache.org/jira/browse/CASSANDRA-14655.

I current put target version as 4.x. If a compatible version of the driver
happens to be released soon enough, and if there is a consensus that we
should merge this into 4.0, will change the target version accordingly.
Otherwise, it seems unlikely for 4.0 purely from dependencies perspective.

Thanks,
Sumanth

On Thu, Aug 16, 2018 at 6:47 PM, Andy Tolbert 
wrote:

> Hi Sumanth,
>
> I gave a shot at upgrading to Guava 26.0; resolved build issues; about 63
> > Unit Tests fail - a lot of them due to a NPE and another bunch due to
> > the driver using a method that does not exist in latest Guava.
> >
>
> Unfortunately the driver doesn't currently work with Guava 26.0.  We have a
> fix (JAVA-1928 <https://datastax-oss.atlassian.net/browse/JAVA-1928>) that
> addresses this that will be in version 3.6.0 which should be released in
> the coming weeks.  After that the driver will work with Guava 16.0.1
> through 26 (We've run our full test suite against all versions in that
> range).
>
> Thanks,
> Andy
>
> On Thu, Aug 16, 2018 at 6:55 PM, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > I am +1 on upgrading to latest Guava, given that we would be on 4.0 for a
> > while, and we would have a relatively big testing phase that follows the
> > freeze date, which would hopefully iron out (as much as possible) any
> > issues we may have with the upgrade.
> >
> > I gave a shot at upgrading to Guava 26.0; resolved build issues; about 63
> > Unit Tests fail - a lot of them due to a NPE and another bunch due to
> > the driver using a method that does not exist in latest Guava.
> >
> > Github Branch:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.
> > com_sumanth-2Dpasupuleti_cassandra_tree_guava-5F26-5Ftrunk=DwIFaQ=
> > adz96Xi0w1RHqtPMowiL2g=VHsWqsWT2MoX5jRZ0xZfdAWZxBsrn5KzowynGYCJaXE=
> > NBUK9LYIuBLTb2_dn7ZZnfqkFQuWmAr69kTsiLgthN8=
> > upEwsGydoKbFV9vnRLMO9LEy4YaSlVXBiPoChzsJfCE=
> > Failing Unit Tests: https://urldefense.proofpoint.
> com/v2/url?u=https-3A__
> > circleci.com_gh_sumanth-2Dpasupuleti_cassandra_84=DwIFaQ=
> > adz96Xi0w1RHqtPMowiL2g=VHsWqsWT2MoX5jRZ0xZfdAWZxBsrn5KzowynGYCJaXE=
> > NBUK9LYIuBLTb2_dn7ZZnfqkFQuWmAr69kTsiLgthN8&
> s=oKPrxl_zBsIcuZoHkzS2MZOi9U5_
> > lF3DaNldTbMQsBU=
> >
> > Thanks,
> > Sumanth
> >
> > On Thu, Aug 16, 2018 at 8:22 AM, Jonathan Haddad 
> > wrote:
> >
> > > Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading
> > now
> > >
> > > On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
> > >  wrote:
> > >
> > > > Jason,
> > > > Given that we're so close to the 9/1 date, I would err on the side of
> > > > caution especially given the low value prop. If someone does run into
> > > Guava
> > > > compatibility issues (and someone somewhere will), we can revisit
> this
> > > > question then.
> > > > Dinesh
> > > >
> > > > On Wednesday, August 15, 2018, 11:42:31 PM PDT, Dinesh A. Joshi <
> > > > dinesh.jo...@gatech.edu> wrote:
> > > >
> > > >  Jason,
> > > > Given that we're so close to the 9/1 date, I would err on the side of
> > > > caution especially given the low value prop. If someone does run into
> > > Guava
> > > > compatibility issues (and someone somewhere will), we can revisit
> this
> > > > question then.
> > > > Dinesh
> > > >
> > > > On Wednesday, August 15, 2018, 8:22:28 AM PDT, Salih Gedik <
> > > > m...@salih.xyz> wrote:
> > > >
> > > >  Hi,
> > > >
> > > > Change logs are on Github releases page. It seems like only hash
> > flooding
> > > > protection which is added to ImmutableMap is relevant to Cassandra
> > code.
> > > I
> > > > haven’t checked whether we use deprecated APIs. But there isn’t much
> on
> > > > table from what I see.
> > > >
> > > > Salih
> > > > On 15 Aug 2018 17:55 +0300, Ariel Weisberg ,
> wrote:
> > > > > Hi,
> > > > >
> > > > > They don't even do release notes after 23. Also no API diffs. I
> mean
> > > I'm
> > > > fine with it, but it's mostly just changing to another arbitrary
> > version
> > > > that won't match what is in apps.
> > > > >
> 

Re: upgrade guava on trunk before 9/1?

[Sumanth Pasupuleti]

I am +1 on upgrading to latest Guava, given that we would be on 4.0 for a
while, and we would have a relatively big testing phase that follows the
freeze date, which would hopefully iron out (as much as possible) any
issues we may have with the upgrade.

I gave a shot at upgrading to Guava 26.0; resolved build issues; about 63
Unit Tests fail - a lot of them due to a NPE and another bunch due to
the driver using a method that does not exist in latest Guava.

Github Branch:
https://github.com/sumanth-pasupuleti/cassandra/tree/guava_26_trunk
Failing Unit Tests: https://circleci.com/gh/sumanth-pasupuleti/cassandra/84

Thanks,
Sumanth

On Thu, Aug 16, 2018 at 8:22 AM, Jonathan Haddad  wrote:

> Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading now
>
> On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID
>  wrote:
>
> > Jason,
> > Given that we're so close to the 9/1 date, I would err on the side of
> > caution especially given the low value prop. If someone does run into
> Guava
> > compatibility issues (and someone somewhere will), we can revisit this
> > question then.
> > Dinesh
> >
> > On Wednesday, August 15, 2018, 11:42:31 PM PDT, Dinesh A. Joshi <
> > dinesh.jo...@gatech.edu> wrote:
> >
> >  Jason,
> > Given that we're so close to the 9/1 date, I would err on the side of
> > caution especially given the low value prop. If someone does run into
> Guava
> > compatibility issues (and someone somewhere will), we can revisit this
> > question then.
> > Dinesh
> >
> > On Wednesday, August 15, 2018, 8:22:28 AM PDT, Salih Gedik <
> > m...@salih.xyz> wrote:
> >
> >  Hi,
> >
> > Change logs are on Github releases page. It seems like only hash flooding
> > protection which is added to ImmutableMap is relevant to Cassandra code.
> I
> > haven’t checked whether we use deprecated APIs. But there isn’t much on
> > table from what I see.
> >
> > Salih
> > On 15 Aug 2018 17:55 +0300, Ariel Weisberg , wrote:
> > > Hi,
> > >
> > > They don't even do release notes after 23. Also no API diffs. I mean
> I'm
> > fine with it, but it's mostly just changing to another arbitrary version
> > that won't match what is in apps.
> > >
> > > Ariel
> > >
> > > On Wed, Aug 15, 2018, at 10:48 AM, Jason Brown wrote:
> > > > Hey Ariel,
> > > >
> > > > Tbqh, not that much. I was mostly thinking from the "I have conflicts
> > on
> > > > guava versions in my app because I pull in cassandra and XYZ
> > libraries, and
> > > > the transitive dependencies on guava use different versions" POV.
> > Further,
> > > > we'll be on this version of guava for 4.0 for at least two years from
> > now.
> > > >
> > > > As I asked, "does anybody feeling strongly?". Personally, I'm sorta
> +0
> > to
> > > > +0.5, but I was just throwing this out there in case someone does
> > really
> > > > think it best we upgrade (and wants to make a contribution).
> > > >
> > > > -Jason
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Aug 15, 2018 at 7:25 AM, Ariel Weisberg 
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > What do we get from Guava in exchange for upgrading?
> > > > >
> > > > > Ariel
> > > > >
> > > > > On Wed, Aug 15, 2018, at 10:19 AM, Jason Brown wrote:
> > > > > > Hey all,
> > > > > >
> > > > > > Does anyone feel strongly about upgrading guava on trunk before
> > the 9/1
> > > > > > feature freeze for 4.0? We are currently at 23.3 (thanks to
> > > > > > CASSANDRA-13997), and the current is 26.0.
> > > > > >
> > > > > > I took a quick look, and there's about 17 compilation errors.
> They
> > fall
> > > > > > into two categories, both of which appear not too difficult to
> > resolve (I
> > > > > > didn't look too closely, tbh).
> > > > > >
> > > > > > If anyone wants to tackle this LHF I can rustle up some review
> > time.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > -Jason
> > > > >
> > > > > 
> -
> > > > > 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
> > >
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: [VOTE] Branching Change for 4.0 Freeze

[Sumanth Pasupuleti]

+1 nb
On Fri, Jul 13, 2018 at 6:58 PM Jaydeep Chovatia 
wrote:

> +1
>
> On Wed, Jul 11, 2018 at 2: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
> >
>

Re: Coordinator Write Metrics per CF

[Sumanth Pasupuleti]

I have submitted a patch for
https://issues.apache.org/jira/browse/CASSANDRA-14232. Looking for
reviewers/feedback.

Thanks,
Sumanth

On Tue, Feb 13, 2018 at 2:06 PM, Benedict Elliott Smith <bened...@apache.org
> wrote:

> Sorry, I guess I'm tired.  I thought this was discussing local write
> latency.
>
> I'm surprised we have that and not coordinator write latency.
>
> Please do ignore me, I'm not sure why I got involved!
>
> On 13 February 2018 at 21:48, Benedict Elliott Smith <bened...@apache.org>
> wrote:
>
> > For the record, I'm not certain there *is* a great deal of value in this.
> >
> > The read latency metrics are expected to vary a great deal, since the
> > entire IO subsystem is involved.
> >
> > Writes, however, go straight to a memtable.  They only block on IO if we
> > exceed our commit log flush bandwidth for an extended period of time.  We
> > already have a metric for tracking this: CommitLog.WaitingOnCommit.
> >
> > I'm not saying there won't be any latency distribution, but it is
> unlikely
> > to be terribly interesting in very many situations.  I can't off the top
> of
> > my head think of a good reason to consult this metric, that couldn't
> better
> > be answered elsewhere.
> >
> >
> >
> > On 13 February 2018 at 19:18, Sumanth Pasupuleti <
> spasupul...@netflix.com.
> > invalid> wrote:
> >
> >> Thanks Kurt and Chris for your valuable inputs. Created
> >> https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start
> >> working on this.
> >>
> >> Thanks,
> >> Sumanth
> >>
> >> On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink <clohf...@apple.com>
> >> wrote:
> >>
> >> > It would be good to have it. Its not that its not there because its
> >> > difficult or anything. I think its more that the read latency metric
> was
> >> > needed for speculative retry so it was added but the write side wasn't
> >> > needed for that feature so wasn't added at same time. It would be very
> >> > useful in determining the table that the coordinator writes are slow
> to.
> >> >
> >> > Chris
> >> >
> >> > > On Feb 11, 2018, at 10:33 PM, kurt greaves <k...@instaclustr.com>
> >> wrote:
> >> > >
> >> > > I've tried to search around for a reason for this in the past and
> >> haven't
> >> > > found one. I don't think it's a bad idea. Would be a helpful metric
> to
> >> > > diagnose internode networking issues - although I'll note that the
> >> read
> >> > > metric will also achieve this assuming you have enough reads to get
> >> some
> >> > > useful information out of it.
> >> > >
> >> > > On 9 February 2018 at 17:43, Sumanth Pasupuleti <
> >> > > sumanth.pasupuleti...@gmail.com> wrote:
> >> > >
> >> > >> There is an existing CoordinatorReadLatency table metric. I am
> >> looking
> >> > to
> >> > >> add CoordinatorWriteLatency table metric - however, before I
> attempt
> >> a
> >> > shot
> >> > >> at it, would like to know if anyone has context around why we
> >> currently
> >> > do
> >> > >> not have such metric (while we have the read metric) - if someone
> has
> >> > >> already attempted and realized its a bad idea for some reason.
> >> > >>
> >> > >> Thanks,
> >> > >> Sumanth
> >> > >>
> >> >
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >> >
> >> >
> >>
> >
> >
>

Re: Coordinator Write Metrics per CF

[Sumanth Pasupuleti]

Thanks Kurt and Chris for your valuable inputs. Created
https://issues.apache.org/jira/browse/CASSANDRA-14232; I shall start
working on this.

Thanks,
Sumanth

On Mon, Feb 12, 2018 at 7:43 AM, Chris Lohfink <clohf...@apple.com> wrote:

> It would be good to have it. Its not that its not there because its
> difficult or anything. I think its more that the read latency metric was
> needed for speculative retry so it was added but the write side wasn't
> needed for that feature so wasn't added at same time. It would be very
> useful in determining the table that the coordinator writes are slow to.
>
> Chris
>
> > On Feb 11, 2018, at 10:33 PM, kurt greaves <k...@instaclustr.com> wrote:
> >
> > I've tried to search around for a reason for this in the past and haven't
> > found one. I don't think it's a bad idea. Would be a helpful metric to
> > diagnose internode networking issues - although I'll note that the read
> > metric will also achieve this assuming you have enough reads to get some
> > useful information out of it.
> >
> > On 9 February 2018 at 17:43, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> >> There is an existing CoordinatorReadLatency table metric. I am looking
> to
> >> add CoordinatorWriteLatency table metric - however, before I attempt a
> shot
> >> at it, would like to know if anyone has context around why we currently
> do
> >> not have such metric (while we have the read metric) - if someone has
> >> already attempted and realized its a bad idea for some reason.
> >>
> >> Thanks,
> >> Sumanth
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Coordinator Write Metrics per CF

[Sumanth Pasupuleti]

There is an existing CoordinatorReadLatency table metric. I am looking to
add CoordinatorWriteLatency table metric - however, before I attempt a shot
at it, would like to know if anyone has context around why we currently do
not have such metric (while we have the read metric) - if someone has
already attempted and realized its a bad idea for some reason.

Thanks,
Sumanth

Re: TWCS High Disk Space Usage Troubleshooting - Looking for suggestions

[Sumanth Pasupuleti]

My final try on pushing the attachment over.


​

On Wed, Aug 9, 2017 at 4:01 PM, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Thanks for the insights Jeff! I did go through the tickets around dropping
> expired sstables that have overlaps - based on what I understand, the only
> undesirable impact of that would be possible data resurrection.
>
> I have now attached the output of sstableslicer with the mail. Will submit
> a patch for review.
>
> Thanks,
> Sumanth
>
> On Tue, Aug 8, 2017 at 9:49 PM, Jeff Jirsa <jji...@gmail.com> wrote:
>
>> The most likely cause is read repairs due to consistency level repairs
>> (digest mismatch). The only way to actually eliminate read repair is to
>> read with CL:ONE, which almost nobody does (at least in time series use
>> cases, because it implies you probably write with ALL, or run repair which
>> - as you've noted - often isn't necessary in ttl-only use cases).
>>
>> I can't see the image, but more tools for understanding sstable state are
>> never a bad thing (as long as they're generally useful and maintainable).
>>
>> For what it's worth, there are tickets in flight for being more aggressive
>> at dropping overlaps, but there are companies that use tools that stop the
>> cluster, use sstablemetadata to identify sstables we knew should be fully
>> expired, and manually remove them (/bin/rm) before starting cassandra
>> again. It works reasonably well IF (and only if) you write all data with
>> TTLs, and you can identify fully expired sstables based on maximum
>> timestamps.
>>
>>
>>
>>
>> On Tue, Aug 8, 2017 at 8:51 PM, Sumanth Pasupuleti <
>> sumanth.pasupuleti...@gmail.com> wrote:
>>
>> > Hi,
>> >>
>> >> We use TWCS in a few of the column families that have TTL based
>> >> time-series data, and no explicit deletes are issued. Over the time, we
>> >> observed the disk usage has been increasing beyond the expected levels.
>> >>
>> >> Data directory in a particular node shows SSTables that are more than
>> >> 16days old, while the bucket size is configured at 12hours, TTL is at
>> >> 15days and GC grace at 1hour.
>> >> Upon using sstableexpiredblockers, we got quite a few sets of blocking
>> >> and blocked SSTables. SSTableMetadata that is shown in the output
>> indicates
>> >> there is an overlap in the MinTS-MaxTS period among the blocking
>> SSTable
>> >> and the blocked SSTables, which is preventing the older SSTables from
>> >> getting dropped/deleted.
>> >>
>> >> Following are the possible root causes we considered
>> >>
>> >>1. Hints - old data hints getting replayed from the coordinator
>> node.
>> >>We ruled this out since hints live for no more than 1 day based on
>> our
>> >>configuration.
>> >>2. External compactions - no external compactions were run, that
>> >>could cause compaction of SSTables across the TWCS buckets.
>> >>3.  Read repairs - this is ruled out as well, since we never ran
>> >>external repairs, and read repair chance on the TWCS column
>> families has
>> >>been set to 0.
>> >>4.  Application team writing data with older timestamp (in newer
>> >>SSTables).
>> >>
>> >>
>> >>1. We wanted to identify the specific row keys with older timestamps
>> >>   in the blocking SSTable, that could be causing this issue to
>> occur. We
>> >>   considered using SSTable2Keys/json, however, since both the
>> tools involve
>> >>   outputting the entire content/keys of the SSTable in the order
>> of the keys,
>> >>   they were not helpful in this case.
>> >>   2. Since we wanted to get data on a few oldest cells with
>> >>   timestamps, we created a tool mostly based off of sstable2json,
>> called
>> >>   sstableslicer, to output 'n' top/bottom cells in an SSTable,
>> ordered either
>> >>   on writetime/localDeletionTime. This helped us identify the
>> specific cells
>> >>   in new SSTables with older timestamps, which further helped in
>> debugging on
>> >>   the application end. From application team perspective, however,
>> writing
>> >>   data with old timestamp is not a possible scenario.
>> >>
>> >>3. Below is a sample output of sstableslicer
>> > [image: Inline image 2]
>> >
>> >
>> >> Looking for suggestions, especially around following two things:
>> >>
>> >>1. Did we miss any other case in TWCS that could be causing such
>> >>overlap?
>> >>2. Does sstableslicer seem valuable, to be included in Apache C*? If
>> >>yes, I shall create a JIRA and submit a PR/patch for review.
>> >>
>> >> C* version we use is 2.1.17.
>> >
>> > Thanks,
>> >> Sumanth
>> >>
>> >
>>
>
>

Re: TWCS High Disk Space Usage Troubleshooting - Looking for suggestions

[Sumanth Pasupuleti]

Thanks for the insights Jeff! I did go through the tickets around dropping
expired sstables that have overlaps - based on what I understand, the only
undesirable impact of that would be possible data resurrection.

I have now attached the output of sstableslicer with the mail. Will submit
a patch for review.

Thanks,
Sumanth

On Tue, Aug 8, 2017 at 9:49 PM, Jeff Jirsa <jji...@gmail.com> wrote:

> The most likely cause is read repairs due to consistency level repairs
> (digest mismatch). The only way to actually eliminate read repair is to
> read with CL:ONE, which almost nobody does (at least in time series use
> cases, because it implies you probably write with ALL, or run repair which
> - as you've noted - often isn't necessary in ttl-only use cases).
>
> I can't see the image, but more tools for understanding sstable state are
> never a bad thing (as long as they're generally useful and maintainable).
>
> For what it's worth, there are tickets in flight for being more aggressive
> at dropping overlaps, but there are companies that use tools that stop the
> cluster, use sstablemetadata to identify sstables we knew should be fully
> expired, and manually remove them (/bin/rm) before starting cassandra
> again. It works reasonably well IF (and only if) you write all data with
> TTLs, and you can identify fully expired sstables based on maximum
> timestamps.
>
>
>
>
> On Tue, Aug 8, 2017 at 8:51 PM, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> wrote:
>
> > Hi,
> >>
> >> We use TWCS in a few of the column families that have TTL based
> >> time-series data, and no explicit deletes are issued. Over the time, we
> >> observed the disk usage has been increasing beyond the expected levels.
> >>
> >> Data directory in a particular node shows SSTables that are more than
> >> 16days old, while the bucket size is configured at 12hours, TTL is at
> >> 15days and GC grace at 1hour.
> >> Upon using sstableexpiredblockers, we got quite a few sets of blocking
> >> and blocked SSTables. SSTableMetadata that is shown in the output
> indicates
> >> there is an overlap in the MinTS-MaxTS period among the blocking SSTable
> >> and the blocked SSTables, which is preventing the older SSTables from
> >> getting dropped/deleted.
> >>
> >> Following are the possible root causes we considered
> >>
> >>1. Hints - old data hints getting replayed from the coordinator node.
> >>We ruled this out since hints live for no more than 1 day based on
> our
> >>configuration.
> >>2. External compactions - no external compactions were run, that
> >>could cause compaction of SSTables across the TWCS buckets.
> >>3.  Read repairs - this is ruled out as well, since we never ran
> >>external repairs, and read repair chance on the TWCS column families
> has
> >>been set to 0.
> >>4.  Application team writing data with older timestamp (in newer
> >>SSTables).
> >>
> >>
> >>1. We wanted to identify the specific row keys with older timestamps
> >>   in the blocking SSTable, that could be causing this issue to
> occur. We
> >>   considered using SSTable2Keys/json, however, since both the tools
> involve
> >>   outputting the entire content/keys of the SSTable in the order of
> the keys,
> >>   they were not helpful in this case.
> >>   2. Since we wanted to get data on a few oldest cells with
> >>   timestamps, we created a tool mostly based off of sstable2json,
> called
> >>   sstableslicer, to output 'n' top/bottom cells in an SSTable,
> ordered either
> >>   on writetime/localDeletionTime. This helped us identify the
> specific cells
> >>   in new SSTables with older timestamps, which further helped in
> debugging on
> >>   the application end. From application team perspective, however,
> writing
> >>   data with old timestamp is not a possible scenario.
> >>
> >>3. Below is a sample output of sstableslicer
> > [image: Inline image 2]
> >
> >
> >> Looking for suggestions, especially around following two things:
> >>
> >>1. Did we miss any other case in TWCS that could be causing such
> >>overlap?
> >>2. Does sstableslicer seem valuable, to be included in Apache C*? If
> >>yes, I shall create a JIRA and submit a PR/patch for review.
> >>
> >> C* version we use is 2.1.17.
> >
> > Thanks,
> >> Sumanth
> >>
> >
>

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

TWCS High Disk Space Usage Troubleshooting - Looking for suggestions

[Sumanth Pasupuleti]

>
> Hi,
>
> We use TWCS in a few of the column families that have TTL based
> time-series data, and no explicit deletes are issued. Over the time, we
> observed the disk usage has been increasing beyond the expected levels.
>
> Data directory in a particular node shows SSTables that are more than
> 16days old, while the bucket size is configured at 12hours, TTL is at
> 15days and GC grace at 1hour.
> Upon using sstableexpiredblockers, we got quite a few sets of blocking and
> blocked SSTables. SSTableMetadata that is shown in the output indicates
> there is an overlap in the MinTS-MaxTS period among the blocking SSTable
> and the blocked SSTables, which is preventing the older SSTables from
> getting dropped/deleted.
>
> Following are the possible root causes we considered
>
>1. Hints - old data hints getting replayed from the coordinator node.
>We ruled this out since hints live for no more than 1 day based on our
>configuration.
>2. External compactions - no external compactions were run, that could
>cause compaction of SSTables across the TWCS buckets.
>3.  Read repairs - this is ruled out as well, since we never ran
>external repairs, and read repair chance on the TWCS column families has
>been set to 0.
>4.  Application team writing data with older timestamp (in newer
>SSTables).
>
>
>1. We wanted to identify the specific row keys with older timestamps
>   in the blocking SSTable, that could be causing this issue to occur. We
>   considered using SSTable2Keys/json, however, since both the tools 
> involve
>   outputting the entire content/keys of the SSTable in the order of the 
> keys,
>   they were not helpful in this case.
>   2. Since we wanted to get data on a few oldest cells with
>   timestamps, we created a tool mostly based off of sstable2json, called
>   sstableslicer, to output 'n' top/bottom cells in an SSTable, ordered 
> either
>   on writetime/localDeletionTime. This helped us identify the specific 
> cells
>   in new SSTables with older timestamps, which further helped in 
> debugging on
>   the application end. From application team perspective, however, writing
>   data with old timestamp is not a possible scenario.
>
>3. Below is a sample output of sstableslicer
[image: Inline image 2]


> Looking for suggestions, especially around following two things:
>
>1. Did we miss any other case in TWCS that could be causing such
>overlap?
>2. Does sstableslicer seem valuable, to be included in Apache C*? If
>yes, I shall create a JIRA and submit a PR/patch for review.
>
> C* version we use is 2.1.17.

Thanks,
> Sumanth
>