Re: [VOTE] Release dtest-api 0.0.14

2023-05-16 Thread Andrés de la Peña
+1

On Tue, 16 May 2023 at 07:24, Alex Petrov  wrote:

> +1
>
> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote:
>
> +1 (nb)
>
> Doug Rohrer
>
> > On May 15, 2023, at 7:17 PM, Brandon Williams  wrote:
> >
> > +1
> >
> > Kind Regards,
> > Brandon
> >
> >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi  wrote:
> >>
> >> Proposing the test build of in-jvm dtest API 0.0.14 for release.
> >>
> >> Repository:
> >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
> >>
> >> Candidate SHA:
> >>
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
> >> tagged with 0.0.14
> >>
> >> Artifacts:
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/
> >>
> >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
> >>
> >> Changes since last release:
> >>
> >> * CASSANDRA-18511: Add support for JMX in jvm-dtest
> >>
> >> The vote will be open for 24 hours. 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.
>
>


Re: Cassandra 4.0-beta1 available on FreeBSD

2023-05-16 Thread Lapo Luchini

Now updated to 4.0.8! 🎉
(yes, I know, 4.0.9 was released during the process…)

Next step will be to upgrade to 4.1.

cheers,
  Lapo

On 2020-07-27 19:28, Ekaterina Dimitrova wrote:

Thank you Angelo for supporting the project with this! Truly appreciate it!

Best,
Ekaterina

On Mon, 27 Jul 2020 at 13:13, Angelo Polo  wrote:


Cassandra 4.0-beta1 is now available on FreeBSD.

You can find information about the port here:
https://www.freshports.org/databases/cassandra4/

The beta can be installed from an up-to-date ports tree under
databases/cassandra4.

Best,
Angelo




Re: Cassandra 4.0-beta1 available on FreeBSD

2023-05-16 Thread Miklosovic, Stefan
Great stuff, Lapo!

I was looking into FreeBSD ports few days ago to see what Cassandra version it 
supports as I have BSDs as a hobby ...

Can't wait until I see 4.1!

BTW I noticed there is quite a lot of patches to make Cassandra run on FreeBSD 
(1). Would you be maybe interesting in submitting patches for changes you did 
(when applicable) so you do not need to patch it yourself in your port?

(1) https://cgit.freebsd.org/ports/tree/databases/cassandra4/files

Regards


From: Lapo Luchini 
Sent: Tuesday, May 16, 2023 13:05
To: dev@cassandra.apache.org
Subject: Re: Cassandra 4.0-beta1 available on FreeBSD

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Now updated to 4.0.8! 🎉
(yes, I know, 4.0.9 was released during the process…)

Next step will be to upgrade to 4.1.

cheers,
   Lapo

On 2020-07-27 19:28, Ekaterina Dimitrova wrote:
> Thank you Angelo for supporting the project with this! Truly appreciate it!
>
> Best,
> Ekaterina
>
> On Mon, 27 Jul 2020 at 13:13, Angelo Polo  wrote:
>
>> Cassandra 4.0-beta1 is now available on FreeBSD.
>>
>> You can find information about the port here:
>> https://www.freshports.org/databases/cassandra4/
>>
>> The beta can be installed from an up-to-date ports tree under
>> databases/cassandra4.
>>
>> Best,
>> Angelo



Re: [VOTE] Release dtest-api 0.0.14

2023-05-16 Thread Jon Meredith
+1

On Tue, May 16, 2023 at 3:39 AM Andrés de la Peña 
wrote:

> +1
>
> On Tue, 16 May 2023 at 07:24, Alex Petrov  wrote:
>
>> +1
>>
>> On Tue, May 16, 2023, at 4:45 AM, Doug Rohrer wrote:
>>
>> +1 (nb)
>>
>> Doug Rohrer
>>
>> > On May 15, 2023, at 7:17 PM, Brandon Williams  wrote:
>> >
>> > +1
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> >> On Mon, May 15, 2023 at 5:12 PM Dinesh Joshi 
>> wrote:
>> >>
>> >> Proposing the test build of in-jvm dtest API 0.0.14 for release.
>> >>
>> >> Repository:
>> >> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
>> >>
>> >> Candidate SHA:
>> >>
>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
>> >> tagged with 0.0.14
>> >>
>> >> Artifacts:
>> >>
>> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/
>> >>
>> >> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
>> >>
>> >> Changes since last release:
>> >>
>> >> * CASSANDRA-18511: Add support for JMX in jvm-dtest
>> >>
>> >> The vote will be open for 24 hours. 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.
>>
>>


Re: [DISCUSS] The future of CREATE INDEX

2023-05-16 Thread Caleb Rackliffe
I might as well weigh in...

[POLL] Centralize existing syntax or create new syntax?

1.) CREATE INDEX ... USING ... WITH OPTIONS...

(I think the more important protection for users WRT local indexes should
come in the form of a guardrail prohibiting scatter/gather queries against
them.)

[POLL] Should there be a default? (YES/NO)

Yes

[POLL] What do do with the default?

3.) and 4.) Allow both configuring a default and disabling the default
concept entirely. (Both of these are creation-time items, just like the
current guardrails we have around 2i creation and SASI disabling.)

(No defaults should change, but administrators can lock this down/change
the default index without much effort.)

On Mon, May 15, 2023 at 10:52 PM guo Maxwell  wrote:

> [POLL] Centralize existing syntax or create new syntax?
>
>
> 1.) CREATE INDEX ... USING  WITH OPTIONS...
>
> and I  think we should keep CREATE CUSTOM INDEX
>
> [POLL] Should there be a default? (YES/NO)
>
>
> of course  YES
>
> [POLL] What do do with the default?
>
>
> 4.) YAML config/guardrail to require index type selection (not required by
> default)
>
>
>
> Jonathan Ellis  于2023年5月16日周二 07:18写道:
>
>> On Fri, May 12, 2023 at 1:39 PM Caleb Rackliffe 
>> wrote:
>>
>>> [POLL] Centralize existing syntax or create new syntax?
>>>
>>
>> 1 (Existing)
>>
>> [POLL] Should there be a default? (YES/NO)
>>>
>>
>> YES
>>
>>
>>> [POLL] What do do with the default?
>>>
>>
>> 1 (Default SAI)
>>
>>
>
>
> --
> you are the apple of my eye !
>


[DISCUSS] Bring cassandra-harry in tree as a submodule

2023-05-16 Thread Josh McKenzie
Similar to what we've done with accord in 
https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss 
bringing cassandra-harry in-tree as a submodule. repo link: 
https://github.com/apache/cassandra-harry

Given the value it's brought to the project's stabilization efforts and the 
movement of other things in the ecosystem to being more integrated (accord, 
build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I think 
having the testing framework better localized and integrated would be a net 
benefit for adoption, awareness, maintenance, and tighter workflows as we 
troubleshoot future failures it surfaces.

I'd also like to see us get a Harry run integrated as part of our pre-commit CI 
(a 5 minute simple soak test for instance) and having that local in this 
fashion should make that a cleaner integration as well.

Thoughts?

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

2023-05-16 Thread Abe Ratnofsky
Just to make sure I'm understanding the details, this would mean 
apache/cassandra-harry maintains its status as a separate repository, 
apache/cassandra references it as a submodule, and clones and builds Harry 
locally, rather than pulling a released JAR. We can then reference Harry as a 
library without maintaining public artifacts for it. Is that in line with what 
you're thinking?

> I'd also like to see us get a Harry run integrated as part of our pre-commit 
> CI

I'm a strong supporter of this, of course.

> On May 16, 2023, at 11:03 AM, Josh McKenzie  wrote:
> 
> Similar to what we've done with accord in 
> https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss 
> bringing cassandra-harry in-tree as a submodule. repo link: 
> https://github.com/apache/cassandra-harry
> 
> Given the value it's brought to the project's stabilization efforts and the 
> movement of other things in the ecosystem to being more integrated (accord, 
> build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I think 
> having the testing framework better localized and integrated would be a net 
> benefit for adoption, awareness, maintenance, and tighter workflows as we 
> troubleshoot future failures it surfaces.
> 
> I'd also like to see us get a Harry run integrated as part of our pre-commit 
> CI (a 5 minute simple soak test for instance) and having that local in this 
> fashion should make that a cleaner integration as well.
> 
> Thoughts?



[DISCUSS] Feature branch version hygiene

2023-05-16 Thread J. D. Jordan
Process question/discussion. Should tickets that are merged to CEP feature 
branches, like  https://issues.apache.org/jira/browse/CASSANDRA-18204, have a 
fixver of 5.0 on them After merging to the feature branch?

For the SAI CEP which is also using the feature branch method the "reviewed and 
merged to feature branch" tickets seem to be given a version of NA.

Not sure that's the best “waiting for cep to merge” version either?  But it 
seems better than putting 5.0 on them to me.

Why I’m not keen on 5.0 is because if we cut the release today those tickets 
would not be there.

What do other people think?  Is there a better version designation we can use?

On a different project I have in the past made a “version number” in JIRA for 
each long running feature branch. Tickets merged to the feature branch got the 
epic ticket number as their version, and then it got updated to the “real” 
version when the feature branch was merged to trunk.

-Jeremiah


Re: [DISCUSS] Feature branch version hygiene

2023-05-16 Thread Benedict
Copying my rely on the ticket…

We have this discussion roughly once per major. If you look back through dev@ 
you'll find the last one a few years back.
I don't recall NA ever being the approved approach, though. ".x" lines are 
target versions, whereas concrete versions are the ones a fix landed in. 
There's always ambiguity over the next release, as it's sort of both. But since 
there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0, perhaps 5.0 is 
the correct label (and makes sense to me). I forget what we landed upon last 
time.
Work that has actually landed should probably be labelled as 5.0-alpha1

> On 16 May 2023, at 21:02, J. D. Jordan  wrote:
> 
> 
> Process question/discussion. Should tickets that are merged to CEP feature 
> branches, like  https://issues.apache.org/jira/browse/CASSANDRA-18204, have a 
> fixver of 5.0 on them After merging to the feature branch?
> 
> For the SAI CEP which is also using the feature branch method the "reviewed 
> and merged to feature branch" tickets seem to be given a version of NA.
> 
> Not sure that's the best “waiting for cep to merge” version either?  But it 
> seems better than putting 5.0 on them to me.
> 
> Why I’m not keen on 5.0 is because if we cut the release today those tickets 
> would not be there.
> 
> What do other people think?  Is there a better version designation we can use?
> 
> On a different project I have in the past made a “version number” in JIRA for 
> each long running feature branch. Tickets merged to the feature branch got 
> the epic ticket number as their version, and then it got updated to the 
> “real” version when the feature branch was merged to trunk.
> 
> -Jeremiah


Re: [DISCUSS] Feature branch version hygiene

2023-05-16 Thread Caleb Rackliffe
I like the NA approach for sub-tasks that roll up to a parent/epic ticket.
When that lands, it gets a real version, and any sub-task is assumed to
also have that version.

Not that it has to be called "NA", but there should be something to denote
"inherits from parent".

On Tue, May 16, 2023 at 3:04 PM Benedict  wrote:

> Copying my rely on the ticket…
>
>
> We have this discussion roughly once per major. If you look back through
> dev@ you'll find the last one a few years back.
>
> I don't recall NA ever being the approved approach, though. ".x" lines are
> target versions, whereas concrete versions are the ones a fix landed in.
> There's always ambiguity over the next release, as it's sort of both. But
> since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
> landed upon last time.
>
> Work that has actually landed should probably be labelled as 5.0-alpha1
>
> On 16 May 2023, at 21:02, J. D. Jordan  wrote:
>
> 
>
> Process question/discussion. Should tickets that are merged to CEP feature
> branches, like  https://issues.apache.org/jira/browse/CASSANDRA-18204, have
> a fixver of 5.0 on them After merging to the feature branch?
>
>
> For the SAI CEP which is also using the feature branch method the
> "reviewed and merged to feature branch" tickets seem to be given a version
> of NA.
>
>
> Not sure that's the best “waiting for cep to merge” version either?  But
> it seems better than putting 5.0 on them to me.
>
>
> Why I’m not keen on 5.0 is because if we cut the release today those
> tickets would not be there.
>
>
> What do other people think?  Is there a better version designation we can
> use?
>
>
> On a different project I have in the past made a “version number” in JIRA
> for each long running feature branch. Tickets merged to the feature branch
> got the epic ticket number as their version, and then it got updated to the
> “real” version when the feature branch was merged to trunk.
>
>
> -Jeremiah
>
>


Re: [DISCUSS] Feature branch version hygiene

2023-05-16 Thread Caleb Rackliffe
...but that and "What do we do with things that might be in 5.0 and might
not?" are different questions.

A version that denotes "next major release" until merged (at which point it
could be given a real version) could be helpful...

On Tue, May 16, 2023 at 3:28 PM Caleb Rackliffe 
wrote:

> I like the NA approach for sub-tasks that roll up to a parent/epic ticket.
> When that lands, it gets a real version, and any sub-task is assumed to
> also have that version.
>
> Not that it has to be called "NA", but there should be something to denote
> "inherits from parent".
>
> On Tue, May 16, 2023 at 3:04 PM Benedict  wrote:
>
>> Copying my rely on the ticket…
>>
>>
>> We have this discussion roughly once per major. If you look back through
>> dev@ you'll find the last one a few years back.
>>
>> I don't recall NA ever being the approved approach, though. ".x" lines
>> are target versions, whereas concrete versions are the ones a fix landed
>> in. There's always ambiguity over the next release, as it's sort of both.
>> But since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
>> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
>> landed upon last time.
>>
>> Work that has actually landed should probably be labelled as 5.0-alpha1
>>
>> On 16 May 2023, at 21:02, J. D. Jordan  wrote:
>>
>> 
>>
>> Process question/discussion. Should tickets that are merged to CEP
>> feature branches, like
>> https://issues.apache.org/jira/browse/CASSANDRA-18204, have a fixver of
>> 5.0 on them After merging to the feature branch?
>>
>>
>> For the SAI CEP which is also using the feature branch method the
>> "reviewed and merged to feature branch" tickets seem to be given a version
>> of NA.
>>
>>
>> Not sure that's the best “waiting for cep to merge” version either?  But
>> it seems better than putting 5.0 on them to me.
>>
>>
>> Why I’m not keen on 5.0 is because if we cut the release today those
>> tickets would not be there.
>>
>>
>> What do other people think?  Is there a better version designation we can
>> use?
>>
>>
>> On a different project I have in the past made a “version number” in JIRA
>> for each long running feature branch. Tickets merged to the feature branch
>> got the epic ticket number as their version, and then it got updated to the
>> “real” version when the feature branch was merged to trunk.
>>
>>
>> -Jeremiah
>>
>>


Re: [DISCUSS] Feature branch version hygiene

2023-05-16 Thread Ekaterina Dimitrova
I do not think we discussed it from feature branch perspective. (Happy to
stand corrected but I did not find anything in @dev archive myself) But we
do mark with 5.0 anything that lands in trunk. I think it might be a good
idea anything that lands in a feature branch to have different fix version
until the feature branch is merged.

“ Why I’m not keen on 5.0 is because if we cut the release today those
tickets would not be there.”

I guess it can make it easier also from Release Management process as if I
remember correctly there is a script that changes potentially all tickets
resolved with major version (in this case 5.0) to 5.0-alpha or whatever we
stop on to be the release version.

Though NA can be confusing I guess. Shall we use something like
5.0-candidate, 6.0-candidate? This can be based on the confidence people
have around a feature branch, where it can potentially land. I am curious
how other projects do it too.

I think it is a good call to decide on something and document it. I can
imagine it will be also easier during release management. Thank you
Jeremiah for raising the topic

Best regards,
Ekaterina


On Tue, 16 May 2023 at 16:04, Benedict  wrote:

> Copying my rely on the ticket…
>
>
> We have this discussion roughly once per major. If you look back through
> dev@ you'll find the last one a few years back.
>
> I don't recall NA ever being the approved approach, though. ".x" lines are
> target versions, whereas concrete versions are the ones a fix landed in.
> There's always ambiguity over the next release, as it's sort of both. But
> since there is no 5.0 version, only 5.0-alphaN, 5.0-betaN and 5.0.0,
> perhaps 5.0 is the correct label (and makes sense to me). I forget what we
> landed upon last time.
>
> Work that has actually landed should probably be labelled as 5.0-alpha1
>
> On 16 May 2023, at 21:02, J. D. Jordan  wrote:
>
> 
>
> Process question/discussion. Should tickets that are merged to CEP feature
> branches, like  https://issues.apache.org/jira/browse/CASSANDRA-18204, have
> a fixver of 5.0 on them After merging to the feature branch?
>
>
> For the SAI CEP which is also using the feature branch method the
> "reviewed and merged to feature branch" tickets seem to be given a version
> of NA.
>
>
> Not sure that's the best “waiting for cep to merge” version either?  But
> it seems better than putting 5.0 on them to me.
>
>
> Why I’m not keen on 5.0 is because if we cut the release today those
> tickets would not be there.
>
>
> What do other people think?  Is there a better version designation we can
> use?
>
>
> On a different project I have in the past made a “version number” in JIRA
> for each long running feature branch. Tickets merged to the feature branch
> got the epic ticket number as their version, and then it got updated to the
> “real” version when the feature branch was merged to trunk.
>
>
> -Jeremiah
>
>


Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

2023-05-16 Thread Jeremy Hanna
I think it would be great to onboard Harry more officially into the project.  
However it would be nice to perhaps do some sanity checking outside of Apple 
folks to see how approachable it is.  That is, can someone take it and just run 
it with the current readme without any additional context?

I wonder if a mini-onboarding session would be good as a community session - go 
over Harry, how to run it, how to add a test?  Would that be the right venue?  
I just would like to see how we can not only plug it in to regular CI but get 
everyone that wants to add a test be able to know how to get started with it.

Jeremy

> On May 16, 2023, at 1:34 PM, Abe Ratnofsky  wrote:
> 
> Just to make sure I'm understanding the details, this would mean 
> apache/cassandra-harry maintains its status as a separate repository, 
> apache/cassandra references it as a submodule, and clones and builds Harry 
> locally, rather than pulling a released JAR. We can then reference Harry as a 
> library without maintaining public artifacts for it. Is that in line with 
> what you're thinking?
> 
> > I'd also like to see us get a Harry run integrated as part of our 
> > pre-commit CI
> 
> I'm a strong supporter of this, of course.
> 
>> On May 16, 2023, at 11:03 AM, Josh McKenzie  wrote:
>> 
>> Similar to what we've done with accord in 
>> https://issues.apache.org/jira/browse/CASSANDRA-18204, I'd like to discuss 
>> bringing cassandra-harry in-tree as a submodule. repo link: 
>> https://github.com/apache/cassandra-harry
>> 
>> Given the value it's brought to the project's stabilization efforts and the 
>> movement of other things in the ecosystem to being more integrated (accord, 
>> build-scripts https://issues.apache.org/jira/browse/CASSANDRA-18133), I 
>> think having the testing framework better localized and integrated would be 
>> a net benefit for adoption, awareness, maintenance, and tighter workflows as 
>> we troubleshoot future failures it surfaces.
>> 
>> I'd also like to see us get a Harry run integrated as part of our pre-commit 
>> CI (a 5 minute simple soak test for instance) and having that local in this 
>> fashion should make that a cleaner integration as well.
>> 
>> Thoughts?
> 



Re: [VOTE] Release dtest-api 0.0.14

2023-05-16 Thread Dinesh Joshi
Vote passes with 7 +1s and no -1s.

thanks everybody.

On 5/15/23 15:12, Dinesh Joshi wrote:
> Proposing the test build of in-jvm dtest API 0.0.14 for release.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
> 
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/ea4b44e0ed0a4f0bbe9b18fb40ad927b49a73a32
> tagged with 0.0.14
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1289/org/apache/cassandra/dtest-api/0.0.14/
> 
> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
> 
> Changes since last release:
> 
> * CASSANDRA-18511: Add support for JMX in jvm-dtest
> 
> The vote will be open for 24 hours. 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.