Re: [DISCUSS] CEP-9: Make SSLContext creation pluggable

[Maulin Vasavada]

Thanks Berenguer. Mainly I did detailed PR since I was not familiar with
Cassandra codebase and wanted to make sure I figured out the magnitude of
things lying ahead of me sooner by having tests failures etc :) Also partly
I get chunks of time where I just focus and do things so I better utilize
that time :)

On Mon, Jul 12, 2021 at 10:33 PM Berenguer Blasi 
wrote:

> I have gone through the CEP and I have no concerns on voting on it.
>
> In my case a PR helps me pin down and understand better what the CEP
> will indeed look like, I like that a lot. So thx Maulin for the detailed
> PR with the luxury of all tests and all bells and whistles!. If it were
> a CEP of my own though my PR would be with pseudo-code or similar, for
> illustration and brainstorming purposes only, just to give enough
> context for the voting. That way if my CEP gets declined I haven't
> wasted so much effort.
>
> My 2cts.
>
> On 13/7/21 0:25, Ekaterina Dimitrova wrote:
> > Hi everyone,
> >
> > Reading the thread I feel we are all more or less on the same page.
> >
> > My personal line of thinking:
> > 1) I really like Benedict’s idea of some kind of cheat sheet
> > 2) I think some kind of PoC PR, when/if needed, sounds reasonable.
> Probably
> > It can help in some cases the author to reconsider  or even explain
> better
> > some suggestions/decisions. In that sense, I think I agree with Maulin
> that
> > probably Jira ticket after voted CEP is a good idea. I think that when we
> > put PR in a Jira ticket (at least I as a creature of habit) we start
> > thinking of more diligent reviews and might forget it is still unapproved
> > CEP and get into details that doesn’t really matter at this point in
> time.
> > But that might be only me. :-)
> >
> > Best regards,
> > Ekaterina
> >
> > On Mon, 12 Jul 2021 at 15:47, Maulin Vasavada  >
> > wrote:
> >
> >> Thank you Benjamin. Sounds good to me.
> >>
> >> I feel if we leave full control of creating SSL's context (including
> >> ciphers, accepted protocols values etc) to the interface it would work.
> >> There are some other requirements people run into like customizing X 509
> >> cert validations (SPIFFE
> >> ),
> >> using
> >> different SSL Providers (like Bouncy Castle, Boring SSL etc) altogether
> >> which in my opinion can be better served with exploration of JSSE
> Providers
> >> (java's security.provider configuration) instead of trying to customize
> >> just the SSL Context. However, leaving full control with the SSL context
> >> factory interface may mean supporting 'Map' as modelling the
> configuration
> >> vs keeping 'CommonEncryptionOption' but that would again go into more
> >> technical discussion so we can keep it separate.
> >>
> >> Thanks
> >> Maulin
> >>
> >> On Mon, Jul 12, 2021 at 3:27 AM Benjamin Lerer 
> wrote:
> >>
>  In the context of your latest answers on JIRA - your interface makes
> >>> sense
>  to me, I just want to be sure that we will not forget to add anything
> >>> which
>  would a respective implementator need in the future and could not use
>  because it is just not exposed.
> >>>
> >>> I do not believe that we can build the perfect interface. Sadely, it is
> >>> impossible to know what future implementations will require. Outside of
> >>> the  obvious issues that we can think of right now, I believe that we
> >> will
> >>> just have to find some solutions at the time where the problems arise.
> >>>
> >>> The thread is right now going into technical areas that could be
> >> discussed
> >>> on the PR later on. It might be a sign that there are no high level
> >>> concerns with the CEP and that we should simply trigger the vote.
> >>> If nobody disagrees, I will start the vote tomorrow.
> >>>
> >>>
> >>>
> >>> Le sam. 10 juil. 2021 à 07:05, Mick Semb Wever  a
> écrit
> >> :
>  Thanks for bringing this back to the ML Maulin.
>  Very much appreciated.
> 
>  On Sat, 10 Jul 2021 at 00:04, Maulin Vasavada <
> >> maulin.vasav...@gmail.com
>  wrote:
> 
> > Thanks Stefan for the pointer for the 'examples' directory. Will
> >> invest
> > time in coming up with a reference custom implementation.
> >
> > For your other comments around common encryption options, I agree
> >> with
>  you
> > on a challenge in order to prevent secure information getting leaked
> >> in
> > logs. Let me create a separate branch and show how interface will
> >>> change
> > with keeping Common Encryption options + map instead of just the map.
> >
> > Thanks
> > Maulin
> >
> > On Fri, Jul 9, 2021 at 2:59 PM Maulin Vasavada <
>  maulin.vasav...@gmail.com>
> > wrote:
> >
> >> Stefan Miklosovic
> >> 
> >>
> >> Hi MAULIN VASAVADA
> >> ,
> >> few
>  more
> >> observations. I 

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

[Scott Andreas]

+1nb.

Thank you for sharing a Circle run, Sumanth!


From: Sumanth Pasupuleti 
Sent: Wednesday, July 14, 2021 12:52 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

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

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

> +1 (nb)
>
> > On Jul 15, 2021, at 3:42 AM, Blake Eggleston
>  wrote:
> >
> > +1
> >
> >> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko 
> wrote:
> >>
> >> +1
> >>
>  On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> >>>
> >>> +1
> >>>
>  On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever 
> wrote:
> 
>  Proposing the test build of Cassandra 4.0.0 for release.
> 
>  sha1: 924bf92fab1820942137138c779004acaf834187
>  Git:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>  Maven Artifacts:
> 
> 
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> 
>  The Source and Build Artifacts, and the Debian and RPM packages and
>  repositories, are available here:
>  https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> 
>  The vote will be open for 72 hours (longer if needed). Everyone who
>  has tested the build is invited to vote. Votes by PMC members are
>  considered binding. A vote passes if there are at least three binding
>  +1s and no -1's.
> 
>  [1]: CHANGES.txt:
> 
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>  [2]: NEWS.txt:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>> --
> >>> Jonathan Ellis
> >>> co-founder, http://www.datastax.com
> >>> @spyced
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[Nate McCall]

>
>
>
> > Yes, we should perhaps remove target version from the template, and
> > introduce guidance on describing stability impact etc.
>
> Strong +1 to remove this from the template. I got sucked into the mistake
> of conflating implementation details and implications on where it lands
> instead of staying high level in the "do we agree we need this".
>
> And I'm a +1 on the "I agree we need this".
>

+1 to focusing on the _if_ (I think we need it).

IMO we could keep the target version in the template and allow "To Be
Decided (TBD)" as it could be useful for larger efforts or specific
features. (I don't want to bikeshed on that though and won't complain if
that field goes away.)

Appreciate the debate and refocusing, though!

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

[Sumanth Pasupuleti]

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

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

> +1 (nb)
>
> > On Jul 15, 2021, at 3:42 AM, Blake Eggleston
>  wrote:
> >
> > +1
> >
> >> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko 
> wrote:
> >>
> >> +1
> >>
>  On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> >>>
> >>> +1
> >>>
>  On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever 
> wrote:
> 
>  Proposing the test build of Cassandra 4.0.0 for release.
> 
>  sha1: 924bf92fab1820942137138c779004acaf834187
>  Git:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>  Maven Artifacts:
> 
> 
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
> 
>  The Source and Build Artifacts, and the Debian and RPM packages and
>  repositories, are available here:
>  https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
> 
>  The vote will be open for 72 hours (longer if needed). Everyone who
>  has tested the build is invited to vote. Votes by PMC members are
>  considered binding. A vote passes if there are at least three binding
>  +1s and no -1's.
> 
>  [1]: CHANGES.txt:
> 
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>  [2]: NEWS.txt:
> 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>>
> >>> --
> >>> Jonathan Ellis
> >>> co-founder, http://www.datastax.com
> >>> @spyced
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

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

[Jeremy Hanna]

+1 (nb)

> On Jul 15, 2021, at 3:42 AM, Blake Eggleston  
> wrote:
> 
> +1
> 
>> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko  wrote:
>> 
>> +1
>> 
 On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
>>> 
>>> +1
>>> 
 On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:
 
 Proposing the test build of Cassandra 4.0.0 for release.
 
 sha1: 924bf92fab1820942137138c779004acaf834187
 Git:
 https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
 Maven Artifacts:
 
 https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
 
 The Source and Build Artifacts, and the Debian and RPM packages and
 repositories, are available here:
 https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
 
 The vote will be open for 72 hours (longer if needed). Everyone who
 has tested the build is invited to vote. Votes by PMC members are
 considered binding. A vote passes if there are at least three binding
 +1s and no -1's.
 
 [1]: CHANGES.txt:
 
 https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
 [2]: NEWS.txt:
 https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>>> -- 
>>> Jonathan Ellis
>>> co-founder, http://www.datastax.com
>>> @spyced
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

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

[Blake Eggleston]

+1

> On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko  wrote:
> 
> +1
> 
>> On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
>> 
>> +1
>> 
>>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:
>>> 
>>> Proposing the test build of Cassandra 4.0.0 for release.
>>> 
>>> sha1: 924bf92fab1820942137138c779004acaf834187
>>> Git:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>>> Maven Artifacts:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
>>> 
>>> The Source and Build Artifacts, and the Debian and RPM packages and
>>> repositories, are available here:
>>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>>> 
>>> The vote will be open for 72 hours (longer if needed). Everyone who
>>> has tested the build is invited to vote. Votes by PMC members are
>>> considered binding. A vote passes if there are at least three binding
>>> +1s and no -1's.
>>> 
>>> [1]: CHANGES.txt:
>>> 
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>>> [2]: NEWS.txt:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
>> -- 
>> Jonathan Ellis
>> co-founder, http://www.datastax.com
>> @spyced
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[Jeff Jirsa]

Same


On Wed, Jul 14, 2021 at 9:16 AM Brandon Williams  wrote:

> I am +1 to both removal from the template and "we need this"
>
> On Wed, Jul 14, 2021 at 9:05 AM Joshua McKenzie 
> wrote:
> >
> > And I'm a +1 on the "I agree we need this".
>
>

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[Brandon Williams]

I am +1 to both removal from the template and "we need this"

On Wed, Jul 14, 2021 at 9:05 AM Joshua McKenzie  wrote:
>
> >
> > Yes, we should perhaps remove target version from the template, and
> > introduce guidance on describing stability impact etc.
>
> Strong +1 to remove this from the template. I got sucked into the mistake
> of conflating implementation details and implications on where it lands
> instead of staying high level in the "do we agree we need this".
>
> And I'm a +1 on the "I agree we need this".
>
>
> On Wed, Jul 14, 2021 at 7:32 AM bened...@apache.org 
> wrote:
>
> > > I think CEPs would benefit from describing their compatibility and
> > stability impacts, rather than trying to tie themselves to a
> > version, regardless of what context a specific version provides.
> >
> > Yes, we should perhaps remove target version from the template, and
> > introduce guidance on describing stability impact etc.
> >
> > Regarding waivers, I’m not sure we’ve really agreed as a community what
> > the criteria are for determining if work goes into a patch release – so I’m
> > not sure it would be right to call it a waiver. But I agree that scheduling
> > the release to contain some work should be a mixture of project roadmap
> > planning (distinct from CEP), and Jira/dev list discussion near the point
> > of merge.
> >
> > The question is if there is still value in the CEP pages maintaining the
> > endeavour’s goal for when the work will be ready, but perhaps this can be
> > communicated in normal date format, and used to inform project roadmap
> > planning.
> >
> >
> > From: Mick Semb Wever 
> > Date: Wednesday, 14 July 2021 at 10:41
> > To: dev@cassandra.apache.org 
> > Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations
> > >
> > > PRs will land soon for people to look at, but honestly we’re getting into
> > > an unnecessary tangle over target release. I think it would be a mistake
> > to
> > > push this to a later release, because it is valuable and it will bring
> > pain
> > > by creating divergence - but the question a CEP is meant to answer is
> > _if_
> > > the community wants a piece of work.
> > >
> > > Since it’s become an explicit point of contention, we can perhaps
> > > disaggregate a vote on _when_ to happen in parallel, once discussion on
> > > _if_ wraps up.
> >
> >
> >
> > Totally agree, can we remove the "Target Version" from the CEP, so the vote
> > is based on the _if_ ?
> >
> > Some further thoughts…
> >
> > I think CEPs would benefit from describing their compatibility and
> > stability impacts, rather than trying to tie themselves to a
> > version, regardless of what context a specific version provides.
> >
> > Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what
> > about requests for waivers on each jira ticket as they are ready to land? I
> > suspect much of the work (once we see it) will be easier to agree to such
> > waivers than the only other position we have to stand by currently, which
> > is categories defined by SemVer. (A lot of people are really keen to see us
> > practice PATCH-only patch versions.) This also ties back to my request to
> > see a "rough timeline/plan of how the proposed changes are to be defined in
> > JIRAs and ordered."
> >
> > It's worth noting that the code divergence will happen between two branches
> > no matter what, e.g. 3.11, and next April is really not far away at all. Is
> > it really a problem if the LWT fix is also pushed back to 4.1 (though I
> > understand this is a bigger discussion) for the sake of driving home
> > we are a project now serious about stability?
> >
> > All in all, I am betting this discussion will be a lot more productive a)
> > when we see more of the work involved and its impact, and b) in a month or
> > two when we have better witnessed the stability of 4.0.0 and what has gone
> > into 4.0.1 and 4.0.2.
> >

-
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.0 (take2)

[Aleksey Yeschenko]

+1

> On 14 Jul 2021, at 15:37, Jonathan Ellis  wrote:
> 
> +1
> 
> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:
> 
>> Proposing the test build of Cassandra 4.0.0 for release.
>> 
>> sha1: 924bf92fab1820942137138c779004acaf834187
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
>> Maven Artifacts:
>> 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
>> 
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>> 
>> The vote will be open for 72 hours (longer if needed). Everyone who
>> has tested the build is invited to vote. Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding
>> +1s and no -1's.
>> 
>> [1]: CHANGES.txt:
>> 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced


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

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

[Jonathan Ellis]

+1

On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0.0 for release.
>
> sha1: 924bf92fab1820942137138c779004acaf834187
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

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

[Gary Dusbabek]

+1

On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0.0 for release.
>
> sha1: 924bf92fab1820942137138c779004acaf834187
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1242/org/apache/cassandra/cassandra-all/4.0.0/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.0/
>
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
>
> [1]: CHANGES.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.0-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[Joshua McKenzie]

>
> Yes, we should perhaps remove target version from the template, and
> introduce guidance on describing stability impact etc.

Strong +1 to remove this from the template. I got sucked into the mistake
of conflating implementation details and implications on where it lands
instead of staying high level in the "do we agree we need this".

And I'm a +1 on the "I agree we need this".


On Wed, Jul 14, 2021 at 7:32 AM bened...@apache.org 
wrote:

> > I think CEPs would benefit from describing their compatibility and
> stability impacts, rather than trying to tie themselves to a
> version, regardless of what context a specific version provides.
>
> Yes, we should perhaps remove target version from the template, and
> introduce guidance on describing stability impact etc.
>
> Regarding waivers, I’m not sure we’ve really agreed as a community what
> the criteria are for determining if work goes into a patch release – so I’m
> not sure it would be right to call it a waiver. But I agree that scheduling
> the release to contain some work should be a mixture of project roadmap
> planning (distinct from CEP), and Jira/dev list discussion near the point
> of merge.
>
> The question is if there is still value in the CEP pages maintaining the
> endeavour’s goal for when the work will be ready, but perhaps this can be
> communicated in normal date format, and used to inform project roadmap
> planning.
>
>
> From: Mick Semb Wever 
> Date: Wednesday, 14 July 2021 at 10:41
> To: dev@cassandra.apache.org 
> Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations
> >
> > PRs will land soon for people to look at, but honestly we’re getting into
> > an unnecessary tangle over target release. I think it would be a mistake
> to
> > push this to a later release, because it is valuable and it will bring
> pain
> > by creating divergence - but the question a CEP is meant to answer is
> _if_
> > the community wants a piece of work.
> >
> > Since it’s become an explicit point of contention, we can perhaps
> > disaggregate a vote on _when_ to happen in parallel, once discussion on
> > _if_ wraps up.
>
>
>
> Totally agree, can we remove the "Target Version" from the CEP, so the vote
> is based on the _if_ ?
>
> Some further thoughts…
>
> I think CEPs would benefit from describing their compatibility and
> stability impacts, rather than trying to tie themselves to a
> version, regardless of what context a specific version provides.
>
> Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what
> about requests for waivers on each jira ticket as they are ready to land? I
> suspect much of the work (once we see it) will be easier to agree to such
> waivers than the only other position we have to stand by currently, which
> is categories defined by SemVer. (A lot of people are really keen to see us
> practice PATCH-only patch versions.) This also ties back to my request to
> see a "rough timeline/plan of how the proposed changes are to be defined in
> JIRAs and ordered."
>
> It's worth noting that the code divergence will happen between two branches
> no matter what, e.g. 3.11, and next April is really not far away at all. Is
> it really a problem if the LWT fix is also pushed back to 4.1 (though I
> understand this is a bigger discussion) for the sake of driving home
> we are a project now serious about stability?
>
> All in all, I am betting this discussion will be a lot more productive a)
> when we see more of the work involved and its impact, and b) in a month or
> two when we have better witnessed the stability of 4.0.0 and what has gone
> into 4.0.1 and 4.0.2.
>

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

[Joshua McKenzie]

+1

On Wed, Jul 14, 2021 at 7:22 AM guo Maxwell  wrote:

> +1
>
> Paulo Motta  于2021年7月14日周三 下午7:03写道：
>
> > +1
> >
> > Em qua., 14 de jul. de 2021 às 05:10, Benjamin Lerer 
> > escreveu:
> >
> > > +1
> > >
> > > Le mer. 14 juil. 2021 à 09:48, Mick Semb Wever  a
> écrit
> > :
> > >
> > > > >
> > > > > The vote will be open for 72 hours (longer if needed). Everyone who
> > > > > has tested the build is invited to vote. Votes by PMC members are
> > > > > considered binding. A vote passes if there are at least three
> binding
> > > > > +1s and no -1's.
> > > > >
> > > >
> > > >
> > > > +1
> > > >
> > > >
> > > > Tested:
> > > > sha1, md5, sha256, sha512 match.
> > > > gpg signatures match.
> > > > Source artefact builds. (and doesn't contain compiled dependencies)
> > > > Tarball Binary artefact runs.
> > > > Debian binary package runs.
> > > > Redhat binary package runs.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>
>
> --
> you are the apple of my eye !
>

Re: [VOTE] CIP-9: Make SSLContext creation pluggable

[Joshua McKenzie]

+1

On Wed, Jul 14, 2021 at 7:03 AM Paulo Motta 
wrote:

> +1
>
> Em qua., 14 de jul. de 2021 às 02:29, Sumanth Pasupuleti <
> sumanth.pasupuleti...@gmail.com> escreveu:
>
> > +1 non-binding
> >
> > On Tue, Jul 13, 2021 at 10:05 PM Berenguer Blasi <
> berenguerbl...@gmail.com
> > >
> > wrote:
> >
> > > +1
> > >
> > > On 14/7/21 0:34, Nate McCall wrote:
> > > > +1
> > > >
> > > >
> > > > On Wed, Jul 14, 2021 at 2:49 AM Benjamin Lerer 
> > > wrote:
> > > >
> > > >> Hi everyone,
> > > >>
> > > >> I am proposing the CIP-9 (Make SSLContext creation pluggable) for
> > > adoption
> > > >>
> > > >> Discussion thread:
> > > >>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/rbf99c0108a65f5e31a8f8f0ee525816ee0a387a6fae64de86ceb1495%40%3Cdev.cassandra.apache.org%3E
> > > >>
> > > >>
> > > >> The vote will be open for 72 hours.
> > > >> Votes by PMC members are considered binding. A
> > > >> vote passes if there are at least three binding +1s and no binding
> > > vetoes.
> > > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[bened...@apache.org]

> I think CEPs would benefit from describing their compatibility and
stability impacts, rather than trying to tie themselves to a
version, regardless of what context a specific version provides.

Yes, we should perhaps remove target version from the template, and introduce 
guidance on describing stability impact etc.

Regarding waivers, I’m not sure we’ve really agreed as a community what the 
criteria are for determining if work goes into a patch release – so I’m not 
sure it would be right to call it a waiver. But I agree that scheduling the 
release to contain some work should be a mixture of project roadmap planning 
(distinct from CEP), and Jira/dev list discussion near the point of merge.

The question is if there is still value in the CEP pages maintaining the 
endeavour’s goal for when the work will be ready, but perhaps this can be 
communicated in normal date format, and used to inform project roadmap planning.


From: Mick Semb Wever 
Date: Wednesday, 14 July 2021 at 10:41
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations
>
> PRs will land soon for people to look at, but honestly we’re getting into
> an unnecessary tangle over target release. I think it would be a mistake to
> push this to a later release, because it is valuable and it will bring pain
> by creating divergence - but the question a CEP is meant to answer is _if_
> the community wants a piece of work.
>
> Since it’s become an explicit point of contention, we can perhaps
> disaggregate a vote on _when_ to happen in parallel, once discussion on
> _if_ wraps up.



Totally agree, can we remove the "Target Version" from the CEP, so the vote
is based on the _if_ ?

Some further thoughts…

I think CEPs would benefit from describing their compatibility and
stability impacts, rather than trying to tie themselves to a
version, regardless of what context a specific version provides.

Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what
about requests for waivers on each jira ticket as they are ready to land? I
suspect much of the work (once we see it) will be easier to agree to such
waivers than the only other position we have to stand by currently, which
is categories defined by SemVer. (A lot of people are really keen to see us
practice PATCH-only patch versions.) This also ties back to my request to
see a "rough timeline/plan of how the proposed changes are to be defined in
JIRAs and ordered."

It's worth noting that the code divergence will happen between two branches
no matter what, e.g. 3.11, and next April is really not far away at all. Is
it really a problem if the LWT fix is also pushed back to 4.1 (though I
understand this is a bigger discussion) for the sake of driving home
we are a project now serious about stability?

All in all, I am betting this discussion will be a lot more productive a)
when we see more of the work involved and its impact, and b) in a month or
two when we have better witnessed the stability of 4.0.0 and what has gone
into 4.0.1 and 4.0.2.

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

[guo Maxwell]

+1

Paulo Motta  于2021年7月14日周三 下午7:03写道：

> +1
>
> Em qua., 14 de jul. de 2021 às 05:10, Benjamin Lerer 
> escreveu:
>
> > +1
> >
> > Le mer. 14 juil. 2021 à 09:48, Mick Semb Wever  a écrit
> :
> >
> > > >
> > > > The vote will be open for 72 hours (longer if needed). Everyone who
> > > > has tested the build is invited to vote. Votes by PMC members are
> > > > considered binding. A vote passes if there are at least three binding
> > > > +1s and no -1's.
> > > >
> > >
> > >
> > > +1
> > >
> > >
> > > Tested:
> > > sha1, md5, sha256, sha512 match.
> > > gpg signatures match.
> > > Source artefact builds. (and doesn't contain compiled dependencies)
> > > Tarball Binary artefact runs.
> > > Debian binary package runs.
> > > Redhat binary package runs.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>


-- 
you are the apple of my eye !

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

[Paulo Motta]

+1

Em qua., 14 de jul. de 2021 às 05:10, Benjamin Lerer 
escreveu:

> +1
>
> Le mer. 14 juil. 2021 à 09:48, Mick Semb Wever  a écrit :
>
> > >
> > > The vote will be open for 72 hours (longer if needed). Everyone who
> > > has tested the build is invited to vote. Votes by PMC members are
> > > considered binding. A vote passes if there are at least three binding
> > > +1s and no -1's.
> > >
> >
> >
> > +1
> >
> >
> > Tested:
> > sha1, md5, sha256, sha512 match.
> > gpg signatures match.
> > Source artefact builds. (and doesn't contain compiled dependencies)
> > Tarball Binary artefact runs.
> > Debian binary package runs.
> > Redhat binary package runs.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] CIP-9: Make SSLContext creation pluggable

[Paulo Motta]

+1

Em qua., 14 de jul. de 2021 às 02:29, Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> escreveu:

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

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

[Mick Semb Wever]

>
> PRs will land soon for people to look at, but honestly we’re getting into
> an unnecessary tangle over target release. I think it would be a mistake to
> push this to a later release, because it is valuable and it will bring pain
> by creating divergence - but the question a CEP is meant to answer is _if_
> the community wants a piece of work.
>
> Since it’s become an explicit point of contention, we can perhaps
> disaggregate a vote on _when_ to happen in parallel, once discussion on
> _if_ wraps up.



Totally agree, can we remove the "Target Version" from the CEP, so the vote
is based on the _if_ ?

Some further thoughts…

I think CEPs would benefit from describing their compatibility and
stability impacts, rather than trying to tie themselves to a
version, regardless of what context a specific version provides.

Rather than a subsequent vote on the CEP trying to get it into 4.0.x, what
about requests for waivers on each jira ticket as they are ready to land? I
suspect much of the work (once we see it) will be easier to agree to such
waivers than the only other position we have to stand by currently, which
is categories defined by SemVer. (A lot of people are really keen to see us
practice PATCH-only patch versions.) This also ties back to my request to
see a "rough timeline/plan of how the proposed changes are to be defined in
JIRAs and ordered."

It's worth noting that the code divergence will happen between two branches
no matter what, e.g. 3.11, and next April is really not far away at all. Is
it really a problem if the LWT fix is also pushed back to 4.1 (though I
understand this is a bigger discussion) for the sake of driving home
we are a project now serious about stability?

All in all, I am betting this discussion will be a lot more productive a)
when we see more of the work involved and its impact, and b) in a month or
two when we have better witnessed the stability of 4.0.0 and what has gone
into 4.0.1 and 4.0.2.

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

[Benjamin Lerer]

+1

Le mer. 14 juil. 2021 à 09:48, Mick Semb Wever  a écrit :

> >
> > The vote will be open for 72 hours (longer if needed). Everyone who
> > has tested the build is invited to vote. Votes by PMC members are
> > considered binding. A vote passes if there are at least three binding
> > +1s and no -1's.
> >
>
>
> +1
>
>
> Tested:
> sha1, md5, sha256, sha512 match.
> gpg signatures match.
> Source artefact builds. (and doesn't contain compiled dependencies)
> Tarball Binary artefact runs.
> Debian binary package runs.
> Redhat binary package runs.
>
> -
> 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.0 (take2)

[Mick Semb Wever]

>
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
>


+1


Tested:
sha1, md5, sha256, sha512 match.
gpg signatures match.
Source artefact builds. (and doesn't contain compiled dependencies)
Tarball Binary artefact runs.
Debian binary package runs.
Redhat binary package runs.

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

Re: Number of DCs in Cassandra

[Erick Ramirez]

Noting here that the same question was asked and answered in the users@ ML.
Cheers!

Number of DCs in Cassandra

[Shaurya Gupta]

Hi

Does someone have any suggestions on the maximum number of Data Centers
which NetworkTopology strategy can have for a keyspace. Not only
technically but considering performance as well.
In each Data Center RF is 3.

Thanks!
--
Shaurya Gupta