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

[sankalp kohli]

+1 to all

On Thu, Oct 14, 2021 at 11:57 AM C. Scott Andreas 
wrote:

> 1. +1nb
> 2. +1nb
> 3. +1nb
>
> It’s been encouraging to follow discussion advancing potential
> enhancements to this proposal on the other threads.
>
> I disagree that it is a good outcome for the project and the Apache
> Cassandra user community to veto significant progress in this area on
> grounds that the CEP does not contain a design for a feature that is a
> non-goal of the initial scope proposed by the CEP, and which is also not
> precluded by the CEP.
>
> - Scott
>
> > On Oct 14, 2021, at 11:27 AM, Aleksey Yeschenko 
> wrote:
> >
> > +1 on all points
> >
> >> On 14 Oct 2021, at 17:31, bened...@apache.org wrote:
> >> Hi everyone,
> >> I would like to start a vote on this CEP, split into three
> sub-decisions, as discussion has been circular for some time.
> >> 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?
> >> The first vote is a consensus vote of all committers, the second and
> third however are about project direction and therefore are simple majority
> votes of the PMC.
> >> Recall that all -1 votes must be accompanied by an explanation. If you
> reject the CEP only on grounds (2) or (3) you should not veto the proposal.
> If a majority reject grounds (2) or (3) then transaction developments will
> halt for the time being.
> >> This vote will be open for 72 hours.
> >
> >
> > -
> > 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 Yifan Cai as Cassandra committer

[sankalp kohli]

Congratulations Yifan.

On Mon, Dec 21, 2020 at 9:10 AM Benjamin Lerer 
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
>

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

[sankalp kohli]

Congratulations everyone.

On Wed, Dec 16, 2020 at 11:53 AM Lorina Poland  wrote:

> I'm really excited to see these four folks become committers!
> Congratulations!
>
> Lorina Poland
>
>
>
> On Wed, Dec 16, 2020 at 11:16 AM Paulo Motta 
> wrote:
>
> > Great news, congratulations to the new committers!
> >
> > Em qua., 16 de dez. de 2020 às 14:52, Patrick McFadin <
> pmcfa...@gmail.com>
> > escreveu:
> >
> > > Congratulations Jordan, David, Zhao and Ekaterina! It's great to see
> your
> > > names on the committer list! You have definitely made Apache Cassandra
> > > better through your efforts.
> > >
> > > Patrick
> > >
> > > On Wed, Dec 16, 2020 at 9:03 AM Jonathan Ellis 
> > wrote:
> > >
> > > > Well-deserved congratulations!
> > > >
> > > > On Wed, Dec 16, 2020 at 10:56 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
> > > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
> >
>

Re: Creating a branch for 5.0 …?

[sankalp kohli]

Hi,
I hear the following
"Freeze is causing contributions to go away and stopping innovation"
"Lack of 4.0 release is causing people to think C* is dead."

I think it is important to think why we are here. We are here as we shipped
3.0 with 10s of correctness bug. So the statements should be
"3.0 shipped with 10s of correctness bugs and that is causing contributions
to go away and stopping innovation"
"Lack of 4.0 release due to 3.0 shipping with 10s of correctness bugs is
causing people to think C* is dead."

Once we start putting it this way, we can start debating on how not to make
4.0 like 3.0 and cause 5.0 to be delayed. So instead of focusing on
symptoms and major effects 3.0 + correctness bugs has caused, lets talk
about following

1. How can we make 4.0 stable so we dont have to freeze for 2+ years and
dont ship with 10s of correctness bugs.
2. How can we have a stable .0 release instead of people not using it for
10th minor.
3. How can we have a predictable timeline for major releases like 4.0 so
contributors/users knows how to plan around it.

I think it is more important to fix the root cause than fixing the
symptoms.

Thanks,
Sankalp






On Thu, Sep 24, 2020 at 10:50 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli 
> wrote:
> >
> > Hi Brandon,
> >   In all respect, we need to discuss and vote before we
> > create a new branch. So it is best if we do that instead of creating
> > branches.
>
> Fair enough.
>
> > Freeze is a symptom not a cause so if we dont like the symptom,
> > we should see how to fix the cause. Are we fine having a database release
> > which will be released with 10s of  correctness bugs and with an implicit
> > assumption that no one will use it in prod till 10th minor.
>
> I think we're making quite a leap to go from adding new features in
> one branch equating to releasing software with more bugs in a
> completely different branch.  I think your concern is that by having
> the project 'bless' a feature-accepting branch, this will detract from
> time they would otherwise spend on stabilizing the release branch (if
> we had one.)  I can't fault you for this, it may be a real
> possibility, nobody knows.  Nothing can be done about changing what
> people decide to work on in a free project, however, and it would be
> naive to think there are not people already out there interested in
> working purely on new features, with no dog in the stability of 4.0
> fight.  I know that's not conducive to your goals (and honestly I'd
> rather they help on the 4.0 side too) but that's just the way things
> are.
>
> > Everyone wants to innovate but security, durability and availability
> comes
> > first.  People who are working on stabilizing 4.0 are doing it as there
> is
> > no other choice. So I request you to kindly cooperate on working with
> them
> > in making 4.0 a stable release.
>
> Sorry, but I respectfully refuse your statement that there is no other
> choice.  This is a free project and there is always a choice for those
> who may wish to donate their time.  I would like to cast a wide enough
> net to allow all their itches to be scratched here for the future
> health of this project.
>
> Kind Regards,
> Brandon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Creating a branch for 5.0 …?

[sankalp kohli]

Hi Brandon,
  In all respect, we need to discuss and vote before we
create a new branch. So it is best if we do that instead of creating
branches. Freeze is a symptom not a cause so if we dont like the symptom,
we should see how to fix the cause. Are we fine having a database release
which will be released with 10s of  correctness bugs and with an implicit
assumption that no one will use it in prod till 10th minor.

Everyone wants to innovate but security, durability and availability comes
first.  People who are working on stabilizing 4.0 are doing it as there is
no other choice. So I request you to kindly cooperate on working with them
in making 4.0 a stable release.

https://tinyurl.com/30seriousissues


Thanks,
Sankalp

On Thu, Sep 24, 2020 at 9:30 AM Brandon Williams  wrote:

> On Thu, Sep 24, 2020 at 11:22 AM Benedict Elliott Smith
>  wrote:
> > Given this is the basis of argument, I would also propose a less
> contentious vote, should one be undertaken: to create a cassandra-5.0
> branch that is open only to contributions from those unaffiliated by
> employment with any existing committers.
>
> Are you serious?  What kind of opensource environment is it that
> precludes anyone from contributing based on their employment?
>
> -
> 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

[sankalp kohli]

+1

On Wed, Sep 16, 2020 at 10:07 AM Ekaterina Dimitrova 
wrote:

> +1 (non-binding)
>
> On Wed, 16 Sep 2020 at 12:52, Dinesh Joshi  wrote:
>
> > +1
> >
> >
> >
> > Dinesh
> >
> >
> >
> > > On Sep 16, 2020, at 9:30 AM, Joshua McKenzie 
> > wrote:
> >
> > >
> >
> > > +1
> >
> > >
> >
> > >
> >
> > >> On Wed, Sep 16, 2020 at 11:22 AM, Aleksey Yeshchenko <
> >
> > >> alek...@apple.com.invalid> wrote:
> >
> > >>
> >
> > >> +1
> >
> > >>
> >
> > >> On 16 Sep 2020, at 16:09, Sumanth Pasupuleti
> >  >
> > >> com> wrote:
> >
> > >>
> >
> > >> +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
> >
> > >>
> >
> > >> -
> 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 research on C* usage for blog

[sankalp kohli]

+1 to the blog post

On Thu, Aug 27, 2020 at 10:53 AM Jeff Jirsa  wrote:

> I don't have any questions, but datastax folks: thanks for funding stuff
> like this.
>
> (I'd love to see it as a blog post, I'd also love to see people internalize
> the negative feedback and assumed features and determine whether or not
> people are working on the right things)
>
> On Thu, Aug 27, 2020 at 10:25 AM Melissa Logan 
> wrote:
>
> > Hi everyone,
> >
> > Several open source projects conduct regular user surveys to understand
> > current usage and adoption trends, e.g. OpenStack, Kubernetes, Cloud
> > Foundry, etc. They can be informative to the community and other end
> users.
> > It looks like the C* community may have conducted these in the past per
> > https://twitter.com/cassandra/status/649287871577219072.
> >
> > Recently, an independent research company called Clearpath Strategies was
> > funded by DataStax to conduct research on C* usage and adoption, and they
> > would like to contribute the findings to the community.
> >
> > 901 practitioners were interviewed. I analyzed the data and summarized
> in a
> > document here:
> >
> >
> https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing
> >
> > If this seems broadly useful, I’m proposing that we publish to the C*
> blog.
> > New graphics will be created in the same styling as the 4.0 graphic as
> > noted in the doc.
> >
> > If you have questions about the data, please share here or in the doc.
> >
> > Appreciate your thoughts and consideration.
> >
> > Melissa
> >
>

Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)

[sankalp kohli]

+1

On Mon, Jul 20, 2020 at 10:58 AM Blake Eggleston
 wrote:

> +1
>
> > On Jul 20, 2020, at 9:56 AM, Jon Haddad  wrote:
> >
> > +1, thanks Mick for rerolling.
> >
> > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie 
> > wrote:
> >
> >> +1
> >>
> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani  wrote:
> >>
> >>> +1
> >>>
> >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña <
> >>> a.penya.gar...@gmail.com>
> >>> wrote:
> >>>
>  +1 (nb)
> 
>  On Mon, 20 Jul 2020 at 12:58, João Reis 
> >> wrote:
> 
> > +1 (nb)
> >
> > The drivers smoke test suite looks good:
> >
> >
> >
> 
> >>>
> >>
> https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004
> >
> > Mick Semb Wever  escreveu no dia sábado, 18/07/2020
> >>> à(s)
> > 00:27:
> >
> >> Proposing the test build of Cassandra 4.0-beta1 for release.
> >>
> >> sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> >> 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-1211/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 60 hours (longer if needed). I've taken
> >> 12
> > hours
> >> off the normal 72 hours and this follows closely after the initial
> >> 4.0-beta1 vote. 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
> >>
> >
> 
> >>>
> >>>
> >>> --
> >>> http://twitter.com/tjake
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] A point of view on Testing Cassandra

[sankalp kohli]

Can you please allow comments on the doc so we can leave feedback.

On Mon, Jul 13, 2020 at 2:16 PM Joshua McKenzie 
wrote:

> Link:
>
> https://docs.google.com/document/d/1ktuBWpD2NLurB9PUvmbwGgrXsgnyU58koOseZAfaFBQ/edit#
>
>
> Myself and a few other contributors are working with this point of view as
> our frame of where we're going to work on improving testing on the project.
> I figured it might be useful to foster collaboration more broadly in the
> community as well as provide people with the opportunity to discuss work
> they're doing they may not yet have had a chance to bring up or open
> source. While fallout is already open-sourced, expect the schema anonymizer
> and some of the cassandra-diff + nosqlbench framework effort to be
> open-sourced / openly worked on soon. Anyone that's interested in
> collaborating, that would be highly welcome.
>
> Doc is view only; figured we could keep this to the ML.
>
> Thanks.
>
> ~Josh
>

Re: [DISCUSS] Future of MVs

[sankalp kohli]

I see this discussion as several decisions which can be made in small
increments.

1. In release cycles, when can we propose a feature to be deprecated or
marked experimental. Ideally a new feature should come out experimental if
required but we have several who are candidates now. We can work on
integrating this in the release lifecycle doc we already have.
2. What is the process of making an existing feature experimental? How does
it affect major releases around testing.
3. What is the process of deprecating/removing an experimental feature.
(Assuming experimental features should be deprecated/removed)

Coming to MV, I think we need more data before we can say we
should deprecate MV. Here are some of them which should be part of
deprecation process
1.Talk to customers who use them and understand what is the impact. Give
them a forum to talk about it.
2. Do we have enough resources to bring this feature out of the
experimental feature list in next 1 or 2 major releases. We cannot have too
many experimental features in the database. Marking a feature experimental
should not be a parking place for a non functioning feature but a place
while we stabilize it.




On Tue, Jun 30, 2020 at 4:52 PM  wrote:

> I followed up with the clarification about unit and dtests for that reason
> Dinesh. We test experimental features now.
>
> If we’re talking about adding experimental features to the 40 quality
> testing effort, how does that differ from just saying “we won’t release
> until we’ve tested and stabilized these features and they’re no longer
> experimental”?
>
> Maybe I’m just misunderstanding something here?
>
> > On Jun 30, 2020, at 7:12 PM, Dinesh Joshi  wrote:
> >
> > 
> >>
> >> On Jun 30, 2020, at 4:05 PM, Brandon Williams  wrote:
> >>
> >> Instead of ripping it out, we could instead disable them in the yaml
> >> with big fat warning comments around it.  That way people already
> >> using them can just enable them again, but it will raise the bar for
> >> new users who ignore/miss the warnings in the logs and just use them.
> >
> > Not a bad idea. Although, the real issue is that users enable MV on a 3
> node cluster with a few megs of data and conclude that MVs will
> horizontally scale with the size of data. This is what causes issues for
> users who naively roll it out in production and discover that MVs do not
> scale with their data growth. So whatever we do, the big fat warning should
> educate the unsuspecting operator.
> >
> > Dinesh
> > -
> > 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] Project governance wiki doc (take 2)

[sankalp kohli]

+1

On Wed, Jun 24, 2020 at 8:37 AM Jake Luciani  wrote:

> +1 (b)
>
> On Wed, Jun 24, 2020 at 9:59 AM Joshua McKenzie 
> wrote:
>
> > A reminder: this vote will close at midnight PST today in roughly 17
> hours.
> >
> >
> > On Mon, Jun 22, 2020 at 2:20 PM J. D. Jordan 
> > wrote:
> >
> > > +1 non-binding
> > >
> > > > On Jun 22, 2020, at 1:18 PM, Stefan Podkowinski 
> > wrote:
> > > >
> > > > +1
> > > >
> > > >> On 22.06.20 20:12, Blake Eggleston wrote:
> > > >> +1
> > > >>
> > >  On Jun 20, 2020, at 8:12 AM, Joshua McKenzie <
> jmcken...@apache.org>
> > > wrote:
> > > >>>
> > > >>> Link to doc:
> > > >>>
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > >>>
> > > >>> Change since previous cancelled vote:
> > > >>> "A simple majority of this electorate becomes the low-watermark for
> > > votes
> > > >>> in favour necessary to pass a motion, with new PMC members added to
> > the
> > > >>> calculation."
> > > >>>
> > > >>> This previously read "super majority". We have lowered the low
> water
> > > mark
> > > >>> to "simple majority" to balance strong consensus against risk of
> > stall
> > > due
> > > >>> to low participation.
> > > >>>
> > > >>>
> > > >>>   - Vote will run through 6/24/20
> > > >>>   - pmc votes considered binding
> > > >>>   - simple majority of binding participants passes the vote
> > > >>>   - committer and community votes considered advisory
> > > >>>
> > > >>> Lastly, I propose we take the count of pmc votes in this thread as
> > our
> > > >>> initial roll call count for electorate numbers and low watermark
> > > >>> calculation on subsequent votes.
> > > >>>
> > > >>> Thanks again everyone (and specifically Benedict and Jon) for the
> > time
> > > and
> > > >>> collaboration on this.
> > > >>>
> > > >>> ~Josh
> > > >>
> > > >>
> -
> > > >> 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
> > >
> > >
> >
>
>
> --
> http://twitter.com/tjake
>

List of serious issues fixed in 3.0.x

[sankalp kohli]

Hi,
I want to share some of the serious issues that were found and fixed in
3.0.x. I have created this list from JIRA to help us identify areas for
validating 4.0.  This will also give an insight to the dev community.

Let us know if anyone has suggestions on how to better use this data in
validating 4.0. Also this list might be missing some issues identified
early on in 3.0.x or some latest ones.

Link: https://tinyurl.com/30seriousissues

Thanks,
Sankalp

Re: Discussion: addition to CEP guide

[sankalp kohli]

+1

On Thu, Apr 23, 2020 at 6:07 AM Andrés de la Peña 
wrote:

> +1 (nb)
>
> On Thu, 23 Apr 2020 at 13:09, Aleksey Yeshchenko  >
> wrote:
>
> > +1
> >
> > > On 23 Apr 2020, at 12:58, Benjamin Lerer 
> > 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 
> > >>> 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
> >
> >
>

Re: Keeping test-only changes out of CHANGES.txt

[sankalp kohli]

Thanks

On Wed, Apr 15, 2020 at 10:32 AM Mick Semb Wever  wrote:

> > Can we vote(if required) on this as it looks largely everyone is in
> > agreement?
>
>
> I knew I forgot to post a reply here, thanks for the nudge sankalp, my bad.
>
> I took the above thread as consensus and last Friday committed it,
> along with the documentation update from Eduard.
>
> https://github.com/apache/cassandra/commit/141ea26733e7e8fe022bc78f7fd68225013e8d14
>
> So this is also reflected in the CHANGES.txt found in 4.0-alpha4
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Keeping test-only changes out of CHANGES.txt

[sankalp kohli]

Can we vote(if required) on this as it looks largely everyone is in
agreement?
Also we can pile on documentation changes in the vote unless anyone
objects.

On Fri, Apr 10, 2020 at 2:52 PM Erick Ramirez 
wrote:

> >
> > In a conversation with Mick we discussed keeping doc changes out as well.
> > Anyone object to eliding documentation changes from CHANGES.txt?
> >
>
> +1 It will just get too noisy otherwise.
>

Re: server side describe

[sankalp kohli]

What are the next steps? Do we hold a vote as I see few initial emails
which dont seem to agree and have not replied based on future discussions.

On Fri, Apr 10, 2020 at 12:50 PM Dinesh Joshi  wrote:

> +1 let's keep moving forward.
>
> Dinesh
>
> > On Apr 9, 2020, at 4:07 PM, Nate McCall  wrote:
> >
> > Ok cool. It sounds like we are moving this towards a consensus? (at least
> > agreeing to disagree and moving forward).
> >
> > I very much the different inputs on this thread - thanks for a largely
> > healthy discussion folks.
> >
> > On Fri, Apr 10, 2020 at 6:03 AM Chris Lohfink 
> wrote:
> >
> >> I'd be in favor of going with the newer DESCRIBE option. The original
> patch
> >> was mostly focused on just getting the CQL correct and used virtual
> tables
> >> because its what the initial feedback was to do. Robert added a lot of
> >> functionality on top of what was there which is what people were
> starting
> >> to ask for. I am in favor of just going off of his patch and moving
> >> forward. I initially heard post 4.0 so I know I haven't been focused on
> it
> >> but if theres desire to put it in 4.0 I am +1 on it and would like to
> see
> >> just going off of the Robert's latest patch.
> >>
> >> Chris
> >>
> >> On Thu, Apr 9, 2020 at 6:41 AM Benjamin Lerer <
> benjamin.le...@datastax.com
> >>>
> >> wrote:
> >>
> >>> Thanks for your answer Alex.
> >>>
> >>> Some of the things we
>  have explicitly (as a community) agreed to commit are still in
> >> progress,
>  including several client protocol changes. And, to my understanding,
> if
>  those are committed, it'll be what community has agreed upon.
> 
> >>>
> >>> If the understanding of the community was that this patch was expected
> to
> >>> go in 4.0 then it makes sense to commit it there.
> >>>
> >>>
>  If the discussion is about whether or not to include _some_ version of
> >>> the
>  patch, I think including it makes sense, especially given the patch
> was
>  there for a while and was not committed for non-technical reasons. If
> >>> we're
>  trying to decide _which_ patch to commit, I'd personally focus on the
>  original patch (to foster recognition), get it reviewed, and pick any
>  changes that make it better from the follow-up one (to foster
>  collaboration).
> 
> >>>
> >>> I am fine going through both patches and figuring out a way to merge
> them
> >>> into one if Jon or somebody else is willing to review the output of
> that
> >>> merge
> >>>
> >>>
> >>>
> >>> On Thu, Apr 9, 2020 at 12:45 PM Benedict Elliott Smith <
> >>> bened...@apache.org>
> >>> wrote:
> >>>
>  +1 all of this
> 
>  On 09/04/2020, 10:23, "Oleksandr Petrov"  >
>  wrote:
> 
> > My understanding is that a majority of people ended up in favor
> >> of
> a DESCRIBE approach. Robert made a patch for that approach
> >> (according
>  to
> his comment it was discussed with Chris beforehand).
> 
> This sounds like just a switch of API (in other words, you use the
> >>> same
> string generation, but return it via different means). From the
>  (little)
> time I've spent looking at the patch, I remember that there wasn't
> >>> much
> common code between the two (sorry if I'm remembering it wrong).
> 
> If the discussion is about whether or not to include _some_ version
> >>> of
>  the
> patch, I think including it makes sense, especially given the patch
> >>> was
> there for a while and was not committed for non-technical reasons.
> >> If
>  we're
> trying to decide _which_ patch to commit, I'd personally focus on
> >> the
> original patch (to foster recognition), get it reviewed, and pick
> >> any
> changes that make it better from the follow-up one (to foster
> collaboration).
> 
> > Where do we draw the line?
> 
> I would discuss changes on the case-by-case basis. Some of the
> >> things
>  we
> have explicitly (as a community) agreed to commit are still in
>  progress,
> including several client protocol changes. And, to my
> >> understanding,
> >>> if
> those are committed, it'll be what community has agreed upon. All
>  further
> changes that weren't discussed yet - we can talk over. If it's
>  something as
> trivial as server-side describe that doesn't risk stability but
> >> adds
> >>> a
>  lot
> of value, it may make sense to include. But I woudln't attempt to
> >>> come
>  up
> with a general rule for what we may or may not consider for now.
> 
> 
> On Mon, Apr 6, 2020 at 3:21 PM Benjamin Lerer <
>  benjamin.le...@datastax.com>
> wrote:
> 
> > We have already discussed it for several days and I believe that
> >>> all
>  the
> > points have been brought to the table.
> >
> > I took the time to read CASSANDRA-14825 this 

Re: Simplify voting rules for in-jvm-dtest-api releases

[sankalp kohli]

+1

On Wed, Apr 15, 2020 at 8:32 AM Yifan Cai  wrote:

> +1
>
> 
> From: Sam Tunnicliffe 
> Sent: Wednesday, April 15, 2020 7:49:50 AM
> To: dev@cassandra.apache.org 
> Subject: Re: Simplify voting rules for in-jvm-dtest-api releases
>
> +1
>
> > On 15 Apr 2020, at 14:35, Oleksandr Petrov 
> wrote:
> >
> > Hi everyone,
> >
> > Apache release rules were made for first-class projects. I would like to
> > propose simplifying voting rules for in-jvm-dtest-api project [1].
> >
> > A bit of background: in-jvm-dtest-api is a project that is used by all
> > active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> > that allows creating clusters and running tests, much like Python dtests,
> > just with a potential to run and develop them faster. Previously, anyone
> > could break API compatibility by committing to only one of the branches
> and
> > not updating the other one, which has happened on several occasions and
> has
> > went unnoticed, and has added work for people who had to bring changes to
> > more than one branch. This unified API and tests are particularly useful
> > for upgrade tests, but are also good for any kind of testing.
> >
> > Since this project was made to simplify contributions to in-jvm dtests,
> > it'd be great if making changes to this project would actually be simple.
> > Before that, in order to make changes in in-jvm-dtest API, we required
> > only +1 from a contributor and a committer could just commit the change.
> >
> > I would say that in order to cut a (minor) release of in-jvm-dtest-api
> you
> > should:
> >
> > 1. Get a +1 from a contributor who can review and test your change
> > 2. Get a +1 from one of committers who are familiar with in-jvm dtests
> (we
> > have enough, I just don't want to volunteer anyone)
> >
> > This will guard us from unnecessary changes, and add an extra pair of
> eyes
> > for things that influence moore than one branch, but leave us flexible
> > enough to be able to move forward without conducting a vote.
> >
> > Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> > for production purposes, this is a low-risk change in procedure.
> Moreover,
> > even if we package in-jvm-dtest-api with some Cassandra release, there
> will
> > be an additional vote on the release, where anyone who has concerns about
> > in-jvm-dtest-api changes can still voice them.
> >
> > Please let me know if you'd like more information about in-jvm-dtest API,
> > or have comments about this change in procedure.
> >
> > Thank you,
> > -- Alex
> > [1] https://github.com/apache/cassandra-in-jvm-dtest-api
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: server side describe

[sankalp kohli]

Whether a feature is fully done and whether it validates or invalidate
testing is not the point here. The point is that it is a feature and
violates feature freeze. If someone brings in a feature which is almost
done and does not invalidate testing then will we merge all of them to 4.0?
Lot of features can be merged then based on this justification!!


Considering this is a small feature, I wont -1 on it.  I will disagree and
commit.



On Thu, Apr 2, 2020 at 1:04 PM Jon Haddad  wrote:

> Chris's original patch used a virtual table which didn't even require a
> protocol change.  To me, the difference between having a CQL describe vs a
> virtual table is unimportant, since it's only drivers that need to care
> about it.  I'm completely fine with the simpler implementation of a virtual
> table.
>
> Quite a bit of Chris's patch also fixes our broken server side CQL
> generation, something that affects correctness in our snapshots.  So either
> way most of the code needs to go in before we release 4.0.  Adding a single
> file that creates a new virtual table is so trivial I'm having a hard time
> understanding the opposition.
>
> On Thu, Apr 2, 2020 at 12:56 PM Nate McCall  wrote:
>
> > So summarizing the salient points here:
> > - client authors have worked around this mostly, but this would avoid
> some
> > duplication of effort for new features
> > - this issues was tagged last year as being pertinent to 4.0 in several
> > threads about what was in scope
> > - there is some development efforts required to review/merge/update these
> > patches and we are trying to release
> > - the change is unintrusive
> > - this is a change to the protocol
> >
> > Not having this doesnt effect me for $dayJob, but I want to reiterate
> that
> > it's a silly thing to leave to clients. Given we've previously scoped it
> to
> > 4.0, im still +1 on adding it.
> >
> > It's ok to have differing opinions. I'd like to see us disagree and
> commit
> > to a course of action either way as opposed to just letting it sit more
> > because we can't sort it out.
> >
>

Re: server side describe

[sankalp kohli]

+1 on holding off and focus on shipping 4.0

On Wed, Apr 1, 2020 at 12:25 PM Joshua McKenzie 
wrote:

> This looks like a feature that'd potentially invalidate some testing that's
> been done and we've been feature frozen for over a year and a half. Also:
> scope creep.
>
> My PoV is we hold off. If we get into a cadence of more frequent releases
> we'll have it soon enough.
>
> On Wed, Apr 1, 2020 at 3:03 PM  wrote:
>
> > Hi,
> > Normally I ping the person on the ticket or in Slack to ask him/her for
> > status update and whether I can help. Then probably he/she gives me a
> > direction.
> > If I can’t find the person anymore, I just use my best judgement and
> > coordinate with people who might know better than me.
> > For now this strategy worked for me personally.
> > Hope this helps
> > Ekaterina
> >
> > Sent from my iPhone
> >
> > > On 1 Apr 2020, at 14:27, Jon Haddad  wrote:
> > >
> > > Hey folks,
> > >
> > > I was looking through our open JIRAs and realized we hadn't merged in
> > > server side describe calls yet.  The ticket died off a ways ago, and I
> > > pinged Chris about it yesterday.  He's got a lot of his plate and won't
> > be
> > > able to work on it anytime soon.  I still think we should include this
> in
> > > 4.0.
> > >
> > > From a technical standpoint, It doesn't say much on the ticket after
> > Robert
> > > tossed an alternative patch out there.  I don't mind reviewing and
> > merging
> > > either of them, it sounded like both are pretty close to done and I
> think
> > > from the perspective of updating drivers for 4.0 this will save quite a
> > bit
> > > of time since driver maintainers won't have to add new CQL generation
> for
> > > the various new options that have recently appeared.
> > >
> > > Questions:
> > >
> > > * Does anyone have an objection to getting this into 4.0? The patches
> > > aren't too huge, I think they're low risk, and also fairly high reward.
> > > * I don't have an opinion (yet) on Robert's patch vs Chris's, with
> regard
> > > to which is preferable.
> > > * Since soon after Robert put up his PR he hasn't been around, at least
> > as
> > > far as I've seen.  How have we dealt with abandoned patches before?  If
> > > we're going to add this in the patch will need some cleanup.  Is it
> > > reasonable to continue someone else's work when they've disappeared?
> > >
> > > Jon
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Offering some project management services

[Sankalp Kohli]

Words are open to interpretation but I do not see anyone telling anyone 
anything but proposing it in this and other thread. AFAIK, people who tell even 
accidentally don’t start a discussion thread or ask for feedback before they do 
things. 
The thread on video calls was a discussion and no one objected to it so 
community is starting it. No one told anyone that this must happen. 
This thread Josh is asking if he can help and not telling anyone he will do it. 

Ideas and suggestions can be interrupted as told but again that is interpreted 
differently but everyone. 

(We have a thread I linked so let’s move there if anyone has suggestion on 
video call To keep all context in one thread)

> On Jan 11, 2020, at 10:02 AM, Benedict Elliott Smith  
> wrote:
> 
> I've tried to make my concerns as clear as possible: there's a difference 
> between proposing and telling.
> 
> People who have de-facto power (through the resources they control) are able 
> to _tell_ other people that things are a certain way.  They may easily do it 
> accidentally.  So they must be especially careful to never to do so, or to be 
> seen to do so. 
> 
> If it's still not clear, there's no point flogging a dead horse.
> 
> 
> On 11/01/2020, 17:50, "Sankalp Kohli"  wrote:
> 
>The Agenda is public and everyone will contribute to it. Anyone can attend 
> the meeting. Anyone can propose an alternate time. How is it private ? 
> 
>What else do you suggest ? 
> 
>> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith  
>> wrote:
>> 
>> I think everyone is missing my point, and the reason for it.  I am super 
>> focused on not repeating the situation that happened before.  So I am super 
>> keen that everyone is focused on doing everything as properly as possible.  
>> Telling the community: we've privately decided this important community 
>> thing is happening on this date, and we will tell you when we have published 
>> an agenda, is the wrong way to do it.
>> 
>> Private meetings like this are fine.  Afterwards somebody can send an email 
>> to the list saying "we've talked and we think it would be nice to have a 
>> meeting on 22nd of January, and we're hoping to propose an agenda a week in 
>> advance so the community can discuss it - does that sound good to everyone?"
>> 
>> The difference is subtle, and yet not subtle.  Probably it will receive 
>> little to no interesting response and your proposal will be endorsed.  But 
>> you have to do it, because that's how the decision is made.  I'm not sure 
>> why this is controversial - you all know this is true, I'm certain of it.
>> 
>> People keep forgetting.  I'm just going to sit here and keep reminding you, 
>> so that this email thread is hopefully the worst we have to deal with.
>> 
>> 
>> 
>> On 11/01/2020, 17:07, "sankalp kohli"  wrote:
>> 
>>   Here is the mail thread where we discussed this. It also has agreement that
>>   we will discuss things on mailing list and no decision till it happens on
>>   mailing list. Hope this clears things up when you read the thread.
>> 
>>   
>> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
>> 
>>>   On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith 
>>> 
>>>   wrote:
>>> 
>>> I recall this being discussed at ApacheCon, and I recall the idea seemed
>>> very much for a semi-formal regular project meeting, in which project
>>> business would be discussed on a pre-agreed agenda.  Some ground rules were
>>> even suggested at ApacheCon, such as ensuring the meetings occur in
>>> rotating timezones, that the agenda is proposed and voted upon on-list in
>>> advance, etc.
>>> 
>>> Nothing is a decision until it happens on-list, and in this case the date,
>>> time, agenda and process should be a proposal, not something that is
>>> predetermined.
>>> 
>>> A great comparison is the CEP proposal, which was discussed at ApacheCon,
>>> brought on-list, codified, modified and voted on.
>>> 
>>> It's very easy for people who have resources at their disposal to start to
>>> behave as though they have decision-making power, because usually things
>>> happen in the way that they propose.  This happens even with the best of
>>> intentions, and I have never once implied or suspected bad intentions.
>>> 
>>> 
>>> 
>>> 
>>> On 11/01/2020, 04:24, "Jeff Jirsa"  wrote:
>>> 
>>>   This will be rambling as I’m t

Re: Offering some project management services

[Sankalp Kohli]

The Agenda is public and everyone will contribute to it. Anyone can attend the 
meeting. Anyone can propose an alternate time. How is it private ? 

What else do you suggest ? 

> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith  
> wrote:
> 
> I think everyone is missing my point, and the reason for it.  I am super 
> focused on not repeating the situation that happened before.  So I am super 
> keen that everyone is focused on doing everything as properly as possible.  
> Telling the community: we've privately decided this important community thing 
> is happening on this date, and we will tell you when we have published an 
> agenda, is the wrong way to do it.
> 
> Private meetings like this are fine.  Afterwards somebody can send an email 
> to the list saying "we've talked and we think it would be nice to have a 
> meeting on 22nd of January, and we're hoping to propose an agenda a week in 
> advance so the community can discuss it - does that sound good to everyone?"
> 
> The difference is subtle, and yet not subtle.  Probably it will receive 
> little to no interesting response and your proposal will be endorsed.  But 
> you have to do it, because that's how the decision is made.  I'm not sure why 
> this is controversial - you all know this is true, I'm certain of it.
> 
> People keep forgetting.  I'm just going to sit here and keep reminding you, 
> so that this email thread is hopefully the worst we have to deal with.
> 
> 
> 
> On 11/01/2020, 17:07, "sankalp kohli"  wrote:
> 
>Here is the mail thread where we discussed this. It also has agreement that
>we will discuss things on mailing list and no decision till it happens on
>mailing list. Hope this clears things up when you read the thread.
> 
>
> https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
> 
>>On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith 
>> 
>>wrote:
>> 
>> I recall this being discussed at ApacheCon, and I recall the idea seemed
>> very much for a semi-formal regular project meeting, in which project
>> business would be discussed on a pre-agreed agenda.  Some ground rules were
>> even suggested at ApacheCon, such as ensuring the meetings occur in
>> rotating timezones, that the agenda is proposed and voted upon on-list in
>> advance, etc.
>> 
>> Nothing is a decision until it happens on-list, and in this case the date,
>> time, agenda and process should be a proposal, not something that is
>> predetermined.
>> 
>> A great comparison is the CEP proposal, which was discussed at ApacheCon,
>> brought on-list, codified, modified and voted on.
>> 
>> It's very easy for people who have resources at their disposal to start to
>> behave as though they have decision-making power, because usually things
>> happen in the way that they propose.  This happens even with the best of
>> intentions, and I have never once implied or suspected bad intentions.
>> 
>> 
>> 
>> 
>> On 11/01/2020, 04:24, "Jeff Jirsa"  wrote:
>> 
>>This will be rambling as I’m typing on my phone while watching The
>> Office and I’m not going to proofread, but:
>> 
>>PMC votes on releases, and code policies, and trademarks, and things
>> of that nature. While the link suggests PMCs *can* sponsor meetings,
>> nothing should preclude anyone from meeting to talk about the database -
>> there are countless cassandra meetups around and we never try to police
>> those (and we shouldn’t start), as long as they’re not pretending to be
>> speaking on behalf of the project.
>> 
>>A couple non-committer contributors deciding to hop on a video call
>> and encourage other contributors to attend seems both harmless to the
>> project and something that can help build awareness and bring attention to
>> some of the otherwise invisible work that’s happening.
>> 
>>It’s not on behalf of the project PMC, this thread has made that
>> clear, but I think there’s value here, even if anything discussed or
>> proposed on any hypothetical call has no standing and wouldn’t represent
>> the PMC or the project. Having folks who care about the database talk about
>> the community, even if they’re not committers, doesn’t seem all that
>> damaging to me, as long as they’re not violating trademark to promote it or
>> somehow misrepresenting the nature of the call.
>> 
>>I get the concern about implicit control of the project and how that
>> can devolve over time despite good intentions.
>> 
>>As with the long threads 

Re: Offering some project management services

[sankalp kohli]

Here is the mail thread where we discussed this. It also has agreement that
we will discuss things on mailing list and no decision till it happens on
mailing list. Hope this clears things up when you read the thread.

https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E

On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith 
wrote:

> I recall this being discussed at ApacheCon, and I recall the idea seemed
> very much for a semi-formal regular project meeting, in which project
> business would be discussed on a pre-agreed agenda.  Some ground rules were
> even suggested at ApacheCon, such as ensuring the meetings occur in
> rotating timezones, that the agenda is proposed and voted upon on-list in
> advance, etc.
>
> Nothing is a decision until it happens on-list, and in this case the date,
> time, agenda and process should be a proposal, not something that is
> predetermined.
>
> A great comparison is the CEP proposal, which was discussed at ApacheCon,
> brought on-list, codified, modified and voted on.
>
> It's very easy for people who have resources at their disposal to start to
> behave as though they have decision-making power, because usually things
> happen in the way that they propose.  This happens even with the best of
> intentions, and I have never once implied or suspected bad intentions.
>
>
>
>
> On 11/01/2020, 04:24, "Jeff Jirsa"  wrote:
>
> This will be rambling as I’m typing on my phone while watching The
> Office and I’m not going to proofread, but:
>
> PMC votes on releases, and code policies, and trademarks, and things
> of that nature. While the link suggests PMCs *can* sponsor meetings,
> nothing should preclude anyone from meeting to talk about the database -
> there are countless cassandra meetups around and we never try to police
> those (and we shouldn’t start), as long as they’re not pretending to be
> speaking on behalf of the project.
>
> A couple non-committer contributors deciding to hop on a video call
> and encourage other contributors to attend seems both harmless to the
> project and something that can help build awareness and bring attention to
> some of the otherwise invisible work that’s happening.
>
> It’s not on behalf of the project PMC, this thread has made that
> clear, but I think there’s value here, even if anything discussed or
> proposed on any hypothetical call has no standing and wouldn’t represent
> the PMC or the project. Having folks who care about the database talk about
> the community, even if they’re not committers, doesn’t seem all that
> damaging to me, as long as they’re not violating trademark to promote it or
> somehow misrepresenting the nature of the call.
>
> I get the concern about implicit control of the project and how that
> can devolve over time despite good intentions.
>
> As with the long threads in 2015/2016, I think we should be sure not
> to overreact out of fear, and should assume good intent.
>
> Given the concern, I also think folks trying to build community should
> make a point of over communicating to the dev list.
>
> Hugs and kisses friends,
> - Jeff
>
>
>
> > On Jan 10, 2020, at 6:05 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >
> > To be clear, as it seems like I'm being very negative here, I'm
> really pleased to see DataStax suddenly increase their participation, even
> if currently it's limited to administrative activities.  But let's try
> really hard to do things in the right way.
> >
> > https://www.apache.org/foundation/governance/pmcs.html#meetings
> >
> > Community and meetings are explicitly within the intended purview of
> the PMC.  The Cassandra PMC ordinarily implicitly devolves decision-making
> to the dev list, so a lack of formal role is no impediment to participation
> _here on the devlist_ but making decisions off-list amongst a cohort
> lacking _any_ formal members of the community is a particularly bad look
> IMO, and the kind of indifference to "The Apache Way" that lead to the
> fallout with DataStax many moons ago.
> >
> > In this case, Patrick said "we've decided we're running a
> contributor meeting on this date" which starts to look like an attempt -
> however unintentional - to make decisions about community and collaboration
> _for_ the project.
> >
> > Instead, IMO, presenting a clear proposal to the community about how
> this could happen, giving it due time to respond and consider (and probably
> mostly express gratitude!) is the right way to do it.  It might lead to
> tweaks, it might lead to minor preconditions about process, it might lead
> to nothing.  But that's how these kinds of things should happen, even
> ignoring the ASF stuff, if only out of politeness.
> >
> >
> > On 11/01/2020, 01:52, "J. D. Jordan" 
> wrote:
> >
> >  Isn’t doing such things the way people who are not writing code
> become 

Re: Offering some project management services

[Sankalp Kohli]

We discussed about the video call on the dev list and everyone agreed to it. 

I also welcome Josh in helping with the project. Like Josh and Dinesh 
mentioned, let’s encourage contributions by allowing non-committers to do first 
round of review as I don’t see a downside of doing this. These video calls and 
email updates can help motivate others to help with reviews and write patches. 
I feel it is worth a try!!

> On Jan 10, 2020, at 8:23 PM, Jeff Jirsa  wrote:
> 
> This will be rambling as I’m typing on my phone while watching The Office 
> and I’m not going to proofread, but:
> 
> PMC votes on releases, and code policies, and trademarks, and things of that 
> nature. While the link suggests PMCs *can* sponsor meetings, nothing should 
> preclude anyone from meeting to talk about the database - there are countless 
> cassandra meetups around and we never try to police those (and we shouldn’t 
> start), as long as they’re not pretending to be speaking on behalf of the 
> project. 
> 
> A couple non-committer contributors deciding to hop on a video call and 
> encourage other contributors to attend seems both harmless to the project and 
> something that can help build awareness and bring attention to some of the 
> otherwise invisible work that’s happening. 
> 
> It’s not on behalf of the project PMC, this thread has made that clear, but I 
> think there’s value here, even if anything discussed or proposed on any 
> hypothetical call has no standing and wouldn’t represent the PMC or the 
> project. Having folks who care about the database talk about the community, 
> even if they’re not committers, doesn’t seem all that damaging to me, as long 
> as they’re not violating trademark to promote it or somehow misrepresenting 
> the nature of the call.
> 
> I get the concern about implicit control of the project and how that can 
> devolve over time despite good intentions.
> 
> As with the long threads in 2015/2016, I think we should be sure not to 
> overreact out of fear, and should assume good intent. 
> 
> Given the concern, I also think folks trying to build community should make a 
> point of over communicating to the dev list.
> 
> Hugs and kisses friends,
> - Jeff
> 
> 
> 
>> On Jan 10, 2020, at 6:05 PM, Benedict Elliott Smith  
>> wrote:
>> 
>> To be clear, as it seems like I'm being very negative here, I'm really 
>> pleased to see DataStax suddenly increase their participation, even if 
>> currently it's limited to administrative activities.  But let's try really 
>> hard to do things in the right way.
>> 
>> https://www.apache.org/foundation/governance/pmcs.html#meetings
>> 
>> Community and meetings are explicitly within the intended purview of the 
>> PMC.  The Cassandra PMC ordinarily implicitly devolves decision-making to 
>> the dev list, so a lack of formal role is no impediment to participation 
>> _here on the devlist_ but making decisions off-list amongst a cohort lacking 
>> _any_ formal members of the community is a particularly bad look IMO, and 
>> the kind of indifference to "The Apache Way" that lead to the fallout with 
>> DataStax many moons ago.
>> 
>> In this case, Patrick said "we've decided we're running a contributor 
>> meeting on this date" which starts to look like an attempt - however 
>> unintentional - to make decisions about community and collaboration _for_ 
>> the project.
>> 
>> Instead, IMO, presenting a clear proposal to the community about how this 
>> could happen, giving it due time to respond and consider (and probably 
>> mostly express gratitude!) is the right way to do it.  It might lead to 
>> tweaks, it might lead to minor preconditions about process, it might lead to 
>> nothing.  But that's how these kinds of things should happen, even ignoring 
>> the ASF stuff, if only out of politeness. 
>> 
>> 
>> On 11/01/2020, 01:52, "J. D. Jordan"  wrote:
>> 
>> Isn’t doing such things the way people who are not writing code become part 
>> of a project?  By offering their time to do things that benefit the project?
>> 
>> Why does anyone “with a formal role” need to agree that Patrick is allowed 
>> to use his time to try and get some people together to discuss contributing?
>> 
>> -Jeremiah Jordan
>> Person with no formal role in the Apache Cassandra project.
>> 
>> On Jan 10, 2020, at 7:44 PM, Benedict Elliott Smith 
>>  wrote:
>>> This is also great.  But it's a bit of a weird look to have two people, 
>>> neither of whom have formal roles on the project, making decisions like 
>>> this without the involvement of the community.  I'm sure everyone will be 
>>> supportive, but it would help to democratise the decision-making.
>>> On 11/01/2020, 01:39, "Patrick McFadin"  wrote:
>>> Scott and I had a talk this week and we are starting the contributor
>>> meetings on 1/22 as we talked about at NGCC. (Yeah that was back in
>>> September) Stay tuned for the details and agenda in the project confluence
>>> page.
>>> Patrick
> On Fri, Jan 10, 2020 

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

[sankalp kohli]

+1

On Fri, Nov 1, 2019 at 11:56 AM Scott Andreas  wrote:

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

Re: [VOTE-2] Apache Cassandra Release Lifecycle

[sankalp kohli]

Vote passes with 11 +1 and no -1

On Thu, Oct 10, 2019 at 2:41 PM Jordan West  wrote:

> +1 nb
>
> On Wed, Oct 9, 2019 at 11:00 PM Per Otterström
>  wrote:
>
> > +1 nb
> >
> > -Original Message-
> > From: Mick Semb Wever 
> > Sent: den 10 oktober 2019 07:08
> > To: dev@cassandra.apache.org
> > Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
> >
> >
> > > We have discussed in the email thread[1] about Apache Cassandra
> > > Release Lifecycle. We came up with a doc[2] for it. We have finalized
> > > the doc here[3] Please vote on it if you agree with the content of the
> > doc [3].
> >
> >
> > +1 nb
> >
> > the doc is good. it adds value for users, and does not need to be
> perfect.
> > thanks Sumanth for doing this.
> >
> >
> > -
> > 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-2] Apache Cassandra Release Lifecycle

[Sankalp Kohli]

Can we please stick to the vote here. We can always change the documentation as 
it will evolve over time. 


> On Oct 8, 2019, at 2:57 PM, Joshua McKenzie  wrote:
> 
> It probably warrants a separate discussion about how we version.
> 
> Also, robust +1 to what you said here bes and haddad  ;)
> 
>> On Tue, Oct 8, 2019 at 5:31 PM Jon Haddad  wrote:
>> 
>> This has definitely been a confusing topic in the past, I completely agree
>> Benedict.  Glad you brought this up.
>> 
>> I'm 100% on board with 5.0 after 4.0.
>> 
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith >> 
>> wrote:
>> 
>>> As a brief side-step on the topic only of versioning (which no doubt will
>>> cause enough consternation), I personally endorse streamlining it.  We
>> have
>>> not had a consistently meaningful convention on this, at any point, and
>> we
>>> made it even worse in the 3.x line.  There's no real difference between
>>> 1.2->2.0, 2.0->2.1, or 3.0->3.11 and 3.11->4.0; let's admit this and go
>>> straight to 5.0 for our next feature release, with 4.1 our first patch
>>> release of the 4.x line.
>>> 
>>> 
>>>> On 08/10/2019, 21:36, "Scott Andreas"  wrote:
>>> 
>>>Re: "How can we decide that *all* new features are suppose to go into
>>> trunk only, if we don’t even have an idea about the upcoming release
>>> schedule?"
>>> 
>>>This is a great question. My understanding of the intent of the
>>> document is that new features are generally expected to land in trunk,
>> with
>>> an exception process defined for feature backports. I think that's a
>>> reasonable expectation to start with. But I also agree with you that it's
>>> important we evolve a way to discuss and agree up on release scope - this
>>> was the focus of my slides at NGCC. I would love to discuss this on a
>>> separate thread.
>>> 
>>>Re: “Bug fix releases have associated new minor version.”
>>>"Patchlevel version" might be more in keeping with our current
>>> convention.
>>> 
>>>Re: "We should give users a way to plan, by having EOL dates"
>>>Incorporating EOL dates into our release management / planning is a
>>> great idea.
>>> 
>>>Would you be willing to rephrase your comments in the form of
>> proposed
>>> edits to the document?
>>> 
>>>– Scott
>>> 
>>>
>>>From: Stefan Podkowinski 
>>>Sent: Tuesday, October 8, 2019 1:22 PM
>>>To: dev@cassandra.apache.org
>>>Subject: Re: [VOTE-2] Apache Cassandra Release Lifecycle
>>> 
>>> From the document:
>>> 
>>>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.”
>>>Maintenance: “Missing features from newer generation releases are
>>>back-ported on per - PMC vote basis.”
>>> 
>>>We had a feature freeze before 4.0, which showed that people have
>>>different views on what actually qualifies as a feature. It doesn’t
>>> work
>>>without defining “feature” in more detail. Although I’d rather avoid
>> to
>>>have this in the document at all, since I don’t think this is getting
>>> us
>>>anywhere, without having a clearer picture on the bigger context in
>>>which release are going to happen in the future, starting with
>> release
>>>cadence and support periods. How can we decide that *all* new
>> features
>>>are suppose to go into trunk only, if we don’t even have an idea
>> about
>>>the upcoming release schedule?
>>> 
>>>“Bug fix releases have associated new minor version.”
>>> 
>>>So the next bug fix version will be 4.1? There will be no minor
>> feature
>>>releases like we did with 3.x.0/2.x.0?
>>> 
>>>Deprecated:
>>>"Through a dev community voting process, EOL date is determined for
>>> this
>>>release.”
>>>    “Users actively encouraged to move away from the offering.”
>>> 
>>>We should give users a way to plan, by having EOL dates that may be
>>>months or years ahead in the fu

[VOTE-2] Apache Cassandra Release Lifecycle

[sankalp kohli]

Hi,
We have discussed in the email thread[1] about Apache Cassandra Release
Lifecycle. We came up with a doc[2] for it. We have finalized the doc
here[3] Please vote on it if you agree with the content of the doc [3].

We did not proceed with the previous vote as we want to use confluence for
it. Here is the link for that[4]. It also mentions why we are doing this
vote.

Vote will remain open for 72 hours.

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
[3]https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
Attachments area
[4]
https://lists.apache.org/thread.html/169b00f45dbad295e1aea1da70365fabc8452ef497f78ddfd28c311f@%3Cdev.cassandra.apache.org%3E

Re: [VOTE] Apache Cassandra Release Lifecycle

[sankalp kohli]

Thanks Sumanth. Let me start another vote

On Tue, Oct 8, 2019 at 7:26 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> 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 <https://issues.apache.org/jira/browse/CASSANDRA-15249>
> as
> well as the GDoc
> <
> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit#
> >
> .
>
> 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

[sankalp kohli]

Sure..lets do that.

On Mon, Sep 30, 2019 at 3:21 PM Benedict Elliott Smith 
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
>
>

Re: [VOTE] Apache Cassandra Release Lifecycle

[sankalp kohli]

Vote will be open for 72 hours.

On Mon, Sep 30, 2019 at 12:09 PM 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
> > >
> >
>

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

[sankalp kohli]

t;
> https://community.apache.org/committers/lazyConsensus.html
> > >.
> >
> > Methinks if we got a little more comfortable w/lazy consensus and
> > majority
> > voting on process <https://www.apache.org/foundation/voting.html> we
> > might
> > see some quicker evolution on the project.
> >
> > Not to hijack the thread; just figured I'd point it out since it was
> > on my
> > mind and it may not be common knowledge.
> >
> > On Fri, Sep 27, 2019 at 12:20 PM Sankalp Kohli <
> kohlisank...@gmail.com
> > >
> >     wrote:
> >
> > > Let’s put this to vote next week unless someone thinks it is not
> > required
> > >
> > > > On Sep 25, 2019, at 10:56 AM, sankalp kohli <
> > kohlisank...@gmail.com>
> > > wrote:
> > > >
> > > > 
> > > > Can we put it on vote(if required) if no one has more comments?
> > > >
> > > >> On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer <
> > > j...@koppedomain.com> wrote:
> > > >> Nice work... I like this and have no additions/comments at this
> > time
> > > >>
> > > >> On Wed, Sep 18, 2019, 4:18 PM sankalp kohli <
> > kohlisank...@gmail.com>
> > > wrote:
> > > >>
> > > >> > We added and changed a lot of things to this doc during a
> > discussion
> > > in
> > > >> > NGCC. Can everyone take a look at it and provide feedback.
> > > >> >
> > > >> > On Wed, Sep 11, 2019 at 10:51 PM Dinesh Joshi <
> > djo...@apache.org>
> > > wrote:
> > > >> >
> > > >> > > I have left some comments on the document. Apart from a few
> > > >> > clarifications
> > > >> > > and some minor changes, I feel its in a good shape. I think
> we
> > > should
> > > >> > move
> > > >> > > forward with it. We can refine the process, definitions &
> > criteria
> > > as we
> > > >> > > learn.
> > > >> > >
> > > >> > > Dinesh
> > > >> > >
> > > >> > > > On Sep 11, 2019, at 11:15 AM, Sumanth Pasupuleti <
> > > >> > > sumanth.pasupuleti...@gmail.com> wrote:
> > > >> > > >
> > > >> > > > 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.
> > > >> > > >>>
>

[VOTE] Apache Cassandra Release Lifecycle

[sankalp kohli]

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: TBD" -> "4.0: Est. Q4 2019"?

[Sankalp Kohli]

Let’s put this to vote next week unless someone thinks it is not required 

> On Sep 25, 2019, at 10:56 AM, sankalp kohli  wrote:
> 
> 
> Can we put it on vote(if required) if no one has more comments? 
> 
>> On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer  
>> wrote:
>> Nice work... I like this and have no additions/comments at this time
>> 
>> On Wed, Sep 18, 2019, 4:18 PM sankalp kohli  wrote:
>> 
>> > We added and changed a lot of things to this doc during a discussion in
>> > NGCC. Can everyone take a look at it and provide feedback.
>> >
>> > On Wed, Sep 11, 2019 at 10:51 PM Dinesh Joshi  wrote:
>> >
>> > > I have left some comments on the document. Apart from a few
>> > clarifications
>> > > and some minor changes, I feel its in a good shape. I think we should
>> > move
>> > > forward with it. We can refine the process, definitions & criteria as we
>> > > learn.
>> > >
>> > > Dinesh
>> > >
>> > > > On Sep 11, 2019, at 11:15 AM, Sumanth Pasupuleti <
>> > > sumanth.pasupuleti...@gmail.com> wrote:
>> > > >
>> > > > 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 <
>> > sc...@paradoxica.net>
>> > > >>>> 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 offici

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

[sankalp kohli]

Can we put it on vote(if required) if no one has more comments?

On Wed, Sep 18, 2019 at 5:44 PM Jonathan Koppenhofer 
wrote:

> Nice work... I like this and have no additions/comments at this time
>
> On Wed, Sep 18, 2019, 4:18 PM sankalp kohli 
> wrote:
>
> > We added and changed a lot of things to this doc during a discussion in
> > NGCC. Can everyone take a look at it and provide feedback.
> >
> > On Wed, Sep 11, 2019 at 10:51 PM Dinesh Joshi  wrote:
> >
> > > I have left some comments on the document. Apart from a few
> > clarifications
> > > and some minor changes, I feel its in a good shape. I think we should
> > move
> > > forward with it. We can refine the process, definitions & criteria as
> we
> > > learn.
> > >
> > > Dinesh
> > >
> > > > On Sep 11, 2019, at 11:15 AM, Sumanth Pasupuleti <
> > > sumanth.pasupuleti...@gmail.com> wrote:
> > > >
> > > > 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 <
> > sc...@paradoxica.net>
> > > >>>> 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
> > > >>

Re: Cassandra GUI that supports cqlsh through Bastion

[sankalp kohli]

Please email to user list as I do not think this question is for dev list.

On Wed, Sep 18, 2019 at 10:17 AM Bhavesh Prajapati
 wrote:

> Hi,
>
> I am looking for Cassandra GUI that supports cqlsh connection to Cassandra
> node through bastion/jump host using ssh key.
>
> Thanks,
> Bhavesh
>

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

[sankalp kohli]

king 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 <
> >>>>> 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: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

[sankalp kohli]

Another thing which it should solve is someone proposing an alternate very
late into development which could be provided sooner. If someone has a good
feedback which could not have been given at the time of CEP then that is
good. We don't want situations where contributors have done the CEP and
then worked on implementation of it and then someone who has not read the
CEP comes in and starts giving feedback. This feedback should come at the
time of CEP if CEP has covered that area.
To be clear, I am not saying people should not give feedback later just
that they dont ignore the whole thing and wake up later in the process.
This causes huge productivity and morale loss to code contributors who are
in minority right now in the community.

On Tue, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith 
wrote:

> Can we modify the document to make this really explicit then?  Right now,
> the language suggests the process is mandated, rather than encouraged and
> beneficial.
>
> It would be nice to frame it as a positive and incentivised undertaking by
> authors, and to list the intended advantages, as well as the potential
> disadvantages of not undertaking it, while making it clear it is left
> entirely to their own judgement whether or not to do so.
>
> To be really clear, I do not refer to the flexible definition of the
> process, but to whether participation in even a modest interpretation of
> the process is necessary at all.  This is a form of pre-registration for
> work, to achieve community buy-in.  If you want to go ahead and do
> something on your own, you only risk difficulty and delays when obtaining
> community buy-in after the fact.  Let's not dissuade hobbyists, part-timers
> or scratching an itch by suggesting their work will be discounted because
> it wasn't pre-registered.
>
>
> On 17/09/2019, 06:46, "Mick Semb Wever"  wrote:
>
>
>
> > I think we need to have a meta discussion about the goal for
> > introducing a new process.
>
>
> Indeed, and these were only two brief examples that came to me.
> Another, using the sidecar proposal as an example, is simply to ensure a
> little patience is taken during the initial brainstorming and navigation
> phase, to give more open collaboration a better chance. What's in the
> landscape, where's the value, who might be interested in getting involved
> in this, etc etc. I think the C* community has typically been pretty
> amazing at this, but it would be nice to see it formalised a bit better.
>
>
> > By not mandating it, we do not need to define where it is necessary;
> > the larger and more impactful the change, the greater the incentive
> to
> > the author.
>
>
> This is what Scott highlighted well.
> Sure, a CEP could be opened with nothing but a title to begin with.
> And where it goes from there is up to the working group that materialises.
> Just to have a landing space for new features that's not Jira, I believe
> would be of value.
>
> And in no way should the CEP be a return to waterfall. As you say,
> late discoveries and feedback (as annoying as it can be) is all part of the
> agile game.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

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

[Sankalp Kohli]

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. 

If people have already started using the alpha artifacts, then I suggest we 
make test passing a blocker for next alpha 

> On Sep 6, 2019, at 5:44 AM, Michael Shuler  wrote:
> 
> Thanks a bunch for the test runs. Most of those upgrade tests show 
> "RuntimeError: You need to set JAVA8_HOME," so it does look like a systemic, 
> generic issue to resolve there somewhere in dtest. Thanks again!
> 
> Michael
> 
>> On 9/5/19 8:08 PM, Joseph Lynch wrote:
>> Following passed 100%: utest_compression, utests_stress, utests_long,
>> utests_fqltool, j8_dtests-no-vnodes
>> j8_unit_tests: 1 failure
>> - testAcquireReleaseOutbound - org.apache.cassandra.net.ConnectionTest
>> j11_unit_tests: 1 failure
>> - testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest
>> j8_dtests-with-vnodes + j11_dtests-with-vnodes: 1 failure
>> - test_remote_query - cql_test.TestCQLSlowQuery
>> j11_dtests-no-vnodes: 1 failure
>> - test_13595 - consistency_test.TestConsistency
>> j8_upgradetests-no-vnodes: 3923 failures
>> Other than the upgradetests (which afaik nobody has looked at for
>> 4.0), this looks somewhat reasonable to me. I'm launching a multi-dc
>> cluster to do some light load testing.
>> -Joey
>>> On Thu, Sep 5, 2019 at 4:03 PM Joseph Lynch  wrote:
>>> 
>>> Running all tests at 
>>> https://circleci.com/workflow-run/79918e2a-ea8e-48a6-a38d-96cf85de27ff
>>> 
>>> Will report back with results shortly,
>>> -Joey
>>> 
>>> On Thu, Sep 5, 2019 at 3:55 PM Jon Haddad  wrote:
 
 +1
 
 On Thu, Sep 5, 2019 at 3:44 PM Michael Shuler 
 wrote:
 
> I propose the following artifacts for release as 4.0-alpha1.
> 
> sha1: fc4381ca89ab39a82c9018e5171975285cc3bfe7
> Git:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha1-tentative
> Artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecassandra-1177/org/apache/cassandra/apache-cassandra/4.0-alpha1/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1177/
> 
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
> 
> The vote will be open for 24 hours (longer if needed).
> 
> [1]: CHANGES.txt:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-tentative
> [2]: NEWS.txt:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-alpha1-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
> 

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

Re: 4.0 alpha before apachecon?

[Sankalp Kohli]

I do not think we should branch and is -1 on it. The reason we have trunk 
frozen was for our focus to be on 4.0. I think we still need that focus till a 
few more releases like these. 

> On Aug 30, 2019, at 12:24 AM, Nate McCall  wrote:
> 
> On Fri, Aug 30, 2019 at 10:11 AM Benedict Elliott Smith 
> wrote:
> 
>> 
>>Seems to make sense to branch, right?
>> 
>> Feels like a good line in the sand. +1

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

Re: 4.0 alpha before apachecon?

[sankalp kohli]

Will we cut alpha1 and later alpha releases from trunk or create a new
branch?
On Friday, August 30, 2019, Nate McCall  wrote:

> >
> >
> > I think the next decision is should we just cut 4.0-alpha1 now given
> > that Michael has some cycles regardless of the known issues and start
> > using the new fix versions for the 4.0-alpha2 release? I personally
> > feel we should cut 4.0-alpha1 with every imaginable "expect this
> > release to break" disclaimer and start working towards 4.0-alpha2.
> >
>
> Let's just pull the trigger on it. We know there are a couple of rough
> edges, but that is the point of an alpha.
>

Re: Contributing cassandra-diff

[Sankalp Kohli]

A different repo will be better 

> On Aug 22, 2019, at 6:16 AM, Per Otterström  
> wrote:
> 
> Very powerful tool indeed, thanks for sharing!
> 
> I believe it is best to keep tools like this in different repos since 
> different tools will probably have different life cycles and tool chains. 
> Yes, that could be handled in a single repo, but with different repos we'd 
> get natural boundaries.
> 
> -Original Message-
> From: Sumanth Pasupuleti  
> Sent: den 22 augusti 2019 14:40
> To: dev@cassandra.apache.org
> Subject: Re: Contributing cassandra-diff
> 
> 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://protect2.fireeye.com/url?k=e8982d07-b412e678-e8986d9c-86717
 581b0b5-292bc820a13b7138=1=https%3A%2F%2Fgithub.com%2Fkrummas%2
 Fcassandra-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
>> 
>> 
> B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[Ø\ÜØ[™˜K˜\XÚK›Ü™ÃBƒB

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

Re: Apache Cassandra Virtual meetings

[sankalp kohli]

Thank you all for the feedback. It has been a week since last last feedback
so we will move forward with these meeting. We plan to start them post
NGCC. If anyone feedback is not addressed, please let me know.

Also feedback on this will always be welcomed even when meetings are
ongoing as I am assuming shape of this meeting will keeping changing over
time based on feedback.

On Mon, Aug 12, 2019 at 4:33 PM sankalp kohli 
wrote:

> Thanks Patrick for helping with logistics. We can certainly use your
> resources unless someone objects
>
> On Mon, Aug 12, 2019 at 10:42 AM Patrick McFadin 
> wrote:
>
>> If it works for everyone, DataStax has some resources we could put to this
>> effort. We do large scale conferences like this all the time and have the
>> tools to pull it off. It would be a small group of people with full duplex
>> audio and video with the ability for 100s of people to watch in streaming.
>> As Scott mentioned, a recording could be made available after the fact for
>> anyone that wanted to review and historical purposes.
>>
>> If we go this route, I would suggest using the ASF Cassandra slack for
>> people posting questions. 1) It gets more people on slack 2) It's more or
>> less a permanent, searchable record.
>>
>> Patrick
>>
>> On Sun, Aug 11, 2019 at 10:18 AM Rahul Xavier Singh <
>> rahul.xavier.si...@gmail.com> wrote:
>>
>> > I think these meetings would be great.. if there is a specific
>> structure.
>> > We use a simple format that could help e.g.
>> >
>> > 1. Review long term vision/ roadmap.
>> > 2. Review next release / features that are in progress.
>> > 3. Discuss issues in general and make a game plan for the next quarter.
>> >
>> > Nothing too complicated, but at least some structure so that we are
>> > timeboxed on what we are doing.
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 7:42 AM Joshua McKenzie 
>> > wrote:
>> >
>> > > The one thing we need to keep in mind is the "If it didn't happen on a
>> > > mailing list, it didn't happen <http://theapacheway.com/on-list/>"
>> > > philosophy of apache projects. Shouldn't constrain us too much as the
>> > > nuance is:
>> > >
>> > > *"Discussions and plan proposals often happen at events, in chats
>> (Slack,
>> > > IRC, IM, etc.) or other synchronous places. But all final decisions
>> about
>> > > executing on the plan, checking in the new code, or launching the
>> website
>> > > must be made by the community asyncrhonously on the mailing list."*
>> > >
>> > > So long as we keep that in mind (and maybe push it back to 8am PST
>> since
>> > > 9am can get pretty ugly for some of the more eastern european / asian
>> > > countries), makes sense to me.
>> > >
>> > > On Tue, Aug 6, 2019 at 6:07 PM Dinesh Joshi 
>> wrote:
>> > >
>> > > > Thanks for initiating this conversation Sankalp. On the ASF front, I
>> > > think
>> > > > we need to ensure that non-Pacific time participants can also
>> > participate
>> > > > in the discussions. So posting the notes and opening up discussions
>> > after
>> > > > the meet up to dev@ would be a great way of making sure everyone
>> can
>> > > > participate and gets visibility. Additionally, we should consider
>> > > > scheduling this meetup in different timezones as far as logistics
>> allow
>> > > it.
>> > > >
>> > > > Dinesh
>> > > >
>> > > > > On Aug 6, 2019, at 2:58 PM, sankalp kohli > >
>> > > > wrote:
>> > > > >
>> > > > > Hi All,
>> > > > > There are projects (like k8s[1]) which do regular meetings
>> > > using
>> > > > > video conferencing tools. We want to propose such a meeting for
>> > Apache
>> > > > > Cassandra once a quarter. Here are some of the initial details.
>> > > > >
>> > > > > 1. A two hour meeting once a quarter starting at 9am Pacific. We
>> can
>> > > > later
>> > > > > move this to other times to make it easier for other timezones.
>> > > > > 2. Agenda of the meeting will be due 2 days prior to the meeting.
>> A
>> > > > sample
>> > > > > agenda for next one could cover updates on 4.0 testing, any major
>>

Re: Apache Cassandra Virtual meetings

[sankalp kohli]

Thanks Patrick for helping with logistics. We can certainly use your
resources unless someone objects

On Mon, Aug 12, 2019 at 10:42 AM Patrick McFadin  wrote:

> If it works for everyone, DataStax has some resources we could put to this
> effort. We do large scale conferences like this all the time and have the
> tools to pull it off. It would be a small group of people with full duplex
> audio and video with the ability for 100s of people to watch in streaming.
> As Scott mentioned, a recording could be made available after the fact for
> anyone that wanted to review and historical purposes.
>
> If we go this route, I would suggest using the ASF Cassandra slack for
> people posting questions. 1) It gets more people on slack 2) It's more or
> less a permanent, searchable record.
>
> Patrick
>
> On Sun, Aug 11, 2019 at 10:18 AM Rahul Xavier Singh <
> rahul.xavier.si...@gmail.com> wrote:
>
> > I think these meetings would be great.. if there is a specific structure.
> > We use a simple format that could help e.g.
> >
> > 1. Review long term vision/ roadmap.
> > 2. Review next release / features that are in progress.
> > 3. Discuss issues in general and make a game plan for the next quarter.
> >
> > Nothing too complicated, but at least some structure so that we are
> > timeboxed on what we are doing.
> >
> >
> >
> > On Wed, Aug 7, 2019 at 7:42 AM Joshua McKenzie 
> > wrote:
> >
> > > The one thing we need to keep in mind is the "If it didn't happen on a
> > > mailing list, it didn't happen <http://theapacheway.com/on-list/>"
> > > philosophy of apache projects. Shouldn't constrain us too much as the
> > > nuance is:
> > >
> > > *"Discussions and plan proposals often happen at events, in chats
> (Slack,
> > > IRC, IM, etc.) or other synchronous places. But all final decisions
> about
> > > executing on the plan, checking in the new code, or launching the
> website
> > > must be made by the community asyncrhonously on the mailing list."*
> > >
> > > So long as we keep that in mind (and maybe push it back to 8am PST
> since
> > > 9am can get pretty ugly for some of the more eastern european / asian
> > > countries), makes sense to me.
> > >
> > > On Tue, Aug 6, 2019 at 6:07 PM Dinesh Joshi  wrote:
> > >
> > > > Thanks for initiating this conversation Sankalp. On the ASF front, I
> > > think
> > > > we need to ensure that non-Pacific time participants can also
> > participate
> > > > in the discussions. So posting the notes and opening up discussions
> > after
> > > > the meet up to dev@ would be a great way of making sure everyone can
> > > > participate and gets visibility. Additionally, we should consider
> > > > scheduling this meetup in different timezones as far as logistics
> allow
> > > it.
> > > >
> > > > Dinesh
> > > >
> > > > > On Aug 6, 2019, at 2:58 PM, sankalp kohli 
> > > > wrote:
> > > > >
> > > > > Hi All,
> > > > > There are projects (like k8s[1]) which do regular meetings
> > > using
> > > > > video conferencing tools. We want to propose such a meeting for
> > Apache
> > > > > Cassandra once a quarter. Here are some of the initial details.
> > > > >
> > > > > 1. A two hour meeting once a quarter starting at 9am Pacific. We
> can
> > > > later
> > > > > move this to other times to make it easier for other timezones.
> > > > > 2. Agenda of the meeting will be due 2 days prior to the meeting. A
> > > > sample
> > > > > agenda for next one could cover updates on 4.0 testing, any major
> > bugs
> > > > > found and/or fixed, next steps for 4.0, etc.
> > > > > 3. Each agenda item will have a time duration and list of people to
> > > drive
> > > > > that item.
> > > > > 4. We will have a moderator for each meeting which will rotate
> around
> > > the
> > > > > community members.
> > > > > 5. We need to figure out which video conferencing tool to use for
> > this.
> > > > > Suggestions and donation of tools are welcome.
> > > > > 6. We will have meeting notes for each item discussed in the
> meeting.
> > > > >
> > > > > Motivation for such a meeting
> > &

Re: Apache Cassandra Virtual meetings

[sankalp kohli]

@Dinesh/Nate: Yes we need to decide on the timing and we can always change
them as we go
@Joshua/Gary: We will publish notes on the mailing list. If we need to make
a decision, we will still need to get it voted on the ML. We should not
have a case where someone misses the boat because they could not attend one
of these. So ML is a big part of this.

Additional feedback welcome.

On Fri, Aug 9, 2019 at 6:28 AM Gary Dusbabek  wrote:

> Would publishing notes to the ML be sufficient? Apache board meetings work
> this way.
>
> Gary.
>
> On Wed, Aug 7, 2019 at 4:51 PM Nate McCall  wrote:
>
> > We can do the time mostly fair if we alternate back and forth between PST
> > morning and evening. This will at least let most folks attend every other
> > meeting.
> >
> > I agree with Josh's sentiment on the discussions. We can do it, we just
> > have to be aware of it and defer things to Jira and/or ML.
> >
> > On Thu, Aug 8, 2019 at 12:42 AM Joshua McKenzie 
> > wrote:
> >
> > > The one thing we need to keep in mind is the "If it didn't happen on a
> > > mailing list, it didn't happen <http://theapacheway.com/on-list/>"
> > > philosophy of apache projects. Shouldn't constrain us too much as the
> > > nuance is:
> > >
> > > *"Discussions and plan proposals often happen at events, in chats
> (Slack,
> > > IRC, IM, etc.) or other synchronous places. But all final decisions
> about
> > > executing on the plan, checking in the new code, or launching the
> website
> > > must be made by the community asyncrhonously on the mailing list."*
> > >
> > > So long as we keep that in mind (and maybe push it back to 8am PST
> since
> > > 9am can get pretty ugly for some of the more eastern european / asian
> > > countries), makes sense to me.
> > >
> > > On Tue, Aug 6, 2019 at 6:07 PM Dinesh Joshi  wrote:
> > >
> > > > Thanks for initiating this conversation Sankalp. On the ASF front, I
> > > think
> > > > we need to ensure that non-Pacific time participants can also
> > participate
> > > > in the discussions. So posting the notes and opening up discussions
> > after
> > > > the meet up to dev@ would be a great way of making sure everyone can
> > > > participate and gets visibility. Additionally, we should consider
> > > > scheduling this meetup in different timezones as far as logistics
> allow
> > > it.
> > > >
> > > > Dinesh
> > > >
> > > > > On Aug 6, 2019, at 2:58 PM, sankalp kohli 
> > > > wrote:
> > > > >
> > > > > Hi All,
> > > > > There are projects (like k8s[1]) which do regular meetings
> > > using
> > > > > video conferencing tools. We want to propose such a meeting for
> > Apache
> > > > > Cassandra once a quarter. Here are some of the initial details.
> > > > >
> > > > > 1. A two hour meeting once a quarter starting at 9am Pacific. We
> can
> > > > later
> > > > > move this to other times to make it easier for other timezones.
> > > > > 2. Agenda of the meeting will be due 2 days prior to the meeting. A
> > > > sample
> > > > > agenda for next one could cover updates on 4.0 testing, any major
> > bugs
> > > > > found and/or fixed, next steps for 4.0, etc.
> > > > > 3. Each agenda item will have a time duration and list of people to
> > > drive
> > > > > that item.
> > > > > 4. We will have a moderator for each meeting which will rotate
> around
> > > the
> > > > > community members.
> > > > > 5. We need to figure out which video conferencing tool to use for
> > this.
> > > > > Suggestions and donation of tools are welcome.
> > > > > 6. We will have meeting notes for each item discussed in the
> meeting.
> > > > >
> > > > > Motivation for such a meeting
> > > > > 1. We currently have Slack, JIRA and emails however an agenda
> driven
> > > > video
> > > > > meeting can help facilitate alignment within the community.
> > > > > 2. This will give an opportunity to the community to summarize past
> > > > > progress and talk about future tasks.
> > > > > 3. Agenda notes can serve as newsletters for the community.
> > > > >
> > > > > Notes:
> > > > > 1. Does this violate any Apache rules? I could not find any rules
> but
> > > > > someone can double check
> > > > > 2. Are there any other Apache projects which do something similar?
> > > > >
> > > > > This is a proposal at this time and your feedback is greatly
> > > appreciated.
> > > > > If anyone thinks this will not help then please provide a reason.
> > > > >
> > > > > Thanks,
> > > > > Sankalp
> > > > > [1]
> https://github.com/kubernetes/community/tree/master/sig-storage
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Apache Cassandra Virtual meetings

[sankalp kohli]

Hi All,
 There are projects (like k8s[1]) which do regular meetings using
video conferencing tools. We want to propose such a meeting for Apache
Cassandra once a quarter. Here are some of the initial details.

1. A two hour meeting once a quarter starting at 9am Pacific. We can later
move this to other times to make it easier for other timezones.
2. Agenda of the meeting will be due 2 days prior to the meeting. A sample
agenda for next one could cover updates on 4.0 testing, any major bugs
found and/or fixed, next steps for 4.0, etc.
3. Each agenda item will have a time duration and list of people to drive
that item.
4. We will have a moderator for each meeting which will rotate around the
community members.
5. We need to figure out which video conferencing tool to use for this.
Suggestions and donation of tools are welcome.
6. We will have meeting notes for each item discussed in the meeting.

Motivation for such a meeting
1. We currently have Slack, JIRA and emails however an agenda driven video
meeting can help facilitate alignment within the community.
2. This will give an opportunity to the community to summarize past
progress and talk about future tasks.
3. Agenda notes can serve as newsletters for the community.

Notes:
1. Does this violate any Apache rules? I could not find any rules but
someone can double check
2. Are there any other Apache projects which do something similar?

This is a proposal at this time and your feedback is greatly appreciated.
If anyone thinks this will not help then please provide a reason.

Thanks,
Sankalp
[1] https://github.com/kubernetes/community/tree/master/sig-storage

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

[sankalp kohli]

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 folks virtual tables at the
> Accelerate conference last week and the missing table statistics was a big
> shock.  If we can get them in, it'll be a big help to operators.
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-14459
> [2] https://issues.apache.org/jira/browse/CASSANDRA-14630
> [3] https://issues.apache.org/jira/browse/CASSANDRA-14572
>
>
>
>
> On Mon, May 27, 2019 at 2:36 PM Nate McCall  wrote:
>
> > Hi Sumanth,
> > Thank you so much for taking the time to put this together.
> >
> > Cheers,
> > -Nate
> >
> > On Tue, May 28, 2019 at 3:27 AM Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> wrote:
> >
> > > 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 <
> kohlisank...@gmail.com>
> > > > 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
&

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

[sankalp kohli]

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

Re: Stabilising Internode Messaging in 4.0

[Sankalp Kohli]

I think we should wait for testing doc on confluence to come up and discuss 
what all needs to be added there to gain confidence. 

If the work is more to split the patch into smaller parts and delays 4.0 even 
more, can we use time in adding more test coverage, documentation and design 
docs to this component?  Will that be a middle ground here ? 

Examples of large changes not going well is due to lack of testing, 
documentation and design docs not because they were big. Being big adds to the 
complexity and increased the total bug count but small changes can be equally 
worse in terms of impact. 


> On Apr 10, 2019, at 8:53 AM, Jordan West  wrote:
> 
> There is a lot of discuss here so I’ll try to keep my opinions brief:
> 
> 1. The bug fixes are a requirement in order to have a stable 4.0. Whether
> they come from this patch or the original I have less of an opinion. I do
> think its important to minimize code changes at this time in the
> development/freeze cycle — including large refactors which add risk despite
> how they are being discussed here. From that perspective, I would prefer to
> see more targeted fixes but since we don’t have them and we have this patch
> the decision is different.
> 
> 2. We should not be measuring complexity in LoC with the exception that all
> 20k lines *do need to be review* (not just the important parts and because
> code refactoring tools have bugs too) and more lines take more time.
> Otherwise, its a poor metric for how long this will take to review.
> Further, it seems odd that the authors are projecting how long it will take
> to review — this should be the charge of the reviewers and I would like to
> hear from them on this. Its clear this a complex patch — as risky as
> something like 8099 (and the original rewrite by Jason). We should treat it
> as such and not try to merge it in quickly for the sake of it, repeating
> past mistakes. The goal of reviewing the messaging service work was to do
> just that. It would be a disservice to rush in these changes now. If the
> goal is to get the patch in that should be the priority, not completing it
> “in two weeks”. Its clear several community members have pushed back on
> that and are not comfortable with the time frame.
> 
> 3. If we need to add special forks of Netty classes to the code because of
> “how we use Netty” that is a concern to me w.r.t to quality, stability, and
> maintenance. Is there a place that documents/justifies our non-traditional
> usage (I saw some in JavaDocs but found it lacking in *why* but had a lot
> of how/what was changed). Given folks in the community have decent
> relationships with the Netty team perhaps we should leverage that as well.
> Have we reached out to them?
> 
> 4. In principle, I agree with the technical improvements you mention
> (backpressure / checksumming / etc). These things should be there. Are they
> a hard requirement for 4.0? In my opinion no and Dinesh has done a good job
> of providing some reasons as to why so I won’t go into much detail here. In
> short, a bug and a missing safety mechanism are not the same thing. Its
> also important to consider how many users a change like that covers and for
> what risk — we found a bug in 13304 late in review, had it slipped through
> it would have subjected users to silent corruption they thought couldn’t
> occur anymore because we included the feature in a prod Cassandra release.
> 
> 5. The patch could seriously benefit from some commit hygiene that would
> make it easier for folks to review. Had this been done not only would
> review be easier but also the piecemeal breakup of features/fixes could
> have been done more easily. I don’t buy the premise that this wasn’t
> possible. If we had to add the feature/fix later it would have been
> possible. I’m sure there was a smart way we could have organized it, if it
> was a priority.
> 
> 6. Have any upgrade tests been done/added? I would also like to see some
> performance benchmarks before merging so that the patch is in a similar
> state as 14503 in terms of performance testing.
> 
> I’m sure I have more thoughts but these seem like the important ones for
> now.
> 
> Jordan
> 
> On Wed, Apr 10, 2019 at 8:21 AM Dinesh Joshi 
> wrote:
> 
>> Here's are my 2¢.
>> 
>> I think the general direction of this work is valuable but I have a few
>> concerns I’d like to address. More inline.
>> 
>>> On Apr 4, 2019, at 1:13 PM, Aleksey Yeschenko 
>> wrote:
>>> 
>>> I would like to propose CASSANDRA-15066 [1] - an important set of bug
>> fixes
>>> and stability improvements to internode messaging code that Benedict, I,
>>> and others have been working on for the past couple of months.
>>> 
>>> First, some context.   This work started off as a review of
>> CASSANDRA-14503
>>> (Internode connection management is race-prone [2]), CASSANDRA-13630
>>> (Support large internode messages with netty) [3], and a pre-4.0
>>> confirmatory review of such a major new feature.
>>> 
>>> However, as 

Re: Warn about SASI usage and allow to disable them

[Sankalp Kohli]

Can we have a page or a JIRA label which users can see to know why it is 
experimental. Putting a warning without telling why is not good. But since 
warning is better than nothing, I am -0 on warn

> On Jan 26, 2019, at 9:37 AM, Andrés de la Peña  
> wrote:
> 
> I agree with Paulo's proposal. I think it will give us a very desirable
> homogeneity in how we deal with experimental features.
> 
> I'm +1 to warning, config property, and experimental features (SASI and MV)
> disabled by default in trunk.
> 
> These are the explicit votes for now, if I'm counting right:
> 
> - CQL native protocol warning on create SASI index: three +1s, one +0 and
> two -0s
> - Config property to disable new SASI creation: ten +1s
> - New SASI creation disabled by default in trunk: nine +1s and one -0
> - New MV creation disabled by default in trunk: three +1s
> 
> If there are no objections, I'll update the patch by the end of next week.
> 
>> On Mon, 21 Jan 2019 at 19:26, Paulo Motta  wrote:
>> 
>> +1 to enable_sasi_indexes flag
>> +1 to disabling experimental features by default on 4.0 (SASI and MVs,
>> transient replication already disabled)
>> 
>> Regarding the warning on creation of SASI indexes, I think that's a
>> user-level warning complimentary to the flag, which is targeted to admins,
>> so +1. If people are bothered by this, we could add another flag to disable
>> warnings on experimental features, which would be applied to both this and
>> MV creation warning (and any other future experimental feature).
>> 
>> I think the warning should be "SASI indexes are experimental and are not
>> recommended for production use.", similar to the MV warning added on
>> CASSANDRA-13959.
>> 
>> We should open a doc ticket to list limitations of experimental features
>> (MVs, SASI, transient replication), but this should probably be out of the
>> scope of CASSANDRA-14866. Once we have this doc, we can maybe amend the
>> warning to include a link to the doc.
>> 
>> Now that the number of experimental feature flags is growing we should
>> perhaps unify all flags in a "experimental features" section on
>> cassandra.yaml to allow easily locating them - and a pointer to the
>> limitations doc once we have it.
>> 
>> Em qua, 16 de jan de 2019 às 20:18, sankalp kohli 
>> escreveu:
>> 
>>> If we want to put a warning, we should list in a doc all the open issues
>> it
>>> has along with explanation of how it can impact. We have a few in the
>> first
>>> email of this thread but we should put it in a doc for people to know
>> what
>>> are the issues and if they want to take that risk.
>>> 
>>> 
>>> 
>>> On Wed, Jan 16, 2019 at 3:14 PM Brandon Williams 
>> wrote:
>>> 
>>>> Which, if I'm not mistaken, is the goal here?
>>>> 
>>>>> On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa  wrote:
>>>>> 
>>>>> The cost is in how many users you scare away
>>>>> 
>>>>> --
>>>>> Jeff Jirsa
>>>>> 
>>>>> 
>>>>>> On Jan 16, 2019, at 2:34 PM, Brandon Williams 
>>>> wrote:
>>>>>> 
>>>>>> Also it costs us nothing to add it.
>>>>>> 
>>>>>>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad <
>> j...@jonhaddad.com>
>>>>> wrote:
>>>>>>> 
>>>>>>> I'm +1 on the warning for two reasons.
>>>>>>> 
>>>>>>>> A cqlsh warning only applies to those that create the sasi via
>>> cqlsh.
>>>>>>> 
>>>>>>> 1. When people are creating their schemas in development, this is
>>>>> usually
>>>>>>> the first step.  You use the REPL to figure out what you need,
>> then
>>>> you
>>>>>>> copy your schema somewhere else.  The warning here should prevent
>> a
>>>> lot
>>>>> of
>>>>>>> folks from making a serious mistake.
>>>>>>> 
>>>>>>> 2. It's consistent with how we warn when people try to use
>>>> materialized
>>>>>>> views.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Wed, Jan 16, 2019 at 2:15 PM Mick Semb Wever 
>>>>> wrote:
>>>>>>>> 
>>>>>>>> Regarding the

Re: [VOTE] Change Jira Workflow

[sankalp kohli]

+1

On Tue, Dec 18, 2018 at 9:16 PM Ariel Weisberg  wrote:

> +1
>
> On Mon, Dec 17, 2018, at 10:19 AM, Benedict Elliott Smith wrote:
> > I propose these changes
> > <
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>*
>
> > to the Jira Workflow for the project.  The vote will be open for 72
> > hours**.
> >
> > I am, of course, +1.
> >
> > * With the addendum of the mailing list discussion
> > <
> https://lists.apache.org/thread.html/e4668093169aa4ef52f2bea779333f04a0afde8640c9a79a8c86ee74@%3Cdev.cassandra.apache.org%3E>;
>
> > in case of any conflict arising from a mistake on my part in the wiki,
> > the consensus reached by polling the mailing list will take precedence.
> > ** I won’t be around to close the vote, as I will be on vacation.
> > Everyone is welcome to ignore the result until I get back in a couple of
> > weeks, or if anybody is eager feel free to close the vote and take some
> > steps towards implementation.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

If no one has more feedback, we should create JIRAs for all the subtasks
discussed in the proposal. I can see JIRA for Bulk command but not others.

On Mon, Nov 19, 2018 at 2:12 AM dinesh.jo...@yahoo.com.INVALID
 wrote:

> Thanks, Mick & Stefan for your inputs. What should we do as next steps to
> move this proposal forward?
> Dinesh
>
> On Sunday, November 18, 2018, 11:57:54 AM PST, Stefan Podkowinski <
> s...@apache.org> wrote:
>
>  My goal for a side car would be to enable more people to contribute to
> the project, by making it more accessible for anyone who’s not familiar
> with the Cassandra code base, or not familiar with Java development in
> general. Although most of the functionality described in the proposal
> sounds useful to have, I’d already be happy to have a solid REST API for
> the existing nodetool and JMX functionality. If an official side car,
> installed separately on each node, would provide that, I’m sure we’d see
> lots of new tools created by the community (web UIs, cli tools, ..)
> based on that. This would also be a good foundation for other existing
> tool to converge upon, e.g. by calling the REST APIs for repair
> scheduling and progress tracking instead of JMX, or by continually
> integrating and sharing useful helper calls. This would also give
> Cassandra devs more leeway to replace some of the existing tooling
> related code in Cassandra, e.g. by migrating to virtual tables, while at
> the same time keep providing a stable API through the side car.
>
> What I’d also like to point out here is that implementing such a project
> as an *official* side car, also implies to me having the same standards
> when it comes to release quality. I’d also really prefer having feature
> sets matching between Cassandra and the side car, e.g. authentication
> and SSL should also be supported in the side car from the beginning,
> ideally without any additional configuration.
>
>
> On 06.11.18 10:40, Dinesh Joshi wrote:
> > Hi all,
> >
> > Joey, Vinay & I have fleshed out the Management process proposal as the
> very first CIP document (with Jason’s inputs). It is available on the cwiki
> -
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
> >
> > Please comment on it and provide us any input that you may have. We want
> to ideally time-box the period to 2 weeks so we avoid waiting indefinitely.
> >
> > Thanks,
> >
> > Dinesh
> >
> >> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID" <
> dinesh.jo...@yahoo.com.INVALID> wrote:
> >>
> >> Thanks for starting this, Mick. I will flesh it out.
> >> Dinesh
> >>
> >>On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever <
> m...@apache.org> wrote:
> >>
> >>
> >>> But I'll try to put together a strawman proposal for the doc(s) over
> the
> >>> weekend.
> >>
> >> I've thrown something quickly together here:
> >> -
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> >> -
> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process
> >>
> >> The former is a blatant rip-off from the Kafka and Spark design
> proposal pages that Dinesh previously mentioned. I'd hoped to do more of an
> analysis of the existing C* habits and precedence on design proposals
> (implicit in jira tickets), but in lei of that this is a strawman to start
> the discussion.
> >>
> >> The latter still needs to be fleshed out. Dinesh, can you do this? I
> can add a subpage/section that describes the alternative/consuming
> third-party tools out there.
> >>
> >> regards,
> >> Mick
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: JIRA Workflow Proposals

[Sankalp Kohli]

I have following initial comments on the proposal. 
1. Creating a JIRA should have few fields mandatory like platform, version, 
etc. We want to put less burden on someone creating a ticket but I feel these 
are required for opening bugs. 

2. What is the flow when a non committer does the first pass of review? 



> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie  wrote:
> 
> 1) Removal of labels: one of the strengths of the current model is
> flexibility for groupings of concepts to arise from a user-perspective
> (lhf, etc). Calcifying the label concepts into components, categories, etc.
> is a strict loss of functionality for users to express and categorize their
> concerns with the project. This feels like an over-correction to our
> current lack of discipline cleaning up one-off labels. Counter-proposal:
> 
>   1. We beef up the categories and components as proposed and migrate
>   labels to those
>   2. We remove the one-off labels that aren't adding value, considering
>   aggregating similar labels
>   3. We leave the "labels" field intact, perhaps with a bit of guidance on
>   how to effectively use it
> 
> 2) Required fields on transition: assuming these are required upon *issue
> creation*, that's placing a significant burden on a user that's seen
> something and wants to open a ticket about it, but isn't sure if it's a
> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
> instead, a field required for transition to other ticket states by the
> developer working on it, I think that makes sense.
> 
> 3) Priority Changes: to be blunt, this looks like shuffling chairs on the
> deck of the titanic on this one - in my experience, most users aren't going
> to set the priority on tickets when they open them (hence default == major
> and most tickets are opened as major), so this is something that will be
> either a) left alone so as not to offend those for whom the priority is
> *actually* major or consistent with the default, or b) changed by the dev
> anyway and the added signal from a new "High vs. Urgent" distinction and
> communication of developer intent to engage with a ticket is something
> that'll be lost on most users that are just reporting something. I don't
> have a meaningful counter-proposal at this point as the current problem is
> more about UX on this field than the signal / noise on the field itself IMO.
> 
> A meta question about the "What and Why" of what we're trying to accomplish
> here: it sounds like what you're looking at is:
> 
>   1. to capture more information
>   2. simplify the data entry
>   3. nudge people towards more complete and accurate data entry
>   4. our ability as a project to measure release quality over time and
>   identify when Cassandra is ready for (or due a) release.
> 
> The proposal in its current form makes certain strong inroads in all of
> those 4 metrics, but I think the major thing missing is the UX of what
> we're thinking about changing:
> 
>   1. Making it easy for / reduce friction for users to report bugs and
>   requests into the project JIRA (easy to do things right, hard to do things
>   wrong) (current proposal is a +1 on "do things right", though I'd argue
>   against it being *easy*)
>   2. Asking from the users what they can provide about their experience
>   and issues and no more
> 
> Philosophically, are we trying to make it easier for people that are paid
> FT to work on C*, are we trying to make things easier for *users* of C*,
> both, neither? Who are we targeting here w/these project changes and what
> of their issues / problems are we trying to improve?
> 
> And lastly: the TLC and management of the JIRA aspects of this project have
> *definitely* languished (not pointing any fingers here, I'm *at least* as
> guilty as anyone on this :) ) - so a big thanks to you and whomever you've
> collaborate with in getting this conversation started!
> 
> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
> wrote:
> 
>> We’ve concluded our efforts to produce a proposal for changes to the JIRA
>> workflow, and they can be found here:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>> <
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>> 
>> 
>> I hope there will be broad consensus, but I’m sure it won’t be plain
>> sailing.  It would be great to get a discussion going around the proposal,
>> so please take some time to read and respond if you think you’ll have a
>> strong opinion on this topic.
>> 
>> There remains an undecided question in our initial proposal, that is
>> highlighted in the wiki.  Specifically, there was no seemingly objective
>> winner for the suggested changes to Component (though I have a preference,
>> that I will express in the ensuing discussion).
>> 
>> Other contentious issues may be:
>> - The removal of ‘labels’ - which is very noisy, the vast majority of
>> which provide no value, and we expect can be superseded by other 

Re: Inter-node messaging latency

[sankalp kohli]

Inter-node messaging is rewritten using Netty in 4.0. It will be better to
test it using that as potential changes will mostly land on top of that.

On Mon, Nov 26, 2018 at 7:39 AM Yuji Ito  wrote:

> Hi,
>
> I'm investigating LWT performance with C* 3.11.3.
> It looks that the performance is bounded by messaging latency when many
> requests are issued concurrently.
>
> According to the source code, the number of messaging threads per node is
> only 1 thread for incoming and 1 thread for outbound "small" message to
> another node.
>
> I guess these threads are frequently interrupted because many threads are
> executed when many requests are issued.
> Especially, I think it affects the LWT performance when many LWT requests
> which need lots of inter-node messaging are issued.
>
> I measured that latency. It took 2.5 ms in average to enqueue a message at
> a node and to receive the message at the **same** node with 96 concurrent
> LWT writes.
> Is it normal? I think it is too big latency, though a message was sent to
> the same node.
>
> Decreasing numbers of other threads like `concurrent_counter_writes`,
> `concurrent_materialized_view_writes` reduced a bit the latency.
> Can I change any other parameter to reduce the latency?
> I've tried using message coalescing, but they didn't reduce that.
>
> * Environment
> - 3 node cluster
> - Replication factor: 3
> - Node instance: AWS EC2 i3.xlarge
>
> * C* configuration
> - Apache Cassandra 3.11.3
> - commitlog_sync: batch
> - concurrent_reads: 32 (default)
> - concurrent_writes: 32 (default)
>
> Thanks,
> Yuji
>
>
> -
> 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

[Sankalp Kohli]

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 
> 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: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

Hi Mick,
  Any feedback? 
Also pinging this thread after a week for others to give feedback 

> On Nov 6, 2018, at 1:40 AM, Dinesh Joshi  
> wrote:
> 
> Hi all,
> 
> Joey, Vinay & I have fleshed out the Management process proposal as the very 
> first CIP document (with Jason’s inputs). It is available on the cwiki - 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
> 
> Please comment on it and provide us any input that you may have. We want to 
> ideally time-box the period to 2 weeks so we avoid waiting indefinitely.
> 
> Thanks,
> 
> Dinesh
> 
>> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID" 
>>  wrote:
>> 
>> Thanks for starting this, Mick. I will flesh it out.
>> Dinesh 
>> 
>>   On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever 
>>  wrote:  
>> 
>> 
>>> But I'll try to put together a strawman proposal for the doc(s) over the 
>>> weekend. 
>> 
>> 
>> I've thrown something quickly together here:
>> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>> - 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process
>> 
>> The former is a blatant rip-off from the Kafka and Spark design proposal 
>> pages that Dinesh previously mentioned. I'd hoped to do more of an analysis 
>> of the existing C* habits and precedence on design proposals (implicit in 
>> jira tickets), but in lei of that this is a strawman to start the discussion.
>> 
>> The latter still needs to be fleshed out. Dinesh, can you do this? I can add 
>> a subpage/section that describes the alternative/consuming third-party tools 
>> out there.
>> 
>> regards,
>> Mick
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 

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

Re: Jepsen testing

[sankalp kohli]

Should we use confluence page to sign them up for this testing?

https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+QA+Signup

On Thu, Nov 8, 2018 at 2:07 PM Nate McCall  wrote:

> [- cassandra-users]
> Hi Yuji,
> Thanks so much for working on this! Any fault injection testing is
> certainly worth the effort.
>
> Thanks,
> -Nate
> On Thu, Nov 8, 2018 at 1:36 PM Yuji Ito  wrote:
> >
> > Hi,
> >
> > We are working on Jepsen testing for Cassandra.
> > https://github.com/scalar-labs/jepsen/tree/cassandra/cassandra
> >
> > As you may know, Jepsen is a framework for distributed systems
> verification.
> > It can inject network failure and so on and check data consistency.
> > https://github.com/jepsen-io/jepsen
> >
> > Our tests are based on riptano's great work.
> > https://github.com/riptano/jepsen/tree/cassandra/cassandra
> >
> > I refined it for the latest Jepsen and removed some tests.
> > Next, I'll fix clock-drift tests.
> >
> > I would like to get your feedback.
> >
> > Thanks,
> > Yuji Ito
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: 4.0 Testing Signup

[sankalp kohli]

This is good start and we should use this approach each component. Once we
have volunteers for each area, it will be important to also publish a
confluence page per component by the volunteer so we can know/discuss how
it was tested.

On Wed, Nov 7, 2018 at 12:14 PM Joseph Lynch  wrote:

> Following up on Jon's call
> <
> https://lists.apache.org/thread.html/17e57d1666393d961a15502a648a1174a1b145a4bf0a8e07fd8bb760@%3Cdev.cassandra.apache.org%3E
> >
> for QA, I put together the start of a confluence page
> for
> people to list out important components that they think should be tested
> before 4.0 releases and hopefully committers and contributors can signup
> and present their progress to the community. I've certainly missed a ton of
> components that need testing but I figured that it may be good to get the
> conversation started and moving forward.
>
> What do people think? Is there a more effective way to list these out or if
> people like this maybe folks can start contributing sections and
> volunteering to shepherd or test them?
>
> Let me know,
> -Joey
>

Re: Deprecating/removing PropertyFileSnitch?

[Sankalp Kohli]

No worries...I mentioned the issue not the JIRA number 

> On Oct 22, 2018, at 8:01 PM, Jeremiah D Jordan  wrote:
> 
> Sorry, maybe my spam filter got them or something, but I have never seen a 
> JIRA number mentioned in the thread before this one.  Just looked back 
> through again to make sure, and this is the first email I have with one.
> 
> -Jeremiah
> 
>> On Oct 22, 2018, at 9:37 PM, sankalp kohli  wrote:
>> 
>> Here are some of the JIRAs which are fixed but actually did not fix the
>> issue. We have tried fixing this by several patches. May be it will be
>> fixed when Gossip is rewritten(CASSANDRA-12345). I should find or create a
>> new JIRA as this issue still exists.
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D10366=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=lI3KEen0YYUim6t3VWsvITHUZfFX8oYaczP_t3kk21o=W_HfejhgW1gmZ06L0CXOnp_EgBQ1oI5MLMoyz0OrvFw=
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_CASSANDRA-2D10089=DwIFaQ=adz96Xi0w1RHqtPMowiL2g=CNZK3RiJDLqhsZDG6FQGnXn8WyPRCQhp4x_uBICNC0g=lI3KEen0YYUim6t3VWsvITHUZfFX8oYaczP_t3kk21o=qXzh1nq2yE27J8SvwYoRf9HPQE83m07cKdKVHXyOyAE=
>>  (related to it)
>> 
>> Also the quote you are using was written as a follow on email. I have
>> already said what the bug I was referring to.
>> 
>> "Say you restarted all instances in the cluster and status for some host
>> goes missing. Now when you start a host replacement, the new host won’t
>> learn about the host whose status is missing and the view of this host will
>> be wrong."
>> 
>>  - CASSANDRA-10366
>> 
>> 
>> On Mon, Oct 22, 2018 at 7:22 PM Sankalp Kohli 
>> wrote:
>> 
>>> I will send the JIRAs of the bug which we thought we have fixed but it
>>> still exists.
>>> 
>>> Have you done any correctness testing after doing all these tests...have
>>> you done the tests for 1000 instance clusters?
>>> 
>>> It is great you have done these tests and I am hoping the gossiping snitch
>>> is good. Also was there any Gossip bug fixed post 3.0? May be I am seeing
>>> the bug which is fixed.
>>> 
>>>> On Oct 22, 2018, at 7:09 PM, J. D. Jordan 
>>> wrote:
>>>> 
>>>> Do you have a specific gossip bug that you have seen recently which
>>> caused a problem that would make this happen?  Do you have a specific JIRA
>>> in mind?  “We can’t remove this because what if there is a bug” doesn’t
>>> seem like a good enough reason to me. If that was a reason we would never
>>> make any changes to anything.
>>>> I think many people have seen PFS actually cause real problems, where
>>> with GPFS the issue being talked about is predicated on some theoretical
>>> gossip bug happening.
>>>> In the past year at DataStax we have done a lot of testing on 3.0 and
>>> 3.11 around adding nodes, adding DC’s, replacing nodes, replacing racks,
>>> and replacing DC’s, all while using GPFS, and as far as I know we have not
>>> seen any “lost” rack/DC information during such testing.
>>>> 
>>>> -Jeremiah
>>>> 
>>>>> On Oct 22, 2018, at 5:46 PM, sankalp kohli 
>>> wrote:
>>>>> 
>>>>> We will have similar issues with Gossip but this will create more
>>> issues as
>>>>> more things will be relied on Gossip.
>>>>> 
>>>>> I agree PFS should be removed but I dont see how it can be with issues
>>> like
>>>>> these or someone proves that it wont cause any issues.
>>>>> 
>>>>> On Mon, Oct 22, 2018 at 2:21 PM Paulo Motta 
>>>>> wrote:
>>>>> 
>>>>>> I can understand keeping PFS for historical/compatibility reasons, but
>>> if
>>>>>> gossip is broken I think you will have similar ring view problems
>>> during
>>>>>> replace/bootstrap that would still occur with the use of PFS (such as
>>>>>> missing tokens, since those are propagated via gossip), so that doesn't
>>>>>> seem like a strong reason to keep it around.
>>>>>> 
>>>>>> With PFS it's pretty easy to shoot yourself in the foot if you're not
>>>>>> careful enough to have identical files across nodes and updating it
>>> when
>>>>>> adding nodes/dcs, so it's seems to be less foolproof than other
>>> snitches.
>>>>>> While the rejectio

Re: Deprecating/removing PropertyFileSnitch?

[Sankalp Kohli]

+1 to fallback and like I said before removing PFS is a good idea as long it is 
safe 

> On Oct 22, 2018, at 7:41 PM, Jeff Jirsa  wrote:
> 
> On Mon, Oct 22, 2018 at 7:09 PM J. D. Jordan 
> wrote:
> 
>> Do you have a specific gossip bug that you have seen recently which caused
>> a problem that would make this happen?  Do you have a specific JIRA in mind?
> 
> 
> Sankalp linked a few others, but also
> https://issues.apache.org/jira/browse/CASSANDRA-13700
> 
> 
>>  “We can’t remove this because what if there is a bug” doesn’t seem like
>> a good enough reason to me. If that was a reason we would never make any
>> changes to anything.
>> 
> 
> How about "we know that certain fields that are gossiped go missing even
> after all of the known races are fixed, so removing an existing
> low-maintenance feature and forcing users to rely on gossip for topology
> may be worth some discussion".
> 
> 
>> I think many people have seen PFS actually cause real problems, where with
>> GPFS the issue being talked about is predicated on some theoretical gossip
>> bug happening.
>> 
> 
> How many of those were actually caused by incorrect fallback from GPFS to
> PFS, rather than PFS itself?
> 
> 
>> In the past year at DataStax we have done a lot of testing on 3.0 and 3.11
>> around adding nodes, adding DC’s, replacing nodes, replacing racks, and
>> replacing DC’s, all while using GPFS, and as far as I know we have not seen
>> any “lost” rack/DC information during such testing.
>> 
> 
> I've also run very large GPFS clusters in the past without much gossip
> pain, and I'm in the "we should deprecate PFS" camp, but it is also true
> that PFS is low maintenance and mostly works. Perhaps the first step is
> breaking the GPFS->PFS fallback that people don't know about, maybe that'll
> help?

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

Re: Deprecating/removing PropertyFileSnitch?

[sankalp kohli]

Here are some of the JIRAs which are fixed but actually did not fix the
issue. We have tried fixing this by several patches. May be it will be
fixed when Gossip is rewritten(CASSANDRA-12345). I should find or create a
new JIRA as this issue still exists.
https://issues.apache.org/jira/browse/CASSANDRA-10366
https://issues.apache.org/jira/browse/CASSANDRA-10089 (related to it)

Also the quote you are using was written as a follow on email. I have
already said what the bug I was referring to.

"Say you restarted all instances in the cluster and status for some host
goes missing. Now when you start a host replacement, the new host won’t
learn about the host whose status is missing and the view of this host will
be wrong."

   - CASSANDRA-10366


On Mon, Oct 22, 2018 at 7:22 PM Sankalp Kohli 
wrote:

> I will send the JIRAs of the bug which we thought we have fixed but it
> still exists.
>
> Have you done any correctness testing after doing all these tests...have
> you done the tests for 1000 instance clusters?
>
> It is great you have done these tests and I am hoping the gossiping snitch
> is good. Also was there any Gossip bug fixed post 3.0? May be I am seeing
> the bug which is fixed.
>
> > On Oct 22, 2018, at 7:09 PM, J. D. Jordan 
> wrote:
> >
> > Do you have a specific gossip bug that you have seen recently which
> caused a problem that would make this happen?  Do you have a specific JIRA
> in mind?  “We can’t remove this because what if there is a bug” doesn’t
> seem like a good enough reason to me. If that was a reason we would never
> make any changes to anything.
> > I think many people have seen PFS actually cause real problems, where
> with GPFS the issue being talked about is predicated on some theoretical
> gossip bug happening.
> > In the past year at DataStax we have done a lot of testing on 3.0 and
> 3.11 around adding nodes, adding DC’s, replacing nodes, replacing racks,
> and replacing DC’s, all while using GPFS, and as far as I know we have not
> seen any “lost” rack/DC information during such testing.
> >
> > -Jeremiah
> >
> >> On Oct 22, 2018, at 5:46 PM, sankalp kohli 
> wrote:
> >>
> >> We will have similar issues with Gossip but this will create more
> issues as
> >> more things will be relied on Gossip.
> >>
> >> I agree PFS should be removed but I dont see how it can be with issues
> like
> >> these or someone proves that it wont cause any issues.
> >>
> >> On Mon, Oct 22, 2018 at 2:21 PM Paulo Motta 
> >> wrote:
> >>
> >>> I can understand keeping PFS for historical/compatibility reasons, but
> if
> >>> gossip is broken I think you will have similar ring view problems
> during
> >>> replace/bootstrap that would still occur with the use of PFS (such as
> >>> missing tokens, since those are propagated via gossip), so that doesn't
> >>> seem like a strong reason to keep it around.
> >>>
> >>> With PFS it's pretty easy to shoot yourself in the foot if you're not
> >>> careful enough to have identical files across nodes and updating it
> when
> >>> adding nodes/dcs, so it's seems to be less foolproof than other
> snitches.
> >>> While the rejection of verbs to invalid replicas on trunk could address
> >>> concerns raised by Jeremy, this would only happen after the new node
> joins
> >>> the ring, so you would need to re-bootstrap the node and lose all the
> work
> >>> done in the original bootstrap.
> >>>
> >>> Perhaps one good reason to use PFS is the ability to easily package it
> >>> across multiple nodes, as pointed out by Sean Durity on CASSANDRA-10745
> >>> (which is also it's Achilles' heel). To keep this ability, we could
> make
> >>> GPFS compatible with the cassandra-topology.properties file, but
> reading
> >>> only the dc/rack info about the local node.
> >>>
> >>> Em seg, 22 de out de 2018 às 16:58, sankalp kohli <
> kohlisank...@gmail.com>
> >>> escreveu:
> >>>
> >>>> Yes it will happen. I am worried that same way DC or rack info can go
> >>>> missing.
> >>>>
> >>>> On Mon, Oct 22, 2018 at 12:52 PM Paulo Motta <
> pauloricard...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>>> the new host won’t learn about the host whose status is missing and
> >>> the
> >>>>> view of this host will be wrong.
> >>>>>
> >>>>> Won't this happen even with PropertyFileSnitch as th

Re: Deprecating/removing PropertyFileSnitch?

[Sankalp Kohli]

I will send the JIRAs of the bug which we thought we have fixed but it still 
exists. 

Have you done any correctness testing after doing all these tests...have you 
done the tests for 1000 instance clusters? 

It is great you have done these tests and I am hoping the gossiping snitch is 
good. Also was there any Gossip bug fixed post 3.0? May be I am seeing the bug 
which is fixed. 

> On Oct 22, 2018, at 7:09 PM, J. D. Jordan  wrote:
> 
> Do you have a specific gossip bug that you have seen recently which caused a 
> problem that would make this happen?  Do you have a specific JIRA in mind?  
> “We can’t remove this because what if there is a bug” doesn’t seem like a 
> good enough reason to me. If that was a reason we would never make any 
> changes to anything.
> I think many people have seen PFS actually cause real problems, where with 
> GPFS the issue being talked about is predicated on some theoretical gossip 
> bug happening.
> In the past year at DataStax we have done a lot of testing on 3.0 and 3.11 
> around adding nodes, adding DC’s, replacing nodes, replacing racks, and 
> replacing DC’s, all while using GPFS, and as far as I know we have not seen 
> any “lost” rack/DC information during such testing.
> 
> -Jeremiah
> 
>> On Oct 22, 2018, at 5:46 PM, sankalp kohli  wrote:
>> 
>> We will have similar issues with Gossip but this will create more issues as
>> more things will be relied on Gossip.
>> 
>> I agree PFS should be removed but I dont see how it can be with issues like
>> these or someone proves that it wont cause any issues.
>> 
>> On Mon, Oct 22, 2018 at 2:21 PM Paulo Motta 
>> wrote:
>> 
>>> I can understand keeping PFS for historical/compatibility reasons, but if
>>> gossip is broken I think you will have similar ring view problems during
>>> replace/bootstrap that would still occur with the use of PFS (such as
>>> missing tokens, since those are propagated via gossip), so that doesn't
>>> seem like a strong reason to keep it around.
>>> 
>>> With PFS it's pretty easy to shoot yourself in the foot if you're not
>>> careful enough to have identical files across nodes and updating it when
>>> adding nodes/dcs, so it's seems to be less foolproof than other snitches.
>>> While the rejection of verbs to invalid replicas on trunk could address
>>> concerns raised by Jeremy, this would only happen after the new node joins
>>> the ring, so you would need to re-bootstrap the node and lose all the work
>>> done in the original bootstrap.
>>> 
>>> Perhaps one good reason to use PFS is the ability to easily package it
>>> across multiple nodes, as pointed out by Sean Durity on CASSANDRA-10745
>>> (which is also it's Achilles' heel). To keep this ability, we could make
>>> GPFS compatible with the cassandra-topology.properties file, but reading
>>> only the dc/rack info about the local node.
>>> 
>>> Em seg, 22 de out de 2018 às 16:58, sankalp kohli 
>>> escreveu:
>>> 
>>>> Yes it will happen. I am worried that same way DC or rack info can go
>>>> missing.
>>>> 
>>>> On Mon, Oct 22, 2018 at 12:52 PM Paulo Motta 
>>>> wrote:
>>>> 
>>>>>> the new host won’t learn about the host whose status is missing and
>>> the
>>>>> view of this host will be wrong.
>>>>> 
>>>>> Won't this happen even with PropertyFileSnitch as the token(s) for this
>>>>> host will be missing from gossip/system.peers?
>>>>> 
>>>>> Em sáb, 20 de out de 2018 às 00:34, Sankalp Kohli <
>>>> kohlisank...@gmail.com>
>>>>> escreveu:
>>>>> 
>>>>>> Say you restarted all instances in the cluster and status for some
>>> host
>>>>>> goes missing. Now when you start a host replacement, the new host
>>> won’t
>>>>>> learn about the host whose status is missing and the view of this
>>> host
>>>>> will
>>>>>> be wrong.
>>>>>> 
>>>>>> PS: I will be happy to be proved wrong as I can also start using
>>> Gossip
>>>>>> snitch :)
>>>>>> 
>>>>>>> On Oct 19, 2018, at 2:41 PM, Jeremy Hanna <
>>>> jeremy.hanna1...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Do you mean to say that during host replacement there may be a time
>>>>> when
>>>>>> the old->new host isn’t fully prop

Re: Deprecating/removing PropertyFileSnitch?

[sankalp kohli]

We will have similar issues with Gossip but this will create more issues as
more things will be relied on Gossip.

I agree PFS should be removed but I dont see how it can be with issues like
these or someone proves that it wont cause any issues.

On Mon, Oct 22, 2018 at 2:21 PM Paulo Motta 
wrote:

> I can understand keeping PFS for historical/compatibility reasons, but if
> gossip is broken I think you will have similar ring view problems during
> replace/bootstrap that would still occur with the use of PFS (such as
> missing tokens, since those are propagated via gossip), so that doesn't
> seem like a strong reason to keep it around.
>
> With PFS it's pretty easy to shoot yourself in the foot if you're not
> careful enough to have identical files across nodes and updating it when
> adding nodes/dcs, so it's seems to be less foolproof than other snitches.
> While the rejection of verbs to invalid replicas on trunk could address
> concerns raised by Jeremy, this would only happen after the new node joins
> the ring, so you would need to re-bootstrap the node and lose all the work
> done in the original bootstrap.
>
> Perhaps one good reason to use PFS is the ability to easily package it
> across multiple nodes, as pointed out by Sean Durity on CASSANDRA-10745
> (which is also it's Achilles' heel). To keep this ability, we could make
> GPFS compatible with the cassandra-topology.properties file, but reading
> only the dc/rack info about the local node.
>
> Em seg, 22 de out de 2018 às 16:58, sankalp kohli 
> escreveu:
>
> > Yes it will happen. I am worried that same way DC or rack info can go
> > missing.
> >
> > On Mon, Oct 22, 2018 at 12:52 PM Paulo Motta 
> > wrote:
> >
> > > > the new host won’t learn about the host whose status is missing and
> the
> > > view of this host will be wrong.
> > >
> > > Won't this happen even with PropertyFileSnitch as the token(s) for this
> > > host will be missing from gossip/system.peers?
> > >
> > > Em sáb, 20 de out de 2018 às 00:34, Sankalp Kohli <
> > kohlisank...@gmail.com>
> > > escreveu:
> > >
> > > > Say you restarted all instances in the cluster and status for some
> host
> > > > goes missing. Now when you start a host replacement, the new host
> won’t
> > > > learn about the host whose status is missing and the view of this
> host
> > > will
> > > > be wrong.
> > > >
> > > > PS: I will be happy to be proved wrong as I can also start using
> Gossip
> > > > snitch :)
> > > >
> > > > > On Oct 19, 2018, at 2:41 PM, Jeremy Hanna <
> > jeremy.hanna1...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Do you mean to say that during host replacement there may be a time
> > > when
> > > > the old->new host isn’t fully propagated and therefore wouldn’t yet
> be
> > in
> > > > all system tables?
> > > > >
> > > > >> On Oct 17, 2018, at 4:20 PM, sankalp kohli <
> kohlisank...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> This is not the case during host replacement correct?
> > > > >>
> > > > >> On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan <
> > > > >> jeremiah.jor...@gmail.com> wrote:
> > > > >>
> > > > >>> As long as we are correctly storing such things in the system
> > tables
> > > > and
> > > > >>> reading them out of the system tables when we do not have the
> > > > information
> > > > >>> from gossip yet, it should not be a problem. (As far as I know
> GPFS
> > > > does
> > > > >>> this, but I have not done extensive code diving or testing to
> make
> > > > sure all
> > > > >>> edge cases are covered there)
> > > > >>>
> > > > >>> -Jeremiah
> > > > >>>
> > > > >>>> On Oct 16, 2018, at 11:56 AM, sankalp kohli <
> > kohlisank...@gmail.com
> > > >
> > > > >>> wrote:
> > > > >>>>
> > > > >>>> Will GossipingPropertyFileSnitch not be vulnerable to Gossip
> bugs
> > > > where
> > > > >>> we
> > > > >>>> lose hostId or some other fields when we restart C* for large
> > > > >>>> clusters(~1000 instances)?
> > > > >>

Re: Deprecating/removing PropertyFileSnitch?

[sankalp kohli]

Yes it will happen. I am worried that same way DC or rack info can go
missing.

On Mon, Oct 22, 2018 at 12:52 PM Paulo Motta 
wrote:

> > the new host won’t learn about the host whose status is missing and the
> view of this host will be wrong.
>
> Won't this happen even with PropertyFileSnitch as the token(s) for this
> host will be missing from gossip/system.peers?
>
> Em sáb, 20 de out de 2018 às 00:34, Sankalp Kohli 
> escreveu:
>
> > Say you restarted all instances in the cluster and status for some host
> > goes missing. Now when you start a host replacement, the new host won’t
> > learn about the host whose status is missing and the view of this host
> will
> > be wrong.
> >
> > PS: I will be happy to be proved wrong as I can also start using Gossip
> > snitch :)
> >
> > > On Oct 19, 2018, at 2:41 PM, Jeremy Hanna 
> > wrote:
> > >
> > > Do you mean to say that during host replacement there may be a time
> when
> > the old->new host isn’t fully propagated and therefore wouldn’t yet be in
> > all system tables?
> > >
> > >> On Oct 17, 2018, at 4:20 PM, sankalp kohli 
> > wrote:
> > >>
> > >> This is not the case during host replacement correct?
> > >>
> > >> On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan <
> > >> jeremiah.jor...@gmail.com> wrote:
> > >>
> > >>> As long as we are correctly storing such things in the system tables
> > and
> > >>> reading them out of the system tables when we do not have the
> > information
> > >>> from gossip yet, it should not be a problem. (As far as I know GPFS
> > does
> > >>> this, but I have not done extensive code diving or testing to make
> > sure all
> > >>> edge cases are covered there)
> > >>>
> > >>> -Jeremiah
> > >>>
> > >>>> On Oct 16, 2018, at 11:56 AM, sankalp kohli  >
> > >>> wrote:
> > >>>>
> > >>>> Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs
> > where
> > >>> we
> > >>>> lose hostId or some other fields when we restart C* for large
> > >>>> clusters(~1000 instances)?
> > >>>>
> > >>>>> On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa 
> wrote:
> > >>>>>
> > >>>>> We should, but the 4.0 features that log/reject verbs to invalid
> > >>> replicas
> > >>>>> solves a lot of the concerns here
> > >>>>>
> > >>>>> --
> > >>>>> Jeff Jirsa
> > >>>>>
> > >>>>>
> > >>>>>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna <
> > jeremy.hanna1...@gmail.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> We have had PropertyFileSnitch for a long time even though
> > >>>>> GossipingPropertyFileSnitch is effectively a superset of what it
> > offers
> > >>> and
> > >>>>> is much less error prone.  There are some unexpected behaviors when
> > >>> things
> > >>>>> aren’t configured correctly with PFS.  For example, if you replace
> > >>> nodes in
> > >>>>> one DC and add those nodes to that DCs property files and not the
> > other
> > >>> DCs
> > >>>>> property files - the resulting problems aren’t very straightforward
> > to
> > >>>>> troubleshoot.
> > >>>>>>
> > >>>>>> We could try to improve the resilience and fail fast error
> checking
> > and
> > >>>>> error reporting of PFS, but honestly, why wouldn’t we deprecate and
> > >>> remove
> > >>>>> PropertyFileSnitch?  Are there reasons why GPFS wouldn’t be
> > sufficient
> > >>> to
> > >>>>> replace it?
> > >>>>>>
> > -
> > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> -
> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>
> > >>>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Deprecating/removing PropertyFileSnitch?

[Sankalp Kohli]

Say you restarted all instances in the cluster and status for some host goes 
missing. Now when you start a host replacement, the new host won’t learn about 
the host whose status is missing and the view of this host will be wrong.

PS: I will be happy to be proved wrong as I can also start using Gossip snitch 
:) 

> On Oct 19, 2018, at 2:41 PM, Jeremy Hanna  wrote:
> 
> Do you mean to say that during host replacement there may be a time when the 
> old->new host isn’t fully propagated and therefore wouldn’t yet be in all 
> system tables?
> 
>> On Oct 17, 2018, at 4:20 PM, sankalp kohli  wrote:
>> 
>> This is not the case during host replacement correct?
>> 
>> On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>> 
>>> As long as we are correctly storing such things in the system tables and
>>> reading them out of the system tables when we do not have the information
>>> from gossip yet, it should not be a problem. (As far as I know GPFS does
>>> this, but I have not done extensive code diving or testing to make sure all
>>> edge cases are covered there)
>>> 
>>> -Jeremiah
>>> 
>>>> On Oct 16, 2018, at 11:56 AM, sankalp kohli 
>>> wrote:
>>>> 
>>>> Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs where
>>> we
>>>> lose hostId or some other fields when we restart C* for large
>>>> clusters(~1000 instances)?
>>>> 
>>>>> On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa  wrote:
>>>>> 
>>>>> We should, but the 4.0 features that log/reject verbs to invalid
>>> replicas
>>>>> solves a lot of the concerns here
>>>>> 
>>>>> --
>>>>> Jeff Jirsa
>>>>> 
>>>>> 
>>>>>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna 
>>>>> wrote:
>>>>>> 
>>>>>> We have had PropertyFileSnitch for a long time even though
>>>>> GossipingPropertyFileSnitch is effectively a superset of what it offers
>>> and
>>>>> is much less error prone.  There are some unexpected behaviors when
>>> things
>>>>> aren’t configured correctly with PFS.  For example, if you replace
>>> nodes in
>>>>> one DC and add those nodes to that DCs property files and not the other
>>> DCs
>>>>> property files - the resulting problems aren’t very straightforward to
>>>>> troubleshoot.
>>>>>> 
>>>>>> We could try to improve the resilience and fail fast error checking and
>>>>> error reporting of PFS, but honestly, why wouldn’t we deprecate and
>>> remove
>>>>> PropertyFileSnitch?  Are there reasons why GPFS wouldn’t be sufficient
>>> to
>>>>> replace it?
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>>> 
>>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Sankalp Kohli]

(We should definitely harden the definition for freeze in a separate thread)

My thinking is that this is the best time to do this change as we have not even 
cut alpha or beta. All the people involved in the test will definitely be 
testing it again when we have these releases. 

> On Oct 19, 2018, at 8:00 AM, Michael Shuler  wrote:
> 
>> On 10/19/18 9:16 AM, Joshua McKenzie wrote:
>> 
>> At the risk of hijacking this thread, when are we going to transition from
>> "no new features, change whatever else you want including refactoring and
>> changing years-old defaults" to "ok, we think we have something that's
>> stable, time to start testing"?
> 
> Creating a cassandra-4.0 branch would allow trunk to, for instance, get
> a default config value change commit and get more testing. We might
> forget again, from what I understand of Benedict's last comment :)
> 
> -- 
> 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: Deprecating/removing PropertyFileSnitch?

[sankalp kohli]

This is not the case during host replacement correct?

On Tue, Oct 16, 2018 at 10:04 AM Jeremiah D Jordan <
jeremiah.jor...@gmail.com> wrote:

> As long as we are correctly storing such things in the system tables and
> reading them out of the system tables when we do not have the information
> from gossip yet, it should not be a problem. (As far as I know GPFS does
> this, but I have not done extensive code diving or testing to make sure all
> edge cases are covered there)
>
> -Jeremiah
>
> > On Oct 16, 2018, at 11:56 AM, sankalp kohli 
> wrote:
> >
> > Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs where
> we
> > lose hostId or some other fields when we restart C* for large
> > clusters(~1000 instances)?
> >
> > On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa  wrote:
> >
> >> We should, but the 4.0 features that log/reject verbs to invalid
> replicas
> >> solves a lot of the concerns here
> >>
> >> --
> >> Jeff Jirsa
> >>
> >>
> >>> On Oct 16, 2018, at 4:10 PM, Jeremy Hanna 
> >> wrote:
> >>>
> >>> We have had PropertyFileSnitch for a long time even though
> >> GossipingPropertyFileSnitch is effectively a superset of what it offers
> and
> >> is much less error prone.  There are some unexpected behaviors when
> things
> >> aren’t configured correctly with PFS.  For example, if you replace
> nodes in
> >> one DC and add those nodes to that DCs property files and not the other
> DCs
> >> property files - the resulting problems aren’t very straightforward to
> >> troubleshoot.
> >>>
> >>> We could try to improve the resilience and fail fast error checking and
> >> error reporting of PFS, but honestly, why wouldn’t we deprecate and
> remove
> >> PropertyFileSnitch?  Are there reasons why GPFS wouldn’t be sufficient
> to
> >> replace it?
> >>> -
> >>> 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: Deprecating/removing PropertyFileSnitch?

[sankalp kohli]

Will GossipingPropertyFileSnitch not be vulnerable to Gossip bugs where we
lose hostId or some other fields when we restart C* for large
clusters(~1000 instances)?

On Tue, Oct 16, 2018 at 7:59 AM Jeff Jirsa  wrote:

> We should, but the 4.0 features that log/reject verbs to invalid replicas
> solves a lot of the concerns here
>
> --
> Jeff Jirsa
>
>
> > On Oct 16, 2018, at 4:10 PM, Jeremy Hanna 
> wrote:
> >
> > We have had PropertyFileSnitch for a long time even though
> GossipingPropertyFileSnitch is effectively a superset of what it offers and
> is much less error prone.  There are some unexpected behaviors when things
> aren’t configured correctly with PFS.  For example, if you replace nodes in
> one DC and add those nodes to that DCs property files and not the other DCs
> property files - the resulting problems aren’t very straightforward to
> troubleshoot.
> >
> > We could try to improve the resilience and fail fast error checking and
> error reporting of PFS, but honestly, why wouldn’t we deprecate and remove
> PropertyFileSnitch?  Are there reasons why GPFS wouldn’t be sufficient to
> replace it?
> > -
> > 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: Proposing an Apache Cassandra Management process

[sankalp kohli]

Hi Mick,
Any other feedback?
Thanks,
Sankalp

On Sun, Sep 30, 2018 at 8:54 AM Sankalp Kohli 
wrote:

> Thank you for the feedback.  There are lot of advantages of doing this in
> Apache and you can read the thread to find more. The main one is to not
> divide the energy between different tools.
> Also we will not be reinventing the wheel as I think this project can
> still get donations along the way.
>
> > On Sep 30, 2018, at 05:31, Rahul Singh 
> wrote:
> >
> > Perfection is the enemy of the good enough. All if not most informed
> open source users understand that the tar they are downloading is
> “unsupported.”
> >
> > Most of the blog posts people read or the documentation they have is in
> place of tools. Open source software let alone Tooling even a nascent
> version comes with a degree of uncertainty.
> >
> > If the question is for me: I would rather use something that exists than
> reinvent the wheel. The same way I’ll use “contrib” packages in any system
> just to see if it works.
> >
> > Example: While working on on a Solr / Kafka / Cassandra integration
> project we must have used a few different “Kafka Connect” variations before
> settling on a solution which was a combination of an existing sink
> connector and created a source connector because what was out there “meh”.
> >
> > If we had scoffed off “unsupported” packages we would have spent more
> time making something than delivering value. Technology exists to serve
> business and people’s lives not technology itself.
> >
> > There is a level of discernment that comes with experience as to what
> works and what doesn’t and what is good and what isn’t. The least we can do
> is help the user community know the difference : as Apache does at a higher
> level.
> >
> >
> > Rahul Singh
> > Chief Executive Officer
> > m 202.905.2818
> >
> > Anant Corporation
> > 1010 Wisconsin Ave NW, Suite 250
> > Washington, D.C. 20007
> >
> > We build and manage digital business technology platforms.
> >> On Sep 29, 2018, 5:29 PM -0400, sankalp kohli ,
> wrote:
> >> Thanks Dinesh for looking at the tools and thanks Mick for listing them
> >> down.
> >> Based on Dinesh response, is it accurate to say that for bulk
> >> functionality, we have evaluated the tools listed by the community? If
> >> anything is missed we should discuss it as we want to make sure we
> looked
> >> at all aspects before implementation starts.
> >>
> >> On Sat, Sep 29, 2018 at 1:19 PM Dinesh Joshi  .invalid>
> >> wrote:
> >>
> >>>> On Sep 29, 2018, at 12:31 PM, Rahul Singh <
> rahul.xavier.si...@gmail.com>
> >>> wrote:
> >>>>
> >>>> All of Apache is a patchwork of tools. All of Open Source is a
> patchwork
> >>> of tools. All of Linux is a patchwork of tools.
> >>>>
> >>>> What works, works.
> >>>
> >>> So there isn't a way to make it any better? You would prefer using an
> >>> unsupported tool vs something that worked out of the box & was well
> tested?
> >>>
> >>> Dinesh
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>>
>

Re: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

Thank you for the feedback.  There are lot of advantages of doing this in 
Apache and you can read the thread to find more. The main one is to not divide 
the energy between different tools. 
Also we will not be reinventing the wheel as I think this project can still get 
donations along the way. 

> On Sep 30, 2018, at 05:31, Rahul Singh  wrote:
> 
> Perfection is the enemy of the good enough. All if not most informed open 
> source users understand that the tar they are downloading is “unsupported.”
> 
> Most of the blog posts people read or the documentation they have is in place 
> of tools. Open source software let alone Tooling even a nascent version comes 
> with a degree of uncertainty.
> 
> If the question is for me: I would rather use something that exists than 
> reinvent the wheel. The same way I’ll use “contrib” packages in any system 
> just to see if it works.
> 
> Example: While working on on a Solr / Kafka / Cassandra integration project 
> we must have used a few different “Kafka Connect” variations before settling 
> on a solution which was a combination of an existing sink connector and 
> created a source connector because what was out there “meh”.
> 
> If we had scoffed off “unsupported” packages we would have spent more time 
> making something than delivering value. Technology exists to serve business 
> and people’s lives not technology itself.
> 
> There is a level of discernment that comes with experience as to what works 
> and what doesn’t and what is good and what isn’t. The least we can do is help 
> the user community know the difference : as Apache does at a higher level.
> 
> 
> Rahul Singh
> Chief Executive Officer
> m 202.905.2818
> 
> Anant Corporation
> 1010 Wisconsin Ave NW, Suite 250
> Washington, D.C. 20007
> 
> We build and manage digital business technology platforms.
>> On Sep 29, 2018, 5:29 PM -0400, sankalp kohli , 
>> wrote:
>> Thanks Dinesh for looking at the tools and thanks Mick for listing them
>> down.
>> Based on Dinesh response, is it accurate to say that for bulk
>> functionality, we have evaluated the tools listed by the community? If
>> anything is missed we should discuss it as we want to make sure we looked
>> at all aspects before implementation starts.
>> 
>> On Sat, Sep 29, 2018 at 1:19 PM Dinesh Joshi 
>> wrote:
>> 
>>>> On Sep 29, 2018, at 12:31 PM, Rahul Singh 
>>> wrote:
>>>> 
>>>> All of Apache is a patchwork of tools. All of Open Source is a patchwork
>>> of tools. All of Linux is a patchwork of tools.
>>>> 
>>>> What works, works.
>>> 
>>> So there isn't a way to make it any better? You would prefer using an
>>> unsupported tool vs something that worked out of the box & was well tested?
>>> 
>>> Dinesh
>>> 
>>> 
>>> -
>>> 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: Proposing an Apache Cassandra Management process

[sankalp kohli]

Thanks Dinesh for looking at the tools and thanks Mick for listing them
down.
Based on Dinesh response, is it accurate to say that for bulk
functionality, we have evaluated the tools listed by the community? If
anything is missed we should discuss it as we want to make sure we looked
at all aspects before implementation starts.

On Sat, Sep 29, 2018 at 1:19 PM Dinesh Joshi 
wrote:

> > On Sep 29, 2018, at 12:31 PM, Rahul Singh 
> wrote:
> >
> > All of Apache is a patchwork of tools. All of Open Source is a patchwork
> of tools. All of Linux is a patchwork of tools.
> >
> > What works, works.
>
> So there isn't a way to make it any better? You would prefer using an
> unsupported tool vs something that worked out of the box & was well tested?
>
> Dinesh
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

This is not part of core database and a separate repo and so my impression is 
that this can continue to make progress. Also we can always make progress and 
not merge it till freeze is lifted. 

Open to ideas/suggestions if someone thinks otherwise. 

> On Sep 22, 2018, at 03:13, kurt greaves  wrote:
> 
> Is this something we're moving ahead with despite the feature freeze?
> 
> On Sat, 22 Sep 2018 at 08:32, dinesh.jo...@yahoo.com.INVALID
>  wrote:
> 
>> I have created a sub-task - CASSANDRA-14783. Could we get some feedback
>> before we begin implementing anything?
>> 
>> Dinesh
>> 
>>On Thursday, September 20, 2018, 11:22:33 PM PDT, Dinesh Joshi <
>> dinesh.jo...@yahoo.com.INVALID> wrote:
>> 
>> I have updated the doc with a short paragraph providing the
>> clarification. Sankalp's suggestion is already part of the doc. If there
>> aren't further objections could we move this discussion over to the jira
>> (CASSANDRA-14395)?
>> 
>> Dinesh
>> 
>>> On Sep 18, 2018, at 10:31 AM, sankalp kohli 
>> wrote:
>>> 
>>> How about we start with a few basic features in side car. How about
>> starting with this
>>> 1. Bulk nodetool commands: User can curl any sidecar and be able to run
>> a nodetool command in bulk across the cluster.
>>> 
>> :/bulk/nodetool/tablestats?arg0=keyspace_name.table_name=> required>
>>> 
>>> And later
>>> 2: Health checks.
>>> 
>>> On Thu, Sep 13, 2018 at 11:34 AM dinesh.jo...@yahoo.com.INVALID <
>> dinesh.jo...@yahoo.com.invalid> wrote:
>>> I will update the document to add that point. The document did not mean
>> to serve as a design or architectural document but rather something that
>> would spark a discussion on the idea.
>>> Dinesh
>>> 
>>>   On Thursday, September 13, 2018, 10:59:34 AM PDT, Jonathan Haddad <
>> j...@jonhaddad.com <mailto:j...@jonhaddad.com>> wrote:
>>> 
>>> Most of the discussion and work was done off the mailing list - there's
>> a
>>> big risk involved when folks disappear for months at a time and resurface
>>> with big pile of code plus an agenda that you failed to loop everyone in
>>> on. In addition, by your own words the design document didn't accurately
>>> describe what was being built.  I don't write this to try to argue about
>>> it, I just want to put some perspective for those of us that weren't part
>>> of this discussion on a weekly basis over the last several months.  Going
>>> forward let's keep things on the ML so we can avoid confusion and
>>> frustration for all parties.
>>> 
>>> With that said - I think Blake made a really good point here and it's
>>> helped me understand the scope of what's being built better.  Looking at
>> it
>>> from a different perspective it doesn't seem like there's as much overlap
>>> as I had initially thought.  There's the machinery that runs certain
>> tasks
>>> (what Joey has been working on) and the user facing side of exposing that
>>> information in management tool.
>>> 
>>> I do appreciate (and like) the idea of not trying to boil the ocean, and
>>> working on things incrementally.  Putting a thin layer on top of
>> Cassandra
>>> that can perform cluster wide tasks does give us an opportunity to move
>> in
>>> the direction of a general purpose user-facing admin tool without
>>> committing to trying to write the full stack all at once (or even make
>>> decisions on it now).  We do need a sensible way of doing rolling
>> restarts
>>> / scrubs / scheduling and Reaper wasn't built for that, and even though
>> we
>>> can add it I'm not sure if it's the best mechanism for the long term.
>>> 
>>> So if your goal is to add maturity to the project by making cluster wide
>>> tasks easier by providing a framework to build on top of, I'm in favor of
>>> that and I don't see it as antithetical to what I had in mind with
>> Reaper.
>>> Rather, the two are more complementary than I had originally realized.
>>> 
>>> Jon
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Sep 13, 2018 at 10:39 AM dinesh.jo...@yahoo.com.INVALID
>>> mailto:dinesh.jo...@yahoo.com>.invalid> wrote:
>>> 
>>>> I have a few clarifications -
>>>> The scope of the management process is not to simply run repair
>>>> scheduling. Repair scheduling is one of the many features we could
>>>> implement or adopt 

Re: [DISCUSS] changing default token behavior for 4.0

[Sankalp Kohli]

Putting it on JIRA is to make sure someone is assigned to it and it is tracked. 
Changes should be discussed over ML like you are saying. 

On Sep 21, 2018, at 21:02, Jonathan Haddad  wrote:

>> We should create a JIRA to find what other defaults we need revisit.
> 
> Changing a default is a pretty big deal, I think we should discuss any
> changes to defaults here on the ML before moving it into JIRA.  It's nice
> to get a bit more discussion around the change than what happens in JIRA.
> 
> We (TLP) did some testing on 4 tokens and found it to work surprisingly
> well.   It wasn't particularly formal, but we verified the load stays
> pretty even with only 4 tokens as we added nodes to the cluster.  Higher
> token count hurts availability by increasing the number of nodes any given
> node is a neighbor with, meaning any 2 nodes that fail have an increased
> chance of downtime when using QUORUM.  In addition, with the recent
> streaming optimization it seems the token counts will give a greater chance
> of a node streaming entire sstables (with LCS), meaning we'll do a better
> job with node density out of the box.
> 
> Next week I can try to put together something a little more convincing.
> Weekend time.
> 
> Jon
> 
> 
> On Fri, Sep 21, 2018 at 8:45 PM sankalp kohli 
> wrote:
> 
>> +1 to lowering it.
>> Thanks Jon for starting this.We should create a JIRA to find what other
>> defaults we need revisit. (Please keep this discussion for "default token"
>> only.  )
>> 
>>> On Fri, Sep 21, 2018 at 8:26 PM Jeff Jirsa  wrote:
>>> 
>>> Also agree it should be lowered, but definitely not to 1, and probably
>>> something closer to 32 than 4.
>>> 
>>> --
>>> Jeff Jirsa
>>> 
>>> 
>>>> On Sep 21, 2018, at 8:24 PM, Jeremy Hanna 
>>> wrote:
>>>> 
>>>> I agree that it should be lowered. What I’ve seen debated a bit in the
>>> past is the number but I don’t think anyone thinks that it should remain
>>> 256.
>>>> 
>>>>> On Sep 21, 2018, at 7:05 PM, Jonathan Haddad 
>> wrote:
>>>>> 
>>>>> One thing that's really, really bothered me for a while is how we
>>> default
>>>>> to 256 tokens still.  There's no experienced operator that leaves it
>> as
>>> is
>>>>> at this point, meaning the only people using 256 are the poor folks
>> that
>>>>> just got started using C*.  I've worked with over a hundred clusters
>> in
>>> the
>>>>> last couple years, and I think I only worked with one that had lowered
>>> it
>>>>> to something else.
>>>>> 
>>>>> I think it's time we changed the default to 4 (or 8, up for debate).
>>>>> 
>>>>> To improve the behavior, we need to change a couple other things.  The
>>>>> allocate_tokens_for_keyspace setting is... odd.  It requires you have
>> a
>>>>> keyspace already created, which doesn't help on new clusters.  What
>> I'd
>>>>> like to do is add a new setting, allocate_tokens_for_rf, and set it to
>>> 3 by
>>>>> default.
>>>>> 
>>>>> To handle clusters that are already using 256 tokens, we could prevent
>>> the
>>>>> new node from joining unless a -D flag is set to explicitly allow
>>>>> imbalanced tokens.
>>>>> 
>>>>> We've agreed to a trunk freeze, but I feel like this is important
>> enough
>>>>> (and pretty trivial) to do now.  I'd also personally characterize this
>>> as a
>>>>> bug fix since 256 is horribly broken when the cluster gets to any
>>>>> reasonable size, but maybe I'm alone there.
>>>>> 
>>>>> I honestly can't think of a use case where random tokens is a good
>>> choice
>>>>> anymore, so I'd be fine / ecstatic with removing it completely and
>>>>> requiring either allocate_tokens_for_keyspace (for existing clusters)
>>>>> or allocate_tokens_for_rf
>>>>> to be set.
>>>>> 
>>>>> Thoughts?  Objections?
>>>>> --
>>>>> Jon Haddad
>>>>> http://www.rustyrazorblade.com
>>>>> twitter: rustyrazorblade
>>>> 
>>>> -
>>>> 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

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

Re: [DISCUSS] changing default token behavior for 4.0

[sankalp kohli]

+1 to lowering it.
Thanks Jon for starting this.We should create a JIRA to find what other
defaults we need revisit. (Please keep this discussion for "default token"
only.  )

On Fri, Sep 21, 2018 at 8:26 PM Jeff Jirsa  wrote:

> Also agree it should be lowered, but definitely not to 1, and probably
> something closer to 32 than 4.
>
> --
> Jeff Jirsa
>
>
> > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna 
> wrote:
> >
> > I agree that it should be lowered. What I’ve seen debated a bit in the
> past is the number but I don’t think anyone thinks that it should remain
> 256.
> >
> >> On Sep 21, 2018, at 7:05 PM, Jonathan Haddad  wrote:
> >>
> >> One thing that's really, really bothered me for a while is how we
> default
> >> to 256 tokens still.  There's no experienced operator that leaves it as
> is
> >> at this point, meaning the only people using 256 are the poor folks that
> >> just got started using C*.  I've worked with over a hundred clusters in
> the
> >> last couple years, and I think I only worked with one that had lowered
> it
> >> to something else.
> >>
> >> I think it's time we changed the default to 4 (or 8, up for debate).
> >>
> >> To improve the behavior, we need to change a couple other things.  The
> >> allocate_tokens_for_keyspace setting is... odd.  It requires you have a
> >> keyspace already created, which doesn't help on new clusters.  What I'd
> >> like to do is add a new setting, allocate_tokens_for_rf, and set it to
> 3 by
> >> default.
> >>
> >> To handle clusters that are already using 256 tokens, we could prevent
> the
> >> new node from joining unless a -D flag is set to explicitly allow
> >> imbalanced tokens.
> >>
> >> We've agreed to a trunk freeze, but I feel like this is important enough
> >> (and pretty trivial) to do now.  I'd also personally characterize this
> as a
> >> bug fix since 256 is horribly broken when the cluster gets to any
> >> reasonable size, but maybe I'm alone there.
> >>
> >> I honestly can't think of a use case where random tokens is a good
> choice
> >> anymore, so I'd be fine / ecstatic with removing it completely and
> >> requiring either allocate_tokens_for_keyspace (for existing clusters)
> >> or allocate_tokens_for_rf
> >> to be set.
> >>
> >> Thoughts?  Objections?
> >> --
> >> Jon Haddad
> >> http://www.rustyrazorblade.com
> >> twitter: rustyrazorblade
> >
> > -
> > 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: Proposing an Apache Cassandra Management process

[sankalp kohli]

How about we start with a few basic features in side car. How about
starting with this
1. Bulk nodetool commands: User can curl any sidecar and be able to run a
nodetool command in bulk across the cluster.
:/bulk/nodetool/tablestats?arg0=keyspace_name.table_name=

And later
2: Health checks.

On Thu, Sep 13, 2018 at 11:34 AM dinesh.jo...@yahoo.com.INVALID
 wrote:

> I will update the document to add that point. The document did not mean to
> serve as a design or architectural document but rather something that would
> spark a discussion on the idea.
> Dinesh
>
> On Thursday, September 13, 2018, 10:59:34 AM PDT, Jonathan Haddad <
> j...@jonhaddad.com> wrote:
>
>  Most of the discussion and work was done off the mailing list - there's a
> big risk involved when folks disappear for months at a time and resurface
> with big pile of code plus an agenda that you failed to loop everyone in
> on. In addition, by your own words the design document didn't accurately
> describe what was being built.  I don't write this to try to argue about
> it, I just want to put some perspective for those of us that weren't part
> of this discussion on a weekly basis over the last several months.  Going
> forward let's keep things on the ML so we can avoid confusion and
> frustration for all parties.
>
> With that said - I think Blake made a really good point here and it's
> helped me understand the scope of what's being built better.  Looking at it
> from a different perspective it doesn't seem like there's as much overlap
> as I had initially thought.  There's the machinery that runs certain tasks
> (what Joey has been working on) and the user facing side of exposing that
> information in management tool.
>
> I do appreciate (and like) the idea of not trying to boil the ocean, and
> working on things incrementally.  Putting a thin layer on top of Cassandra
> that can perform cluster wide tasks does give us an opportunity to move in
> the direction of a general purpose user-facing admin tool without
> committing to trying to write the full stack all at once (or even make
> decisions on it now).  We do need a sensible way of doing rolling restarts
> / scrubs / scheduling and Reaper wasn't built for that, and even though we
> can add it I'm not sure if it's the best mechanism for the long term.
>
> So if your goal is to add maturity to the project by making cluster wide
> tasks easier by providing a framework to build on top of, I'm in favor of
> that and I don't see it as antithetical to what I had in mind with Reaper.
> Rather, the two are more complementary than I had originally realized.
>
> Jon
>
>
>
>
> On Thu, Sep 13, 2018 at 10:39 AM dinesh.jo...@yahoo.com.INVALID
>  wrote:
>
> > I have a few clarifications -
> > The scope of the management process is not to simply run repair
> > scheduling. Repair scheduling is one of the many features we could
> > implement or adopt from existing sources. So could we please split the
> > Management Process discussion and the repair scheduling?
> > After re-reading the management process proposal, I see we missed to
> > communicate a basic idea in the document. We wanted to take a pluggable
> > approach to various activities that the management process could perform.
> > This could accommodate different implementations of common activities
> such
> > as repair. The management process would provide the basic framework and
> it
> > would have default implementations for some of the basic activities. This
> > would allow for speedier iteration cycles and keep things extensible.
> > Turning to some questions that Jon and others have raised, when I +1, my
> > intention is to fully contribute and stay with this community. That said,
> > things feel rushed for some but for me it feels like analysis paralysis.
> > We're looking for actionable feedback and to discuss the management
> process
> > _not_ repair scheduling solutions.
> > Thanks,
> > Dinesh
> >
> >
> >
> > On Sep 12, 2018, at 6:24 PM, sankalp kohli 
> wrote:
> > Here is a list of open discussion points from the voting thread. I think
> > some are already answered but I will still gather these questions here.
> >
> > From several people:
> > 1. Vote is rushed and we need more time for discussion.
> >
> > From Sylvain
> > 2. About the voting process...I think that was addressed by Jeff Jirsa
> and
> > deserves a separate thread as it is not directly related to this thread.
> > 3. Does the project need a side car.
> >
> > From Jonathan Haddad
> > 4. Are people doing +1 willing to contribute
> >
> > From Jonathan Ellis
> > 5. List of feat

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

[Sankalp Kohli]

The link to the document is available in the other thread. Comparisons are 
available in other thread as well. 

> On Sep 12, 2018, at 16:29, Mick Semb Wever  wrote:
> 
> 
>> I am hoping all the folks who are saying we should not vote will drive the
>> other thread.  Also note that there is consensus about doing a side car but
>> no consensus on which approach to take. I hope not deciding which approach
>> is not a poison pill for side car!!
> 
> 
> Call me pedantic, but I saw the consensus as favouring a side-car over 
> something in tree. That's not a consensus on doing a side-car, as that was 
> not an option on offer.
> 
> There's certainly interest in a side-car that warrants documenting further on 
> comparisons and investigations, IMHO.
> 
> -
> 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

[sankalp kohli]

I am hoping all the folks who are saying we should not vote will drive the
other thread.  Also note that there is consensus about doing a side car but
no consensus on which approach to take. I hope not deciding which approach
is not a poison pill for side car!!



On Wed, Sep 12, 2018 at 4:11 PM Mick Semb Wever  wrote:

>
> > But I'd like to see a serious investigation of the options -- feature
> set,
> > maturity, maintainer availability, etc -- before making a decision.  This
> > will take some time, but this is a place where "measure twice, cut once"
> > seems like the right approach.
>
>
> This^ 100%.
>
> I dislike the idea of a vote altogether:
> https://www.apache.org/foundation/voting.html#reasons-for-votes
>
> Discussion should resolve things, accepting something into the community
> that divides (isn't built on consensus) seems an unhealthy thing to do to
> the community. Jonathan's suggestion gives us something productive to do to
> get to consensus.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

(Using this thread and not the vote thread intentionally)
For folks talking about vote being rushed. I would use the email from
Joseph to show this is not rushed. There was no email on this thread for 4
months until I pinged.


Dec 2016: Vinay worked with Jon and Alex to try to collaborate on Reaper to
come up with design goals for a repair scheduler that could work at Netflix
scale.

~Feb 2017: Netflix believes that the fundamental design gaps prevented us
from using Reaper as it relies heavily on remote JMX connections and
central coordination.

Sep. 2017: Vinay gives a lightning talk at NGCC about a highly available
and distributed repair scheduling sidecar/tool. He is encouraged by
multiple committers to build repair scheduling into the daemon itself and
not as a sidecar so the database is truly eventually consistent.

~Jun. 2017 - Feb. 2018: Based on internal need and the positive feedback at
NGCC, Vinay and myself prototype the distributed repair scheduler within
Priam and roll it out at Netflix scale.

Mar. 2018: I open a Jira (CASSANDRA-14346) along with a detailed 20 page
design document for adding repair scheduling to the daemon itself and open
the design up for feedback from the community. We get feedback from Alex,
Blake, Nate, Stefan, and Mick. As far as I know there were zero proposals
to contribute Reaper at this point. We hear the consensus that the
community would prefer repair scheduling in a separate distributed sidecar
rather than in the daemon itself and we re-work the design to match this
consensus, re-aligning with our original proposal at NGCC.

Apr 2018: Blake brings the discussion of repair scheduling to the dev list (
https://lists.apache.org/thread.html/760fbef677f27aa5c2ab4c375c7efeb81304fea428deff986ba1c2eb@%3Cdev.cassandra.apache.org%3E
).
Many community members give positive feedback that we should solve it as
part of Cassandra and there is still no mention of contributing Reaper at
this point. The last message is my attempted summary giving context on how
we want to take the best of all the sidecars (OpsCenter, Priam, Reaper) and
ship them with Cassandra.

Apr. 2018: Dinesh opens CASSANDRA-14395 along with a public design document
for gathering feedback on a general management sidecar. Sankalp and Dinesh
encourage Vinay and myself to kickstart that sidecar using the repair
scheduler patch

Apr 2018: Dinesh reaches out to the dev list (
https://lists.apache.org/thread.html/a098341efd8f344494bcd2761dba5125e971b59b1dd54f282ffda253@%3Cdev.cassandra.apache.org%3E
)
about the general management process to gain further feedback. All feedback
remains positive as it is a potential place for multiple community members
to contribute their various sidecar functionality.

May-Jul 2017: Vinay and I work on creating a basic sidecar for running the
repair scheduler based on the feedback from the community in
CASSANDRA-14346 and CASSANDRA-14395

Jun 2018: I bump CASSANDRA-14346 indicating we're still working on this,
nobody objects

Jul 2018: Sankalp asks on the dev list if anyone has feature Jiras anyone
needs review for before 4.0, I mention again that we've nearly got the
basic sidecar and repair scheduling work done and will need help with
review. No one responds.

Aug 2018: We submit a patch that brings a basic distributed sidecar and
robust distributed repair to Cassandra itself. Dinesh mentions that he will
try to review. Now folks appear concerned about it being in tree and
instead maybe it should go in a different repo all together. I don't think
we have consensus on the repo choice yet.

On Sun, Sep 9, 2018 at 9:13 AM sankalp kohli  wrote:

> I agree with Jon and I think folks who are talking about tech debts in
> Reaper should elaborate with examples about these tech debts. Can we be
> more precise and list them down? I see it spread out over this long email
> thread!!
>
> On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims  wrote:
>
>> A big one to add to your list there, IMO as a user:
>> * API for determining detailed repair state (and history?).  Essentially,
>> something beyond just "Is some sort of repair running?" so that tools like
>> Reaper can parallelize better.
>>
>> On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski 
>> wrote:
>>
>> > Does it have to be a single project with functionality provided by
>> > multiple plugins? Designing a plugin API at this point seems to be a bit
>> > early and comes with additional complexity around managing plugins in
>> > general.
>> >
>> > I was more thinking into the direction of: "what can we do to enable
>> > people to create any kind of side car or tooling solution?". Thinks
>> like:
>> >
>> > Common cluster discovery and management API
>> > * Detect local Cassandra processes
>> > * Discover and receive events on cluster topology
>&

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

[sankalp kohli]

Hi Joey,
 The intention of this vote is to do what you are saying. We
want to see movement on this and not drag it for months. I am happy to drag
it for few more weeks if thats is what we agree on.

Regarding evaluating different options, if we decide on option a, we can
always do that like I wrote in the first email.

Thanks,
Sankalp

On Wed, Sep 12, 2018 at 2:51 PM Joseph Lynch  wrote:

> > I'd like to ask those of you that are +1'ing, are you willing to
> contribute
> > or are you just voting we start an admin tool from scratch because you
> > think it'll somehow produce a perfect codebase?
>
> Roopa, Vinay, Sumanth and I are voting as community members (and a
> sizeable user) and our willingness to contribute should be clear from
> the close to six months of engineering work we've invested presenting,
> prototyping, deploying, refactoring, designing, more discussing, and
> producing the patch on CASSANDRA-14346 that then happened to revive
> the April maintenance process discussion as we needed something to put
> the scheduler in. Dinesh and other Apple contributors were the ones
> who floated the idea in the first place and we just tried to help that
> proposal actually happen. Clearly we have to re-work that patch as it
> seems we have turned the management process discussion into a
> discussion about repair which was not the point and we are already in
> the process of converting the patch into a pluggable maintenance
> execution engine for any scheduled task.
>
> I didn't understand this vote as a vote on on releasing the yet to
> exist maintenance process ... I thought we're trying to get consensus
> on if we should invest in a fresh repo and build to the design (when
> we have achieved the design there can be an actual release vote) or
> start from an existing project which has made existing choices and
> trying to refactor towards the scope/desires.
>
> -Joey
>
> -
> 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

[sankalp kohli]

Congrats on the newborn. I am assuming others also have personal things
going on!!

Also discussion thread is ongoing from April and not last 4 days. If enough
people think it is rushed, we can always revote.

On Wed, Sep 12, 2018 at 2:24 PM Joshua McKenzie 
wrote:

> That was four days ago, and I have a newborn at home. Not a lot of time for
> people to respond that have other things going on in life. :)
>
> On Wed, Sep 12, 2018 at 5:13 PM sankalp kohli 
> wrote:
>
> > If you think vote is being forced, why not reply to my email on another
> > thread when I said we should vote? Why was the thread dead for months and
> > someone comes back with a contribution and then people starts talking?
> >
> > I would have happily waited for few more days!!
> >
> >
> >
> > On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
> > wrote:
> >
> > > >
> > > >  It is important we make progress as we have been discussing this
> since
> > > > April!!
> > >
> > >
> > > The discussion was making progress. Just because you want things to
> > happen
> > > faster is no reason to force an early vote.
> > >
> > > On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
> > > wrote:
> > >
> > > > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > > > important we make progress as we have been discussing this since
> > April!!
> > > >
> > > > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli <
> kohlisank...@gmail.com>
> > > > wrote:
> > > >
> > > > > The last email on the thread was 3 days ago and I made it clear
> days
> > > back
> > > > > that we should vote on it to make progress. Without this vote, I am
> > not
> > > > > sure we will make progress.
> > > > > Many people want to contribute on this and hence we are voting so
> we
> > > can
> > > > > make progress.
> > > > >
> > > > > My vote is d
> > > > >
> > > > >
> > > > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  >
> > > > wrote:
> > > > >
> > > > >> This voting process feels a bit rushed and frankly not well
> thought
> > > out.
> > > > >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> > > > address
> > > > >> at all, the discussion in the other threads seemed to be ongoing.
> > The
> > > > >> last
> > > > >> email you wrote on one of them was asking for additional feedback,
> > > that
> > > > >> indicates the discussion is still open.
> > > > >>
> > > > >> Out of principal I vote for none of the options (inaction).
> You're
> > > > >> deliberately trying to ram *something* through, and that's not how
> > > this
> > > > is
> > > > >> supposed to work.
> > > > >>
> > > > >> For those of you unfamiliar with the process - please read
> > > > >> https://www.apache.org/foundation/voting.html.
> > > > >>
> > > > >> I'd like to ask those of you that are +1'ing, are you willing to
> > > > >> contribute
> > > > >> or are you just voting we start an admin tool from scratch because
> > you
> > > > >> think it'll somehow produce a perfect codebase?
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> > > kohlisank...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi Sylvain,
> > > > >> > I would appreciate if we can give feedback on
> the
> > > > >> > discussion threads and not wait for vote threads. I made it
> clear
> > in
> > > > the
> > > > >> > discussion thread that we will start a vote!!
> > > > >> > Thanks,
> > > > >> > Sankalp
> > > > >> >
> > > > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa 
> > > wrote:
> > > > >> >
> > > > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > > > lebre...@gmail.com
> > > > >> >
> > > > &

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

[sankalp kohli]

If you think vote is being forced, why not reply to my email on another
thread when I said we should vote? Why was the thread dead for months and
someone comes back with a contribution and then people starts talking?

I would have happily waited for few more days!!



On Wed, Sep 12, 2018 at 2:09 PM Joshua McKenzie 
wrote:

> >
> >  It is important we make progress as we have been discussing this since
> > April!!
>
>
> The discussion was making progress. Just because you want things to happen
> faster is no reason to force an early vote.
>
> On Wed, Sep 12, 2018 at 5:04 PM sankalp kohli 
> wrote:
>
> > Also my vote is same as Jeff. d but would slightly prefer b. It is
> > important we make progress as we have been discussing this since April!!
> >
> > On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
> > wrote:
> >
> > > The last email on the thread was 3 days ago and I made it clear days
> back
> > > that we should vote on it to make progress. Without this vote, I am not
> > > sure we will make progress.
> > > Many people want to contribute on this and hence we are voting so we
> can
> > > make progress.
> > >
> > > My vote is d
> > >
> > >
> > > On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad 
> > wrote:
> > >
> > >> This voting process feels a bit rushed and frankly not well thought
> out.
> > >> In addition to Sylvain's valid points, which you (Sankalp) didn't
> > address
> > >> at all, the discussion in the other threads seemed to be ongoing.  The
> > >> last
> > >> email you wrote on one of them was asking for additional feedback,
> that
> > >> indicates the discussion is still open.
> > >>
> > >> Out of principal I vote for none of the options (inaction).  You're
> > >> deliberately trying to ram *something* through, and that's not how
> this
> > is
> > >> supposed to work.
> > >>
> > >> For those of you unfamiliar with the process - please read
> > >> https://www.apache.org/foundation/voting.html.
> > >>
> > >> I'd like to ask those of you that are +1'ing, are you willing to
> > >> contribute
> > >> or are you just voting we start an admin tool from scratch because you
> > >> think it'll somehow produce a perfect codebase?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <
> kohlisank...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi Sylvain,
> > >> > I would appreciate if we can give feedback on the
> > >> > discussion threads and not wait for vote threads. I made it clear in
> > the
> > >> > discussion thread that we will start a vote!!
> > >> > Thanks,
> > >> > Sankalp
> > >> >
> > >> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa 
> wrote:
> > >> >
> > >> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <
> > lebre...@gmail.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > That's probably a stupid question, and excuse me if it is, but
> > what
> > >> > does
> > >> > > > those votes on the dev mailing list even mean?
> > >> > > >
> > >> > > > How do you count votes at the end? Just by counting all votes
> > cast,
> > >> > > > irregardless of whomever cast it? Or are we intending to only
> > count
> > >> PMC
> > >> > > > members, or maybe committers votes?
> > >> > > >
> > >> > >
> > >> > > I believe the intent is to try to see if there exists consensus.
> > >> > > Ultimately, PMC is going to matter more than random email
> addresses
> > >> from
> > >> > > people nobody recognizes. This should be in public, though, not
> > >> private,
> > >> > so
> > >> > > seeing what feedback is beyond the PMC is useful (primarily
> because
> > it
> > >> > will
> > >> > > matter when it comes time to extend and maintain it - if people
> > >> strongly
> > >> > > prefer one or the other, then maintenance is going to be a
> problem).
> > >> > >
> > >> > > If there's 100 random 

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

[sankalp kohli]

Also my vote is same as Jeff. d but would slightly prefer b. It is
important we make progress as we have been discussing this since April!!

On Wed, Sep 12, 2018 at 1:52 PM sankalp kohli 
wrote:

> The last email on the thread was 3 days ago and I made it clear days back
> that we should vote on it to make progress. Without this vote, I am not
> sure we will make progress.
> Many people want to contribute on this and hence we are voting so we can
> make progress.
>
> My vote is d
>
>
> On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  wrote:
>
>> This voting process feels a bit rushed and frankly not well thought out.
>> In addition to Sylvain's valid points, which you (Sankalp) didn't address
>> at all, the discussion in the other threads seemed to be ongoing.  The
>> last
>> email you wrote on one of them was asking for additional feedback, that
>> indicates the discussion is still open.
>>
>> Out of principal I vote for none of the options (inaction).  You're
>> deliberately trying to ram *something* through, and that's not how this is
>> supposed to work.
>>
>> For those of you unfamiliar with the process - please read
>> https://www.apache.org/foundation/voting.html.
>>
>> I'd like to ask those of you that are +1'ing, are you willing to
>> contribute
>> or are you just voting we start an admin tool from scratch because you
>> think it'll somehow produce a perfect codebase?
>>
>>
>>
>>
>>
>> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
>> wrote:
>>
>> > Hi Sylvain,
>> > I would appreciate if we can give feedback on the
>> > discussion threads and not wait for vote threads. I made it clear in the
>> > discussion thread that we will start a vote!!
>> > Thanks,
>> > Sankalp
>> >
>> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
>> >
>> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne > >
>> > > wrote:
>> > >
>> > > > That's probably a stupid question, and excuse me if it is, but what
>> > does
>> > > > those votes on the dev mailing list even mean?
>> > > >
>> > > > How do you count votes at the end? Just by counting all votes cast,
>> > > > irregardless of whomever cast it? Or are we intending to only count
>> PMC
>> > > > members, or maybe committers votes?
>> > > >
>> > >
>> > > I believe the intent is to try to see if there exists consensus.
>> > > Ultimately, PMC is going to matter more than random email addresses
>> from
>> > > people nobody recognizes. This should be in public, though, not
>> private,
>> > so
>> > > seeing what feedback is beyond the PMC is useful (primarily because it
>> > will
>> > > matter when it comes time to extend and maintain it - if people
>> strongly
>> > > prefer one or the other, then maintenance is going to be a problem).
>> > >
>> > > If there's 100 random non-contributor votes for one option and 20 pmc
>> > votes
>> > > for another options, I think the real answer will be "we don't have
>> > > consensus, and either we don't do it, or we do it the way the PMC
>> thinks
>> > is
>> > > best", for all of the reasons you describe in the paragraphs below.
>> > >
>> > >
>> > > > If the former, that is a bit weird to me because we simply don't
>> know
>> > who
>> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
>> could
>> > > > easily create 10 email addresses to vote 10 times (and sure, you
>> could
>> > > > invoke trust, and I'm not entirely against trust in general, but
>> it's
>> > the
>> > > > internet...) and 2) this kind of decision will have non-trivial
>> > > > consequences for the project, particularly on those that maintain
>> it,
>> > so
>> > > I
>> > > > admit I'm not entirely comfortable with "anyone's voice has the same
>> > > > weight".
>> > > > If the latter, then this makes more sense to me (why are we even
>> > > bothering
>> > > > voting PMC members in if it's not to handle these kinds of
>> decisions,
>> > > which
>> > > > are very "project management" related), but we should be very clear
>> > about
>> > > > this from the get go (we could s

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

[sankalp kohli]

The last email on the thread was 3 days ago and I made it clear days back
that we should vote on it to make progress. Without this vote, I am not
sure we will make progress.
Many people want to contribute on this and hence we are voting so we can
make progress.

My vote is d


On Wed, Sep 12, 2018 at 1:36 PM Jonathan Haddad  wrote:

> This voting process feels a bit rushed and frankly not well thought out.
> In addition to Sylvain's valid points, which you (Sankalp) didn't address
> at all, the discussion in the other threads seemed to be ongoing.  The last
> email you wrote on one of them was asking for additional feedback, that
> indicates the discussion is still open.
>
> Out of principal I vote for none of the options (inaction).  You're
> deliberately trying to ram *something* through, and that's not how this is
> supposed to work.
>
> For those of you unfamiliar with the process - please read
> https://www.apache.org/foundation/voting.html.
>
> I'd like to ask those of you that are +1'ing, are you willing to contribute
> or are you just voting we start an admin tool from scratch because you
> think it'll somehow produce a perfect codebase?
>
>
>
>
>
> On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli 
> wrote:
>
> > Hi Sylvain,
> > I would appreciate if we can give feedback on the
> > discussion threads and not wait for vote threads. I made it clear in the
> > discussion thread that we will start a vote!!
> > Thanks,
> > Sankalp
> >
> > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:
> >
> > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> > > wrote:
> > >
> > > > That's probably a stupid question, and excuse me if it is, but what
> > does
> > > > those votes on the dev mailing list even mean?
> > > >
> > > > How do you count votes at the end? Just by counting all votes cast,
> > > > irregardless of whomever cast it? Or are we intending to only count
> PMC
> > > > members, or maybe committers votes?
> > > >
> > >
> > > I believe the intent is to try to see if there exists consensus.
> > > Ultimately, PMC is going to matter more than random email addresses
> from
> > > people nobody recognizes. This should be in public, though, not
> private,
> > so
> > > seeing what feedback is beyond the PMC is useful (primarily because it
> > will
> > > matter when it comes time to extend and maintain it - if people
> strongly
> > > prefer one or the other, then maintenance is going to be a problem).
> > >
> > > If there's 100 random non-contributor votes for one option and 20 pmc
> > votes
> > > for another options, I think the real answer will be "we don't have
> > > consensus, and either we don't do it, or we do it the way the PMC
> thinks
> > is
> > > best", for all of the reasons you describe in the paragraphs below.
> > >
> > >
> > > > If the former, that is a bit weird to me because we simply don't know
> > who
> > > > votes. And I don't mean to be rude towards anyone, but 1) someone
> could
> > > > easily create 10 email addresses to vote 10 times (and sure, you
> could
> > > > invoke trust, and I'm not entirely against trust in general, but it's
> > the
> > > > internet...) and 2) this kind of decision will have non-trivial
> > > > consequences for the project, particularly on those that maintain it,
> > so
> > > I
> > > > admit I'm not entirely comfortable with "anyone's voice has the same
> > > > weight".
> > > > If the latter, then this makes more sense to me (why are we even
> > > bothering
> > > > voting PMC members in if it's not to handle these kinds of decisions,
> > > which
> > > > are very "project management" related), but we should be very clear
> > about
> > > > this from the get go (we could still use the dev list for
> transparency
> > > > sake, that I don't mind)? We should probably also have some deadline
> to
> > > the
> > > > vote, one that isn't too short.
> > > >
> > >
> > > Like releases, I think PMC votes count
> > >
> > >
> > > >
> > > > Anyway, fwiw, my opinion on this vote is not far from the one on the
> > > golang
> > > > driver acceptance vote (for which my remark above also apply btw): no
> > yet
> > > > 100% convinced adding more pieces and scope to the project is what
> the
> > > > project needs just right now, but not strongly opposed if people
> really
> > > > wants this (and this one makes more sense to me than the golang
> driver
> > > > actually). But if I'm to pick between a) and b), I'm leaning b).
> > > >
> > >
> > > FWIW, two of the main reasons I'm in favor is as a way to lower barrier
> > to
> > > entry to both using the software AND contributing to the project, so I
> > > think your points are valid (both on gocql thread and on this note
> > above),
> > > but I think that's also part of why we should be encouraging both.
> > >
> > > - Jeff
> > >
> >
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

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

[sankalp kohli]

Hi Sylvain,
I would appreciate if we can give feedback on the
discussion threads and not wait for vote threads. I made it clear in the
discussion thread that we will start a vote!!
Thanks,
Sankalp

On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa  wrote:

> On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne 
> wrote:
>
> > That's probably a stupid question, and excuse me if it is, but what does
> > those votes on the dev mailing list even mean?
> >
> > How do you count votes at the end? Just by counting all votes cast,
> > irregardless of whomever cast it? Or are we intending to only count PMC
> > members, or maybe committers votes?
> >
>
> I believe the intent is to try to see if there exists consensus.
> Ultimately, PMC is going to matter more than random email addresses from
> people nobody recognizes. This should be in public, though, not private, so
> seeing what feedback is beyond the PMC is useful (primarily because it will
> matter when it comes time to extend and maintain it - if people strongly
> prefer one or the other, then maintenance is going to be a problem).
>
> If there's 100 random non-contributor votes for one option and 20 pmc votes
> for another options, I think the real answer will be "we don't have
> consensus, and either we don't do it, or we do it the way the PMC thinks is
> best", for all of the reasons you describe in the paragraphs below.
>
>
> > If the former, that is a bit weird to me because we simply don't know who
> > votes. And I don't mean to be rude towards anyone, but 1) someone could
> > easily create 10 email addresses to vote 10 times (and sure, you could
> > invoke trust, and I'm not entirely against trust in general, but it's the
> > internet...) and 2) this kind of decision will have non-trivial
> > consequences for the project, particularly on those that maintain it, so
> I
> > admit I'm not entirely comfortable with "anyone's voice has the same
> > weight".
> > If the latter, then this makes more sense to me (why are we even
> bothering
> > voting PMC members in if it's not to handle these kinds of decisions,
> which
> > are very "project management" related), but we should be very clear about
> > this from the get go (we could still use the dev list for transparency
> > sake, that I don't mind)? We should probably also have some deadline to
> the
> > vote, one that isn't too short.
> >
>
> Like releases, I think PMC votes count
>
>
> >
> > Anyway, fwiw, my opinion on this vote is not far from the one on the
> golang
> > driver acceptance vote (for which my remark above also apply btw): no yet
> > 100% convinced adding more pieces and scope to the project is what the
> > project needs just right now, but not strongly opposed if people really
> > wants this (and this one makes more sense to me than the golang driver
> > actually). But if I'm to pick between a) and b), I'm leaning b).
> >
>
> FWIW, two of the main reasons I'm in favor is as a way to lower barrier to
> entry to both using the software AND contributing to the project, so I
> think your points are valid (both on gocql thread and on this note above),
> but I think that's also part of why we should be encouraging both.
>
> - Jeff
>

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

[sankalp kohli]

+1

On Wed, 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://incubator.apache.org/guides/ip_clearance.html
>
> Pending the outcome of this vote, we will create the JIRA issues for
> tracking and after we go through the process, and discuss adding
> committers in a separate thread (we need to do this atomically anyway
> per general ASF committer adding processes).
>
> Thanks,
> -Nate
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [Discuss] Accept GoCQL driver donation

[sankalp kohli]

Great..please start the vote to get consensus.

On Wed, Sep 12, 2018 at 8:06 AM Nate McCall  wrote:

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

[VOTE] Development Approach for Apache Cassandra Management process

[sankalp kohli]

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: [Discuss] Accept GoCQL driver donation

[sankalp kohli]

Hi Nate,
Looks like we had a lot of discussion here and everyone seems
to be in favor. What is the next step? A vote?
Thanks,
Sankalp

On Fri, Aug 31, 2018 at 10:48 PM Alex Lourie  wrote:

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

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

I agree with Jon and I think folks who are talking about tech debts in
Reaper should elaborate with examples about these tech debts. Can we be
more precise and list them down? I see it spread out over this long email
thread!!

On Sun, Sep 9, 2018 at 6:29 AM Elliott Sims  wrote:

> A big one to add to your list there, IMO as a user:
> * API for determining detailed repair state (and history?).  Essentially,
> something beyond just "Is some sort of repair running?" so that tools like
> Reaper can parallelize better.
>
> On Sun, Sep 9, 2018 at 8:30 AM, Stefan Podkowinski 
> wrote:
>
> > Does it have to be a single project with functionality provided by
> > multiple plugins? Designing a plugin API at this point seems to be a bit
> > early and comes with additional complexity around managing plugins in
> > general.
> >
> > I was more thinking into the direction of: "what can we do to enable
> > people to create any kind of side car or tooling solution?". Thinks like:
> >
> > Common cluster discovery and management API
> > * Detect local Cassandra processes
> > * Discover and receive events on cluster topology
> > * Get assigned tokens for nodes
> > * Read node configuration
> > * Health checks (as already proposed)
> >
> > Any side cars should be easy to install on nodes that already run
> Cassandra
> > * Scripts for packaging (tar, deb, rpm)
> > * Templates for systemd support, optionally with auto-startup dependency
> > on the Cassandra main process
> >
> > Integration testing
> > * Provide basic testing framework for mocking cluster state and messages
> >
> > Support for other languages / avoid having to use JMX
> > * JMX bridge (HTTP? gRPC?, already implemented in #14346?)
> >
> > Obviously the whole side car discussion is not moving into a direction
> > everyone's happy with. Would it be an option to take a step back and
> > start implementing such a tooling framework with scripts and libraries
> > for the features described above, as a small GitHub project, instead of
> > putting an existing side-car solution up for vote? If that would work
> > and we get people collaborating on code shared between existing
> > side-cars, then we could take the next step and think about either
> > revisit the "official Cassandra side-car" topic, or add the created
> > client tooling framework as official sub-project to the Cassandra
> > project (maybe via Apache incubator).
> >
> >
> > On 08.09.18 02:49, Joseph Lynch wrote:
> > > On Fri, Sep 7, 2018 at 5:03 PM Jonathan Haddad 
> > wrote:
> > >> We haven’t even defined any requirements for an admin tool. It’s hard
> to
> > >> make a case for anything without agreement on what we’re trying to
> > build.
> > >>
> > > We were/are trying to sketch out scope/requirements in the #14395 and
> > > #14346 tickets as well as their associated design documents. I think
> > > the general proposed direction is a distributed 1:1 management sidecar
> > > process similar in architecture to Netflix's Priam except explicitly
> > > built to be general and pluggable by anyone rather than tightly
> > > coupled to AWS.
> > >
> > > Dinesh, Vinay and I were aiming for low amounts of scope at first and
> > > take things in an iterative approach with just enough upfront design
> > > but not so much we are unable to make any progress at all. For example
> > > maybe something like:
> > >
> > > 1. Get a super simple and non controversial sidecar process that ships
> > > with Cassandra and exposes a lightweight HTTP interface to e.g. some
> > > basic JMX endpoints
> > > 2a. Add a pluggable execution engine for cron/oneshot/scheduled jobs
> > > with the basic interfaces and state store and such
> > > 2b. Start scoping and implementing the full HTTP interface, e.g.
> > > backup status, cluster health status, etc ...
> > > 3a. Start integrating implementations of the jobs from 2a such as
> > > snapshot, backup, cluster restart, daemon + sstable upgrade, repair,
> > > etc
> > > 3b. Start integrating UI components that pair with the HTTP interface
> > from 2b
> > > 4. ?? Perhaps start unlocking next generation operations like moving
> > > "background" activities like compaction, streaming, repair etc into
> > > one or more sidecar contained processes to ensure the main daemon only
> > > handles read+write requests
> > >
> > > There are going to be a lot of questions to answer, and I think trying
> > > to answer them all up front will mean that we get nowhere or make
> > > unfortunate compromises that cripple the project from the start. If
> > > people think we need to do more design and discussion than we have
> > > been doing then we can spend more time on the design, but personally
> > > I'd rather start iterating on code and prove value incrementally. If
> > > it doesn't work out we won't release it GA to the community ...
> > >
> > > -Joey
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For 

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

Most of the discussions have been around whether we take some side car or
do a cherry pick approach where we add a feature at a time to side car and
use the best implementation.
We have been discussing this first in April and now for several days. I
think we all want some progress here. We will start a vote soon..may be
next week to decide which approach we will take. I don't see any other
option to make progress besides a vote!!

PS: I think these discussions are very good for the community and it shows
people care about Apache Cassandra and it is a sign of healthy community.
Several people offering to donate the side car or help build is showing the
interest everyone has in it.


On Sat, Sep 8, 2018 at 11:17 AM Joseph Lynch  wrote:

> On Fri, Sep 7, 2018 at 10:00 PM Blake Eggleston 
> wrote:
> >
> > Right, I understand the arguments for starting a new project. I’m not
> saying reaper is, technically speaking, the best place to start. The point
> I’m trying to make is that the non-technical advantages of using an
> existing project as a starting point may outweigh the technical benefits of
> a clean slate. Whether that’s the case or not, it’s not a strictly
> technical decision, and the non-technical advantages of starting with
> reaper need to be weighed.
> >
>
> Technical debt doesn't just refer to the technical solutions, having
> an existing user base means that a project has made promises in the
> past (in the case of Priam 5+ years ago) that the new project would
> have to keep if we make keeping users of those sidecars a goal (which
> for the record I don't think should be a goal, I think the goal is to
> make Cassandra the database work out of the box in the 4.x series).
>
> For example, Priam has to continue supporting the following as users
> actively use them (including Netflix):
> * Parallel token assignment and creation allowing parallel bootstrap
> and parallel doubling of hundred node clusters at once (as long as you
> use single tokens and run in AWS with asgs).
> * 3+ backup solutions, as well as assumptions about where in e.g. S3
> backups are present and what format they're present in.
> * Numerous configuration options and UI elements (mostly 5 year old JSON
> APIs)
> * Support for Cassandra 2.0, 2.1, 2.2, 3.0, 3.11 and soon 4.0
>
> Reaper has to continue supporting the following as users actively use them:
> * Postgres and h2 storage backends. These were the original storage
> engines and users may not have (probably haven't?) migrated to the
> relatively recently added Cassandra backend (which is probably the
> only one an official sidecar should support imo).
> * The three historical modes of running Reaper [1] all of which
> involve remote JMX (disallowed by many companies security policies
> including Netflix's) and none of which are a sidecar design (although
> Mick says we can add that back in, at which point it has to support
> four).
> * Numerous configuration options and UI elements (e.g. a UI around a
> single Reaper instance controlling many Cassandra clusters instead of
> each cluster having a separate UI more consistent with how Cassandra
> architecture works)
> * Support for Cassandra 2.2, 3.0, 3.11, and soon 4.0
>
> [1] http://cassandra-reaper.io/docs/usage/multi_dc/
> [2] https://github.com/hashbrowncipher/cassandra-mirror
>
> We can't "get the community" of these sidecars and drop support for
> 90+% of the supported configurations and features at the same time ...
> These projects have made promises to users, as per the name technical
> debt these choices made over years have explicit costs that we have to
> take into account if we accept a project as is with the goal of taking
> the community with us. If we don't have the goal of taking the
> existing community with us and are instead aiming to simply make
> Cassandra work out of the box without external tools, then we don't
> have to continue fulfilling these promises.
>
> Instead I think the organizations that made those promises (TLP and
> Netflix in these specific cases) should continue keeping them, and the
> Cassandra management process should be incrementally built by the
> Cassandra community with decisions made as a community and we only GA
> it when the PMC/community is happy with making a promise of support
> for the features that we've merged (and since we're starting from a
> fresh start if people have strong opinions about fundamental
> architecture we can try to take those into account like we did with
> the months of feedback on repair scheduling
> runtime/architecture/design). If we can't prove value over other
> community tools for running 4.x, which is definitely a possibility,
> then we don't mark the management process GA, we re-focus on
> individual community tools, and imo failure is a reasonable result of
> attempted innovation.
>
> -Joey
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional 

Re: QA signup

[sankalp kohli]

Thanks for starting this Jon.
Instead of saying "I tested streaming", we should define what all was
tested like was all data transferred, what happened when stream failed,
etc.
Based on talking to a few users, looks like most testing is done by doing
an operation or running a load and seeing if it "worked" and no errors in
logs.

Another important thing will be to fix bugs asap ahead of testing,  as
fixes can lead to more bugs :)

On Thu, Sep 6, 2018 at 7:52 AM Jonathan Haddad  wrote:

> I was thinking along the same lines.  For this to be successful I think
> either weekly or bi-weekly summary reports back to the mailing list by the
> team lead for each subsection on what's been tested and how it's been
> tested will help keep things moving along.
>
> In my opinion the lead for each team should *not* be the contributor that
> wrote the feature, but someone who's very interested in it and can use the
> contributor as a resource.  I think it would be difficult for the
> contributor to poke holes in their own work - if they could do that it
> would have been done already.  This should be a verification process that's
> independent as possible from the original work.
>
> In addition to the QA process, it would be great if we could get a docs
> team together.  We've got quite a bit of undocumented features and nuance
> still, I think hammering that out would be a good idea.  Mick brought up
> updating the website docs in the thread on testing different JDK's [1], if
> we could figure that out in the process we'd be in a really great position
> from the user perspective.
>
> Jon
>
> [1]
>
> https://lists.apache.org/thread.html/5645178efb57939b96e73ab9c298e80ad8e76f11a563b4d250c1ae38@%3Cdev.cassandra.apache.org%3E
>
> On Thu, Sep 6, 2018 at 10:35 AM Jordan West  wrote:
>
> > Thanks for staring this thread Jon!
> >
> > On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad 
> wrote:
> >
> > > For 4.0, I'm thinking it would be a good idea to put together a list of
> > the
> > > things that need testing and see if people are willing to help test /
> > break
> > > those things.  My goal here is to get as much coverage as possible, and
> > let
> > > folks focus on really hammering on specific things rather than just
> > firing
> > > up a cluster and rubber stamping it.  If we're going to be able to
> > > confidently deploy 4.0 quickly after it's release we're going to need a
> > > high attention to detail.
> > >
> > >
> > +1 to a more coordinated effort. I think we could use the Confluence that
> > was set up a little bit ago since it was setup for this purpose, at least
> > for finalized plans and results:
> > https://cwiki.apache.org/confluence/display/CASSANDRA.
> >
> >
> > > In addition to a signup sheet, I think providing some guidance on how
> to
> > QA
> > > each thing that's being tested would go a long way.  Throwing "hey
> please
> > > test sstable streaming" over the wall will only get quality feedback
> from
> > > folks that are already heavily involved in the development process.  It
> > > would be nice to bring some new faces into the project by providing a
> > > little guidance.
> > >
> >
> > > We could help facilitate this even further by considering the people
> > > signing up to test a particular feature as a team, with seasoned
> > Cassandra
> > > veterans acting as team leads.
> > >
> >
> > +1 to this as well. I am always a fan of folks learning about a
> > subsystem/project through testing. It can be challenging to get folks new
> > to a project excited about testing first but for those that do, or for
> > committers who want to learn another part of the db, its a great way to
> > learn.
> >
> > Another thing we can do here is make sure teams are writing about the
> > testing they are doing and their results. This will help share knowledge
> > about techniques and approaches that others can then apply. This
> knowledge
> > can be shared on the mailing list, a blog post, or in JIRA.
> >
> >  Jordan
> >
> >
> > > Any thoughts?  I'm happy to take the lead on this.
> > > --
> > > Jon Haddad
> > > http://www.rustyrazorblade.com
> > > twitter: rustyrazorblade
> > >
> >
>
>
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: NGCC 2018?

[sankalp kohli]

Another thing to  discuss will be how to improve testing further from the
learning of finding bugs in C* 4.0.

On Wed, Sep 5, 2018 at 9:57 AM Jason Brown  wrote:

> +1 to Jon's sentiment. Further, perhaps we should use that time after
> GA'ing 4.0 to poll our users what they need/want from the next major
> release of the database.
>
> On Wed, Sep 5, 2018 at 9:31 AM, Jonathan Haddad  wrote:
>
> > I'm thinking a month or two after 4.0 would give us time to unwind after
> > the release and start to give real thought to big changes coming in the
> > next release.  Let's focus on one thing at a time.
> >
> > On Wed, Sep 5, 2018 at 12:29 PM sankalp kohli 
> > wrote:
> >
> > > A good time for NGCC will be closer to 4.0 release where we can plan
> what
> > > we can put it on 4.0-next. I am not sure doing it now is going to help
> > when
> > > we are months away from 4.0 release.
> > >
> > > On Fri, Aug 31, 2018 at 7:42 AM Jay Zhuang 
> > wrote:
> > >
> > > > Are we going to have a dev event next month? Or anything this year?
> We
> > > may
> > > > also be able to provide space in bay area and help to organize it.
> > > (Please
> > > > let us know, so we could get final approval for that).
> > > >
> > > > On Fri, Jul 27, 2018 at 10:05 AM Jonathan Haddad 
> > > > wrote:
> > > >
> > > > > My interpretation of Nate's statement was that since there would
> be a
> > > > bunch
> > > > > of us at Lynn's event, we might as well do NGCC at the same time.
> > > > >
> > > > > On Thu, Jul 26, 2018 at 9:03 PM Ben Bromhead 
> > > > wrote:
> > > > >
> > > > > > It sounds like there may be an appetite for something, but the
> NGCC
> > > in
> > > > > its
> > > > > > current format is likely to not be that useful?
> > > > > >
> > > > > > Is a bay area event focused on C* developers something that is
> > > > > interesting
> > > > > > for the broader dev community? In whatever format that may be?
> > > > > >
> > > > > > On Tue, Jul 24, 2018 at 5:02 PM Nate McCall 
> > > > wrote:
> > > > > >
> > > > > > > This was discussed amongst the PMC recently. We did not come
> to a
> > > > > > > conclusion and there were not terribly strong feelings either
> > way.
> > > > > > >
> > > > > > > I don't feel like we need to hustle to get "NGCC" in place,
> > > > > > > particularly given our decided focus on 4.0. However, that
> should
> > > not
> > > > > > > stop us from doing an additional 'c* developer' event in sept.
> to
> > > > > > > coincide with distributed data summit.
> > > > > > >
> > > > > > > On Wed, Jul 25, 2018 at 5:03 AM, Patrick McFadin <
> > > pmcfa...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > Ben,
> > > > > > > >
> > > > > > > > Lynn Bender had offered a space the day before Distributed
> Data
> > > > > Summit
> > > > > > in
> > > > > > > > September (http://distributeddatasummit.com/) since we are
> > both
> > > > > > platinum
> > > > > > > > sponsors. I thought he and Nate had talked about that being a
> > > good
> > > > > > place
> > > > > > > > for NGCC since many of us will be in town already.
> > > > > > > >
> > > > > > > > Nate, now that I've spoken for you, you can clarify, :D
> > > > > > > >
> > > > > > > > Patrick
> > > > > > > >
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > > > > >
> > > > > > > --
> > > > > > Ben Bromhead
> > > > > > CTO | Instaclustr <https://www.instaclustr.com/>
> > > > > > +1 650 284 9692
> > > > > > Reliability at Scale
> > > > > > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jon Haddad
> > > > > http://www.rustyrazorblade.com
> > > > > twitter: rustyrazorblade
> > > > >
> > > >
> > >
> >
> >
> > --
> > Jon Haddad
> > http://www.rustyrazorblade.com
> > twitter: rustyrazorblade
> >
>

Re: Side Car New Repo vs not

[Sankalp Kohli]

Thanks everyone for the feedback. Looks like we will go with separate repo as 
that is what majority of people prefer. 

Also note that we can always change this approach later as we build the side 
car. 

> On Aug 24, 2018, at 07:00, Eric Evans  wrote:
> 
>> On Thu, Aug 23, 2018 at 3:01 PM sankalp kohli  wrote:
>> 
>> Separate repo is in a majority so far. Please reply to this thread with
>> your responses.
> 
> I think it makes sense for the code, project, and workflows to be
> (de|loosely)-coupled, so the repo should be as well.
> 
> +1 for a separate repository
> 
>> On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh 
>> wrote:
>> 
>>> +1 for separate repo. Especially on git. Maybe make it a submodule.
>>> 
>>> Rahul
>>> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski ,
>>> wrote:
>>>> I'm also currently -1 on the in-tree option.
>>>> 
>>>> Additionally to what Aleksey mentioned, I also don't see how we could
>>>> make this work with the current build and release process. Our scripts
>>>> [0] for creating releases (tarballs and native packages), would need
>>>> significant work to add support for an independent side-car. Our ant
>>>> based build process is also not a great start for adding new tasks, let
>>>> alone integrating other tool chains for web components for a potential
>>> UI.
>>>> 
>>>> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
>>>> 
>>>> 
>>>>> On 21.08.18 19:20, Aleksey Yeshchenko wrote:
>>>>> Sure, allow me to elaborate - at least a little bit. But before I do,
>>> just let me note that this wasn’t a veto -1, just a shorthand for “I don’t
>>> like this option”.
>>>>> 
>>>>> It would be nice to have sidecar and C* version and release cycles
>>> fully decoupled. I know it *can* be done when in-tree, but the way we vote
>>> on releases with tags off current branches would have to change somehow.
>>> Probably painfully. It would be nice to be able to easily enforce freezes,
>>> like the upcoming one, on the whole C* repo, while allowing feature
>>> development on the sidecar. It would be nice to not have sidecar commits in
>>> emails from commits@ mailing list. It would be nice to not have C* CI
>>> trigger necessarily on sidecar commits. Groups of people working on the two
>>> repos will mostly be different too, so what’s the point in sharing the repo?
>>>>> 
>>>>> Having an extra repo with its own set of branches is cheap and easy -
>>> we already do that with dtests. I like cleanly separated things when
>>> coupling is avoidable. As such I would prefer the sidecar to live in a
>>> separate new repo, while still being part of the C* project.
>>>>> 
>>>>> —
>>>>> AY
>>>>> 
>>>>> On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com)
>>> wrote:
>>>>> 
>>>>> Hi Aleksey,
>>>>> Can you please elaborate on the reasons for your -1? This
>>>>> way we can make progress towards any one approach.
>>>>> Thanks,
>>>>> Sankalp
>>>>> 
>>>>> On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko 
>>>>> wrote:
>>>>> 
>>>>>> FWIW I’m strongly -1 on in-tree approach, and would much prefer a
>>> separate
>>>>>> repo, dtest-style.
>>>>>> 
>>>>>> —
>>>>>> AY
>>>>>> 
>>>>>> On 21 August 2018 at 16:36:02, Jeremiah D Jordan (
>>>>>> jeremiah.jor...@gmail.com) wrote:
>>>>>> 
>>>>>> I think the following is a very big plus of it being in tree:
>>>>>>>> * Faster iteration speed in general. For example when we need to
>>> add a
>>>>>>>> new
>>>>>>>> JMX endpoint that the sidecar needs, or change something from
>>> JMX to a
>>>>>>>> virtual table (e.g. for repair, or monitoring) we can do all
>>> changes
>>>>>>>> including tests as one commit within the main repository and
>>> don't
>>>>>> have
>>>>>>>> to
>>>>>>>> commit to main repo, sidecar repo,
>>>>>> 
>>>>>> I also don’t see a reason why the sidecar being in tree means it
>>> would not
>

Re: Side Car New Repo vs not

[sankalp kohli]

Separate repo is in a majority so far. Please reply to this thread with
your responses.

On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh 
wrote:

> +1 for separate repo. Especially on git. Maybe make it a submodule.
>
> Rahul
> On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski ,
> wrote:
> > I'm also currently -1 on the in-tree option.
> >
> > Additionally to what Aleksey mentioned, I also don't see how we could
> > make this work with the current build and release process. Our scripts
> > [0] for creating releases (tarballs and native packages), would need
> > significant work to add support for an independent side-car. Our ant
> > based build process is also not a great start for adding new tasks, let
> > alone integrating other tool chains for web components for a potential
> UI.
> >
> > [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
> >
> >
> > On 21.08.18 19:20, Aleksey Yeshchenko wrote:
> > > Sure, allow me to elaborate - at least a little bit. But before I do,
> just let me note that this wasn’t a veto -1, just a shorthand for “I don’t
> like this option”.
> > >
> > > It would be nice to have sidecar and C* version and release cycles
> fully decoupled. I know it *can* be done when in-tree, but the way we vote
> on releases with tags off current branches would have to change somehow.
> Probably painfully. It would be nice to be able to easily enforce freezes,
> like the upcoming one, on the whole C* repo, while allowing feature
> development on the sidecar. It would be nice to not have sidecar commits in
> emails from commits@ mailing list. It would be nice to not have C* CI
> trigger necessarily on sidecar commits. Groups of people working on the two
> repos will mostly be different too, so what’s the point in sharing the repo?
> > >
> > > Having an extra repo with its own set of branches is cheap and easy -
> we already do that with dtests. I like cleanly separated things when
> coupling is avoidable. As such I would prefer the sidecar to live in a
> separate new repo, while still being part of the C* project.
> > >
> > > —
> > > AY
> > >
> > > On 21 August 2018 at 17:06:39, sankalp kohli (kohlisank...@gmail.com)
> wrote:
> > >
> > > Hi Aleksey,
> > > Can you please elaborate on the reasons for your -1? This
> > > way we can make progress towards any one approach.
> > > Thanks,
> > > Sankalp
> > >
> > > On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko 
> > > wrote:
> > >
> > > > FWIW I’m strongly -1 on in-tree approach, and would much prefer a
> separate
> > > > repo, dtest-style.
> > > >
> > > > —
> > > > AY
> > > >
> > > > On 21 August 2018 at 16:36:02, Jeremiah D Jordan (
> > > > jeremiah.jor...@gmail.com) wrote:
> > > >
> > > > I think the following is a very big plus of it being in tree:
> > > > > > * Faster iteration speed in general. For example when we need to
> add a
> > > > > > new
> > > > > > JMX endpoint that the sidecar needs, or change something from
> JMX to a
> > > > > > virtual table (e.g. for repair, or monitoring) we can do all
> changes
> > > > > > including tests as one commit within the main repository and
> don't
> > > > have
> > > > > > to
> > > > > > commit to main repo, sidecar repo,
> > > >
> > > > I also don’t see a reason why the sidecar being in tree means it
> would not
> > > > work in a mixed version cluster. The nodes themselves must work in a
> mixed
> > > > version cluster during a rolling upgrade, I would expect any
> management
> > > > side car to operate in the same manor, in tree or not.
> > > >
> > > > This tool will be pretty tightly coupled with the server, and as
> someone
> > > > with experience developing such tightly coupled tools, it is *much*
> easier
> > > > to make sure you don’t accidentally break them if they are in tree.
> How
> > > > many times has someone updated some JMX interface, updated nodetool,
> and
> > > > then moved on? Breaking all the external tools not in tree, without
> > > > realizing it. The above point about being able to modify interfaces
> and the
> > > > side car in the same commit is huge in terms of making sure someone
> doesn’t
> > > > inadvertently break the side car while fixing something else.
> > > >
> > &g

Re: Side Car New Repo vs not

[sankalp kohli]

 don't
> >> have to worry about testing matrices to assure that the sidecar works
> >> with
> >> various versions as the version of the sidecar that is released with
> that
> >> version of Cassandra is the only one we have to certify works. If
> people
> >> want to pull in new versions or maintain backports they can do that at
> >> their discretion/testing.
> >> * We can iterate and prove value before committing to a choice. Since
> it
> >> will be a separate artifact from the start we can always move the
> >> artifact
> >> to a separate repo later (but moving the other way is harder).
> >> * Users will get the sidecar "for free" when they install the daemon,
> >> they
> >> don't need to take affirmative action to e.g. be able to restart their
> >> cluster, run repair, or back their data up; it just comes out of the
> box
> >> for free.
> >>
> >> Unique pros of a separate repository sidecar:
> >> * We can use a more modern build system like gradle instead of ant
> >> * Merging changes is less "scary" I guess (I feel like if you're not
> >> touching the daemon this is already true but I could see this being
> less
> >> worrisome for some).
> >> * Releasing a separate artifact is somewhat easier from a separate
> repo
> >> (especially if we have gradle which makes e.g. building debs and rpms
> >> trivial).
> >> * We could backport to previous versions without getting into
> arguments
> >> about bug fixes vs features.
> >> * Committers could be different from the main repo, which ... may be a
> >> useful thing
> >>
> >> Non unique pros of a sidecar (could be achieved in the main repo or in
> a
> >> separate repo):
> >> * A separate build artifact .jar/.deb/.rpm that can be installed
> >> separately. It's slightly easier with a separate repo but certainly
> not
> >> out
> >> of reach within a single repo (indeed the current patch already creates
> a
> >> separate jar, and we could create a separate .deb reasonably easily).
> >> Personally I think having a separate .deb/.rpm is premature at this
> point
> >> (for companies that really want it they can build their own packages
> >> using
> >> the .jars), but I think it really is a distracting issue from where
> the
> >> patch should go as we can always choose to remove experimental .jar
> files
> >> that the main daemon doesn't touch.
> >> * A separate process lifecycle. No matter where the sidecar goes, we
> get
> >> the benefit of restarting it being less dangerous for availability
> than
> >> restarting the main daemon.
> >>
> >> That all being said, these are strong opinions weakly held and I would
> >> rather get something actually committed so that we can prove value one
> >> way
> >> or the other and am therefore, of course, happy to put sidecar patches
> >> wherever someone can review and commit it.
> >>
> >> -Joey
> >>
> >> On Mon, Aug 20, 2018 at 1:52 PM sankalp kohli 
>
> >> wrote:
> >>
> >>> Hi,
> >>> I am starting a new thread to get consensus on where the side car
> >>> should be contributed.
> >>>
> >>> Please send your responses with pro/cons of each approach or any
> other
> >>> approach. Please be clear which approach you will pick while still
> >> giving
> >>> pros/cons of both approaches.
> >>>
> >>> Thanks.
> >>> Sankalp
> >>>
> >>
> >
> >
> > --
> > Jon Haddad
> > http://www.rustyrazorblade.com
> > twitter: rustyrazorblade
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Side Car New Repo vs not

[sankalp kohli]

Hi,
I am starting a new thread to get consensus on where the side car
should be contributed.

Please send your responses with pro/cons of each approach or any other
approach. Please be clear which approach you will pick while still giving
pros/cons of both approaches.

Thanks.
Sankalp

Re: Proposing an Apache Cassandra Management process

[sankalp kohli]

Hi,
Here is how I think we can make progress
1. Consensus is reached that we need side car as this thread is months old
and I do not see any objections. I bumped it again and it is good to see it
being active.
2. There is no consensus on new repo vs not. I will start a thread on it
and lets discuss it.
3. We have 2 implementations now for running repair via side car. This is
actually awesome to see for the community. We should work on JIRA(like we
did for virtual table) to get the best out of both the implementation.

Thanks,
Sankalp



On Mon, Aug 20, 2018 at 4:23 AM Mick Semb Wever  wrote:

>
> On Fri, 17 Aug 2018, at 14:27, Sankalp Kohli wrote:
> > I am bumping this thread because patch has landed for this with repair
> > functionality.
>
>
> We are looking to contribute Reaper to the Cassandra project.
>
> Looking at the patch it's very similar in its base design already, but
> Reaper does has a lot more to offer. We have all been working hard to move
> it to also being a side-car so it can be contributed. This raises a number
> of relevant questions to this thread: would we then accept both works in
> the Cassandra project, and what burden would it put on the current PMC to
> maintain both works.
>
> I share Stefan's concern that consensus had not been met around a
> side-car, and that it was somehow default accepted before a patch landed.
> This seems at odds when we're already struggling to keep up with the
> incoming patches/contributions, and there could be other git repos in the
> project we will need to support in the future too. But I'm also curious
> about the whole "Community over Code" angle to this, how do we encourage
> multiple external works to collaborate together building value in both the
> technical and community.
>
> The Reaper project has worked hard in building both its user and
> contributor base. And I would have thought these, including having the
> contributor base overlap with the C* PMC, were prerequisites before moving
> a larger body of work into the project (separate git repo or not). I guess
> this isn't so much "Community over Code", but it illustrates a concern
> regarding abandoned code when there's no existing track record of
> maintaining it as OSS, as opposed to expecting an existing "show, don't
> tell" culture. Reaper for example has stronger indicators for ongoing
> support and an existing OSS user base: today C* committers having
> contributed to Reaper are Jon, Stefan, Nate, and myself, amongst the 40
> contributors in total. And we've been making steps to involve it more into
> the C* community (eg users ML), without being too presumptuous. On the
> technical side: Reaper supports (or can easily) all the concerns that the
> proposal here raises: distributed nodetool commands, centralising jmx
> interfacing, scheduling ops (repairs, snapshots, compactions, cleanups,
> etc), monitoring and diagnostics, etc etc. It's designed so that it can be
> a single instance, instance-per-datacenter, or side-car (per process). When
> there are multiple instances in a datacenter you get HA. You have a choice
> of different storage backends (memory, postgres, c*). You can ofc use a
> separate C* cluster as a backend so to separate infrastructure data from
> production data. And it's got an UI for C* Diagnostics already (which
> imposes a different jmx interface of polling for events rather than
> subscribing to jmx notifications which we know is problematic, thanks to
> Stefan). Anyway, that's my plug for Reaper :-)
>
> There's been little effort in evaluating these two bodies of work, one
> which is largely unknown to us, and my concern is how we would fairly
> support both going into the future?
>
> Another option would be that this side-car patch first exists as a github
> project for a period of time, on par to how Reaper has been. This will help
> evaluate its use and to first build up its contributors. This makes it
> easier for the C* PMC to choose which projects it would want to formally
> maintain, and to do so based on factors beyond merits of the technical. We
> may even see it converge (or collaborate more) with Reaper, a win for
> everyone.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

That’s a good point. Let’s review the patch and when it is ready to commit, we 
can create the repo then. 

> On Aug 18, 2018, at 14:04, Stefan Podkowinski  wrote:
> 
> I think we do have some consensus that 1) we should give it a try to
> have one or many side-car processes for non-essential features, and that
> 2) they should be developed in a separate repo. I'm also open to the
> idea of accepting the proposed implementation as a possible side-car
> solution and really appreciate effort. But my point is that creating a
> new repo, just for the patch, seems to imply that it's also going to
> become the de facto official side-car solution, which doesn't feel right
> to me, given that the proposed patch isn't even reviewed and hasn't
> received much feedback yet.
> 
> 
>> On 18.08.18 17:44, Sankalp Kohli wrote:
>> The thread for side car is months old and no one has opposed to it and hence 
>> someone developed it. I am not sure how else you get consensus. 
>> 
>> Regarding separate repo, how do we get consensus? 
>> 
>>> On Aug 18, 2018, at 05:19, Stefan Podkowinski  wrote:
>>> 
>>> I don't see that we have reached sufficient consensus on this yet. We've
>>> had a brief discussion about the pros and cons of in-tree cassandra vs
>>> separate ASF repo here, but let's not frame it like it's either or. From
>>> my perspective, there hasn't been any final decision yet whether the
>>> proposed side-car solution should be further developed as part of the
>>> Cassandra project, or not.
>>> 
>>> 
>>>> On 18.08.18 03:12, Dinesh Joshi wrote:
>>>> Thanks, Nate. I’ll create this request.
>>>> 
>>>> Dinesh
>>>> 
>>>> On Aug 17, 2018, at 5:09 PM, Nate McCall  wrote:
>>>> 
>>>>>> I'm not sure logistically how we get a new repo created and licensing and
>>>>>> such, but if someone helps make it we can cut the patch against it
>>>>>> 
>>>>> This is pretty straight forward. For precedent, see:
>>>>> https://issues.apache.org/jira/browse/CASSANDRA-13634
>>>>> 
>>>>> We currently have three repositories:
>>>>> https://git-wip-us.apache.org/repos/asf
>>>>> 
>>>>> I'm +0 on what approach we take.
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

The thread for side car is months old and no one has opposed to it and hence 
someone developed it. I am not sure how else you get consensus. 

Regarding separate repo, how do we get consensus? 

> On Aug 18, 2018, at 05:19, Stefan Podkowinski  wrote:
> 
> I don't see that we have reached sufficient consensus on this yet. We've
> had a brief discussion about the pros and cons of in-tree cassandra vs
> separate ASF repo here, but let's not frame it like it's either or. From
> my perspective, there hasn't been any final decision yet whether the
> proposed side-car solution should be further developed as part of the
> Cassandra project, or not.
> 
> 
>> On 18.08.18 03:12, Dinesh Joshi wrote:
>> Thanks, Nate. I’ll create this request.
>> 
>> Dinesh
>> 
>> On Aug 17, 2018, at 5:09 PM, Nate McCall  wrote:
>> 
 I'm not sure logistically how we get a new repo created and licensing and
 such, but if someone helps make it we can cut the patch against it
 
>>> This is pretty straight forward. For precedent, see:
>>> https://issues.apache.org/jira/browse/CASSANDRA-13634
>>> 
>>> We currently have three repositories:
>>> https://git-wip-us.apache.org/repos/asf
>>> 
>>> I'm +0 on what approach we take.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> -
>> 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: Proposing an Apache Cassandra Management process

[Sankalp Kohli]

I am bumping this thread because patch has landed for this with repair 
functionality. 

I have a following proposal for this which I can put in the JIRA or doc 

1. We should see if we can keep this in a separate repo like Dtest. 
2. It should have its own release process.
3. It should have integration tests for different versions of Cassandra it will 
support. 

Does anyone has any ideas on this ? 

Thanks
Sankalp 

> On Apr 18, 2018, at 19:20, Dinesh Joshi  
> wrote:
> 
> Thank you all for the feedback. Nate made a Google doc with the proposal in 
> it and is linked off of the ticket. I will try to flesh it out as I gather 
> your input.
> Dinesh 
> 
>On Wednesday, April 18, 2018, 5:12:49 PM PDT, kurt greaves 
>  wrote:  
> 
> For anyone looking Dinesh made a ticket already: CASSANDRA-14395
> 
> 
>> On 18 April 2018 at 18:14, Vinay Chella  wrote:
>> 
>> This is a good initiative. We have advocated for and run a sidecar for the
>> past 5+ years, and we've learned and improved it a lot. We look forward to
>> moving features from Priam (such as backup, HTTP -> JMX, etc) incrementally
>> to this sidecar as they make sense.
>> 
>> 
>> Thanks,
>> Vinay Chella
>> 
>> On Fri, Apr 13, 2018 at 7:01 AM, Eric Evans 
>> wrote:
>> 
>>> On Thu, Apr 12, 2018 at 4:41 PM, Dinesh Joshi
>>>  wrote:
 Hey all -
 With the uptick in discussion around Cassandra operability and after
>>> discussing potential solutions with various members of the community, we
>>> would like to propose the addition of a management process/sub-project
>> into
>>> Apache Cassandra. The process would be responsible for common operational
>>> tasks like bulk execution of nodetool commands, backup/restore, and
>> health
>>> checks, among others. We feel we have a proposal that will garner some
>>> discussion and debate but is likely to reach consensus.
 While the community, in large part, agrees that these features should
>>> exist “in the database”, there is debate on how they should be
>> implemented.
>>> Primarily, whether or not to use an external process or build on
>>> CassandraDaemon. This is an important architectural decision but we feel
>>> the most critical aspect is not where the code runs but that the operator
>>> still interacts with the notion of a single database. Multi-process
>>> databases are as old as Postgres and continue to be common in newer
>> systems
>>> like Druid. As such, we propose a separate management process for the
>>> following reasons:
 
 - Resource isolation & Safety: Features in the management process
>>> will not affect C*'s read/write path which is critical for stability. An
>>> isolated process has several technical advantages including preventing
>> use
>>> of unnecessary dependencies in CassandraDaemon, separation of JVM
>> resources
>>> like thread pools and heap, and preventing bugs from adversely affecting
>>> the main process. In particular, GC tuning can be done separately for the
>>> two processes, hopefully helping to improve, or at least not adversely
>>> affect, tail latencies of the main process.
 
 - Health Checks & Recovery: Currently users implement health checks
>>> in their own sidecar process. Implementing them in the serving process
>> does
>>> not make sense because if the JVM running the CassandraDaemon goes south,
>>> the healthchecks and potentially any recovery code may not be able to
>> run.
>>> Having a management process running in isolation opens up the possibility
>>> to not only report the health of the C* process such as long GC pauses or
>>> stuck JVM but also to recover from it. Having a list of basic health
>> checks
>>> that are tested with every C* release and officially supported will help
>>> boost confidence in C* quality and make it easier to operate.
 
 - Reduced Risk: By having a separate Daemon we open the possibility
>>> to contribute features that otherwise would not have been considered
>> before
>>> eg. a UI. A library that started many background threads and is operated
>>> completely differently would likely be considered too risky for
>>> CassandraDaemon but is a good candidate for the management process.
>>> 
>>> Makes sense IMO.
>>> 
 What can go into the management process?
 - Features that are non-essential for serving reads & writes for eg.
>>> Backup/Restore or Running Health Checks against the CassandraDaemon, etc.
 
 - Features that do not make the management process critical for
>>> functioning of the serving process. In other words, if someone does not
>>> wish to use this management process, they are free to disable it.
 
 We would like to initially build minimal set of features such as health
>>> checks and bulk commands into the first iteration of the management
>>> process. We would use the same software stack that is used to build the
>>> current CassandraDaemon binary. This would be critical for sharing code

Apache Cassandra Blog is now live

[sankalp kohli]

Hi,
 Apache Cassandra Blog is now live. Check out the first blog post.

http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html

Thanks,
Sankalp