Re: [VOTE] CEP-25: Trie-indexed SSTable format

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Dec 19, 2022 at 6:59 AM Branimir Lambov  wrote:
>
> Hi everyone,
>
> I'd like to propose CEP-25 for approval.
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format
> Discussion: https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh
>
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding vetoes.
>
> Thank you,
> Branimir

Re: [DISCUSS] Slack notifications for new Stack Overflow, Stack Exchange questions

[Brandon Williams]

I find it to be more noise than signal thus far.  I noticed it had
been added and put it on my list to ask for it to be removed, since it
seemed to just randomly appear, but I guess we can give it more time.

On Mon, Dec 19, 2022 at 7:06 AM Mick Semb Wever  wrote:
>
>
>> In any case, does anyone have concerns about the notifications in Slack? Do 
>> you foresee any issues with it? Cheers!
>
>
>
> Thanks for writing it up Erick. Perfectly fine to have a bias for action 
> here, it being an easy-to-undo action.
> No objections, my only concern is if it is considered too noisy by some and 
> reduces interaction on #cassandra
> Can you take a poll there to gauge folks' receptiveness to it?

Re: Jira account for bartoszewiczja...@gmail.com

[Brandon Williams]

Your account has been created.

Kind Regards,
Brandon

On Tue, Dec 20, 2022 at 10:42 AM Jakub Bartoszewicz
 wrote:
>
> Hello team,
>
> Issue:
> I would like to request for a Jira account as it is described under this page:
> https://infra.apache.org/jira-guidelines.html#who
>
> Reason:
> I need it to participate in a following issue:
> https://issues.apache.org/jira/browse/CASSANDRA-16555
>
> Data needed for account creation:
>
> email address: bartoszewiczja...@gmail.com
> preferred username: bjaku
>
> Looking forward for your response and I wish you Merry Christmas and a Happy 
> New Year.
>
> Thanks,
> Kuba

Re: upgrade sstable selection

[Brandon Williams]

> I think this means that the Directories.SSTableLister on occasion returns 
> files in the incorrect order during a call to lister.list().entrySet()

This seems easy enough to verify by looping it and examining the results.

Kind Regards,
Brandon

On Tue, Jan 10, 2023 at 4:44 AM Claude Warren, Jr via dev
 wrote:
>
> Greetings,
>
> I am working on the downgradesstables code and seem to have a problem with 
> ordering of the downgrade or perhaps the Directories.SSTableLister
>
> I lifted the code from upgradesstables to select the files to downgrade.  The 
> only difference in the code that selects the files to downgrade is the actual 
> selection of the file.  There is no change to the ordering of the files that 
> are evaluated for inclusion.  Yet I think the downgrade ordering is incorrect.
>
> My process is to start 3.1 version to create the tables and then use the 4.0 
> code base to run the standaloneupgrader and then the standalonedowngrader
>
> When running the standaloneupgrader on system local I see the following
> {{noformat}}
> Found 3 sstables that need upgrading.
> Upgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-1-big-Data.db')
> Upgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-1-big-Data.db')
>  complete.
> Upgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-2-big-Data.db')
> Upgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-2-big-Data.db')
>  complete.
> Upgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-3-big-Data.db')
> Upgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/ma-3-big-Data.db')
>  complete.
> {{noformat}}
>
> when running the standalonedowngrader is see
> {{noformat}}
> Found 3 sstables that need downgrading.
> Downgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-6-big-Data.db')
> Downgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-6-big-Data.db')
>  complete.
> Downgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-4-big-Data.db')
> Downgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-4-big-Data.db')
>  complete.
> Downgrading 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-5-big-Data.db')
> Downgrade of 
> BigTableReader(path='/var/lib/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-5-big-Data.db')
>  complete.
> {{noformat}}}
>
> Note the order of the generations in the downgrader (I have seen similar out 
> of order issues with the upgrader, but infrequently)
>
> The difference between the upgrader and downgrader code in the questionable 
> section 
> (https://github.com/Claudenw/cassandra/blob/CASSANDRA-8928/src/java/org/apache/cassandra/tools/StandaloneDowngrader.java#:~:text=new%20ArrayList%3C%3E()%3B-,//%20Downgrade%20sstables,%7D,-int%20numSSTables%20%3D)
>  is on line 101 where the files are selected and put into a list.  I think 
> this means that the Directories.SSTableLister on occasion returns files in 
> the incorrect order during a call to lister.list().entrySet()
>
> I believe that the files are processed in the order specified and that the 
> generations get switched around.  This is evidenced by the file size of the 
> Data file associated with the generations as it moves through the process.  
> In this case we expect the nb-6 to become ma-7 as per the output from the 
> run.  In actuality we want nb-6 to be nb-9.
>
> {{noformat}}
>   ma   nb  ma
> 1  212 4  2128  212
> 2   64 5   709   70
> 3 4876 6 48837 4883
> {{noformat}}
>
> So now my question, has anyone seen the behaviour before?
>
> Oh, to make things more interesting I am using Docker images of 3.1 and a 
> modified 4.0 that turns off the execution so I can just run the upgrade and 
> downgrade.
>
> Any help would be appreciated,
> Claude

Re: Introducing mockito-inline library among test dependencies

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Jan 11, 2023 at 2:02 PM Miklosovic, Stefan
 wrote:
>
> Hi list,
>
> the test for (1) is using mockito-inline dependency for mocking static 
> methods as mockito-core is not able to do that on its own. mockito-inline was 
> not part of our test dependencies prior this work. I want to ask if we are 
> all OK with being able to mock static methods from now on with the help of 
> this library.
>
> Please tell me if we are mocking static methods already by some other (to me 
> yet unknown) mean so we do not include this unnecessarily.
>
> G:A:V is org.mockito:mockito-inline:4.7.0
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-14361
>
> Thanks

Re: Add to slack workspace

[Brandon Williams]

You have been invited.

Kind Regards,
Brandon

On Thu, Jan 12, 2023 at 11:31 AM kamalesh palanisamy
 wrote:
>
> Hi,
> I am new and looking to contribute to the Cassandra project. Can someone send 
> me an invite to the cassandra-dev channel? My email address is 
> kamalesh...@gmail.com .
> Thanks,
> Kamalesh P

Re: Intra-project dependencies

[Brandon Williams]

On Fri, Jan 20, 2023, 8:31 AM Mick Semb Wever  wrote:

> Both a git post-checkout and a build fail-fast will protect us here. But
>> the post-checkout will need to fail silently if the .git subdirectory
>> doesn't exist.
>>
>
>
> Correction: the build fail-fast will need to fail silently if the .git
> subdirectory doesn't exist.
>

How will this work for users downloading source distributions?

Re: Welcome Patrick McFadin as Cassandra Committer

[Brandon Williams]

Congratulations, Patrick!

Kind Regards,
Brandon

On Thu, Feb 2, 2023 at 11:58 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and its 
> community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

Re: [DISCUSS] Merging incremental feature work

[Brandon Williams]

On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie  wrote:
>
> My current thinking: I'd like to propose we all agree to move to merge work 
> into trunk incrementally if it's either:
> 1) New JDK support
> 2) An approved CEP

So basically everything?  I'm not sure what large complex bodies of
work would be left.

Re: [VOTE] CEP-21 Transactional Cluster Metadata

[Brandon Williams]

+1

On Mon, Feb 6, 2023, 10:15 AM Sam Tunnicliffe  wrote:

> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>
> Discussion:
> https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7
>
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>
> Thanks,
> Sam
>

Re: [VOTE] Release Apache Cassandra 4.0.8

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Feb 9, 2023 at 4:56 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 4.0.8 for release.
>
> sha1: 32c56df067b72da8593c1ddaaf143fe8668459dd
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.8-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1283/org/apache/cassandra/cassandra-all/4.0.8/
>
> 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.8/
>
> 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.8-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.8-tentative

Re: [DISCUSS] Should separate snapshots with the same name be allowed in different tables?

[Brandon Williams]

On Sun, Mar 5, 2023 at 11:00 PM Paulo Motta  wrote:
> I found this a bit surprising, since I would expect a snapshot with the same 
> name on different tables to represent the same logical snapshot taken at the 
> same point-in-time.

I would expect this too, 100%.

> This affects the design of the snapshots virtual table schema on 
> CASSANDRA-18102[1] because the timestamp needs to be included in the primary 
> key to allow distinguishing between different snapshots with the same name, 
> which seems a bit counter-intuitive.
>
> I think we should disallow creating a snapshot if another snapshot already 
> exists with the same name in any other table, so snapshots with the same name 
> on different tables are guaranteed to belong to the same logical 
> point-in-time snapshot.

I agree.  Even if there is a use case for that behavior, it will
almost certainly mislead someone later.

Kind Regards,
Brandon

Re: Removal of DateTieredCompactionStrategy in 5.0

[Brandon Williams]

Yes.

Kind Regards,
Brandon

On Tue, Mar 7, 2023 at 9:14 AM Miklosovic, Stefan
 wrote:
>
> Hi list,
>
> I want to highlight this ticket (1). I was waiting for trunk being on version 
> "5.0" officially so we can get rid of this compaction strategy which was 
> deprecated in 3.8. If we waited one major with deprecated strategy (4.0), I 
> think it is eligible for the actual deletion in the next major which is 5.0.
>
> Are people OK with the removal of DTCS in 5.0?
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-18043
> (2) https://github.com/apache/cassandra/pull/2015
>
> Regards

Re: [RELEASE] Apache Cassandra 4.0.8 released

[Brandon Williams]

It was reported in CASSANDRA-18307 that the Debian and Redhat packages
for 4.0.8 did not make it to the jfrog repository - this has now been
corrected, sorry for any inconvenience.

Kind Regards,
Brandon

On Tue, Feb 14, 2023 at 3:39 PM Miklosovic, Stefan
 wrote:
>
> The Cassandra team is pleased to announce the release of Apache Cassandra 
> version 4.0.8.
>
> Apache Cassandra is a fully distributed database. It is the right choice when 
> you need scalability and high availability without compromising performance.
>
>  http://cassandra.apache.org/
>
> Downloads of source and binary distributions are listed in our download 
> section:
>
>  http://cassandra.apache.org/download/
>
> This version is a bug fix release[1] on the 4.0 series. As always, please pay 
> attention to the release notes[2] and Let us know[3] if you were to encounter 
> any problem.
>
> [WARNING] Debian and RedHat package repositories have moved! Debian 
> /etc/apt/sources.list.d/cassandra.sources.list and RedHat 
> /etc/yum.repos.d/cassandra.repo files must be updated to the new repository 
> URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat 
> it is now https://redhat.cassandra.apache.org/40x/ .
>
> Enjoy!
>
> [1]: CHANGES.txt 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0.8
> [2]: NEWS.txt 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.8
> [3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: Role of Hadoop code in Cassandra 5.0

[Brandon Williams]

This is my feeling too, but I think we should accomplish this by
deprecating it first.  I don't expect anything will change after the
deprecation period.

Kind Regards,
Brandon

On Thu, Mar 9, 2023 at 11:09 AM Jacek Lewandowski
 wrote:
>
> I vote for removing it entirely.
>
> thanks
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 9 mar 2023 o 18:07 Miklosovic, Stefan  
> napisał(a):
>>
>> Derek,
>>
>> I have couple more points ... I do not think that extracting it to a 
>> separate repository is "win". That code is on Hadoop 1.0.3. We would be 
>> spending a lot of work on extracting it just to extract 10 years old code 
>> with occasional updates (in my humble opinion just to make it compilable 
>> again if the code around changes). What good is in that? We would have one 
>> more place to take care of ... Now we at least have it all in one place.
>>
>> I believe we have four options:
>>
>> 1) leave it there so it will be like this is for next years with 
>> questionable and diminishing usage
>> 2) update it to Hadoop 3.3 (I wonder who is going to do that)
>> 3) 2) and extract it to a separate repository but if we do 2) we can just 
>> leave it there
>> 4) remove it
>>
>> 
>> From: Derek Chen-Becker 
>> Sent: Thursday, March 9, 2023 15:55
>> To: dev@cassandra.apache.org
>> Subject: Re: Role of Hadoop code in Cassandra 5.0
>>
>> 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.
>>
>>
>>
>> I think the question isn't "Who ... is still using that?" but more "are we 
>> actually going to support it?" If we're on a version that old it would 
>> appear that we've basically abandoned it, although there do appear to have 
>> been refactoring (for other things) commits in the last couple of years. I 
>> would be in favor of removal from 5.0, but at the very least, could it be 
>> moved into a separate repo/package so that it's not pulling a relatively 
>> large dependency subtree from Hadoop into our main codebase?
>>
>> Cheers,
>>
>> Derek
>>
>> On Thu, Mar 9, 2023 at 6:44 AM Miklosovic, Stefan 
>> mailto:stefan.mikloso...@netapp.com>> wrote:
>> Hi list,
>>
>> I stumbled upon Hadoop package again. I think there was some discussion 
>> about the relevancy of Hadoop code some time ago but I would like to ask 
>> this again.
>>
>> Do you think Hadoop code (1) is still relevant in 5.0? Who in the industry 
>> is still using that?
>>
>> We might drop a lot of code and some Hadoop dependencies too (3) (even their 
>> scope is "provided"). The version of Hadoop we build upon is 1.0.3 which was 
>> released 10 years ago. This code does not have any tests nor documentation 
>> on the website.
>>
>> There seems to be issues like this (2) and it seems like the solution is to, 
>> basically, use Spark Cassandra connector instead which I would say is quite 
>> reasonable.
>>
>> Regards
>>
>> (1) 
>> https://github.com/apache/cassandra/tree/trunk/src/java/org/apache/cassandra/hadoop
>> (2) https://lists.apache.org/thread/jdy5hdc2l7l29h04dqol5ylroqos1y2p
>> (3) 
>> https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L507-L589
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>>

Re: Role of Hadoop code in Cassandra 5.0

[Brandon Williams]

I think if we reach consensus here that decides it. I too vote to
deprecate in 4.1.x.  This means we would remove it in 5.0.

Kind Regards,
Brandon

On Thu, Mar 9, 2023 at 11:32 AM Ekaterina Dimitrova
 wrote:
>
> Deprecation sounds good to me, but I am not completely sure in which version 
> we can do it. If it is possible to add a deprecation warning in the 4.x 
> series or at least 4.1.x - I vote for that.
>
> On Thu, 9 Mar 2023 at 12:14, Jacek Lewandowski  
> wrote:
>>
>> Is it possible to deprecate it in the 4.1.x patch release? :)
>>
>>
>> - - -- --- -  -
>> Jacek Lewandowski
>>
>>
>> czw., 9 mar 2023 o 18:11 Brandon Williams  napisał(a):
>>>
>>> This is my feeling too, but I think we should accomplish this by
>>> deprecating it first.  I don't expect anything will change after the
>>> deprecation period.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Thu, Mar 9, 2023 at 11:09 AM Jacek Lewandowski
>>>  wrote:
>>> >
>>> > I vote for removing it entirely.
>>> >
>>> > thanks
>>> > - - -- --- -  -
>>> > Jacek Lewandowski
>>> >
>>> >
>>> > czw., 9 mar 2023 o 18:07 Miklosovic, Stefan 
>>> >  napisał(a):
>>> >>
>>> >> Derek,
>>> >>
>>> >> I have couple more points ... I do not think that extracting it to a 
>>> >> separate repository is "win". That code is on Hadoop 1.0.3. We would be 
>>> >> spending a lot of work on extracting it just to extract 10 years old 
>>> >> code with occasional updates (in my humble opinion just to make it 
>>> >> compilable again if the code around changes). What good is in that? We 
>>> >> would have one more place to take care of ... Now we at least have it 
>>> >> all in one place.
>>> >>
>>> >> I believe we have four options:
>>> >>
>>> >> 1) leave it there so it will be like this is for next years with 
>>> >> questionable and diminishing usage
>>> >> 2) update it to Hadoop 3.3 (I wonder who is going to do that)
>>> >> 3) 2) and extract it to a separate repository but if we do 2) we can 
>>> >> just leave it there
>>> >> 4) remove it
>>> >>
>>> >> 
>>> >> From: Derek Chen-Becker 
>>> >> Sent: Thursday, March 9, 2023 15:55
>>> >> To: dev@cassandra.apache.org
>>> >> Subject: Re: Role of Hadoop code in Cassandra 5.0
>>> >>
>>> >> 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.
>>> >>
>>> >>
>>> >>
>>> >> I think the question isn't "Who ... is still using that?" but more "are 
>>> >> we actually going to support it?" If we're on a version that old it 
>>> >> would appear that we've basically abandoned it, although there do appear 
>>> >> to have been refactoring (for other things) commits in the last couple 
>>> >> of years. I would be in favor of removal from 5.0, but at the very 
>>> >> least, could it be moved into a separate repo/package so that it's not 
>>> >> pulling a relatively large dependency subtree from Hadoop into our main 
>>> >> codebase?
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Derek
>>> >>
>>> >> On Thu, Mar 9, 2023 at 6:44 AM Miklosovic, Stefan 
>>> >> mailto:stefan.mikloso...@netapp.com>> 
>>> >> wrote:
>>> >> Hi list,
>>> >>
>>> >> I stumbled upon Hadoop package again. I think there was some discussion 
>>> >> about the relevancy of Hadoop code some time ago but I would like to ask 
>>> >> this again.
>>> >>
>>> >> Do you think Hadoop code (1) is still relevant in 5.0? Who in the 
>>> >> industry is still using that?
>>> >>
>>> >> We might drop a lot of code and some Hadoop dependencies too (3) (even 
>>> >> their scope is "provided"). The version of Hadoop we build upon is 1.0.3 
>>> >> which was released 10 years ago. This code does not have any tests nor 
>>> >> documentation on the website.
>>> >>
>>> >> There seems to be issues like this (2) and it seems like the solution is 
>>> >> to, basically, use Spark Cassandra connector instead which I would say 
>>> >> is quite reasonable.
>>> >>
>>> >> Regards
>>> >>
>>> >> (1) 
>>> >> https://github.com/apache/cassandra/tree/trunk/src/java/org/apache/cassandra/hadoop
>>> >> (2) https://lists.apache.org/thread/jdy5hdc2l7l29h04dqol5ylroqos1y2p
>>> >> (3) 
>>> >> https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L507-L589
>>> >>
>>> >>
>>> >> --
>>> >> +---+
>>> >> | Derek Chen-Becker |
>>> >> | GPG Key available at https://keybase.io/dchenbecker and   |
>>> >> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>>> >> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>>> >> +---+
>>> >>

Re: [DISCUSS] New dependencies with Chronicle-Queue update

[Brandon Williams]

I know it was just an example but we upgraded JNA to 5.13 in
CASSANDRA-18050 as part of the JDK17 effort, so at least that is taken
care of.

Kind Regards,
Brandon

On Mon, Mar 13, 2023 at 10:39 AM Jeremiah D Jordan
 wrote:
>
> Given we need to upgrade to support JDK17 it seems fine to me.  The only 
> concern I have is that some of those libraries are already pretty old, for 
> example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years 
> old.  I think we should we use the most recent versions of all libraries 
> where possible?
>
> > On Mar 13, 2023, at 7:42 AM, Mick Semb Wever  wrote:
> >
> > JDK17 requires us to update our chronicle-queue dependency: CASSANDRA-18049
> >
> > We use chronicle-queue for both audit logging and fql.
> >
> > This update pulls in a number of new transitive dependencies.
> >
> > affinity-3.23ea1.jar
> > asm-analysis-9.2.jar
> > asm-commons-9.2.jar
> > asm-tree-9.2.jar
> > asm-util-9.2.jar
> > jffi-1.3.9.jar
> > jna-platform-5.5.0.jar
> > jnr-a64asm-1.0.0.jar
> > jnr-constants-0.10.3.jar
> > jnr-ffi-2.2.11.jar
> > jnr-x86asm-1.0.2.jar
> > posix-2.24ea4.jar
> >
> >
> > More info here:
> > https://issues.apache.org/jira/browse/CASSANDRA-18049?focusedCommentId=17699393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17699393
> >
> >
> > Objections?
>

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Brandon Williams]

On Mon, Mar 13, 2023 at 5:54 PM Mick Semb Wever  wrote:

> Personally I am not in favour of keeping, or recommending users use,
> code we don't test.

How much effort would it be to have some simple smoke tests?  I think
we should make sure nothing gets indirectly broken if we're going to
keep it around.

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Brandon Williams]

On Fri, Mar 17, 2023 at 9:25 AM Mick Semb Wever  wrote:
> Question/Suggestion: should we improve gossip to include what the oldest 
> format a node has, and ensure newer versioned node joining fail/warn if it 
> does > not support that older format?  That is, should we give a clear signal 
> back to operators that their rolling upgrade is not going to work smoothly, 
> that they are > going to hit nodes they will need to stop and do 
> upgradesstables on (leaving them in a state of mix-versions and nodes busy 
> upgrading…)

We already have this (even in 3.0!) to facilitate dropping compact
storage: 
https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/gms/ApplicationState.java#L59

Re: [VOTE] Release Apache Cassandra 4.1.1

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Mar 16, 2023 at 3:11 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 4.1.1 for release.
>
> sha1: 8d91b469afd3fcafef7ef85c10c8acc11703ba2d
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1284/org/apache/cassandra/cassandra-all/4.1.1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.1/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.1.1-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1.1-tentative

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

[Brandon Williams]

On Fri, Mar 17, 2023 at 2:38 PM Mick Semb Wever  wrote:
> So is there appetite for such a patch to fail or warn (guardrail?) to prevent 
> a node running on a new version that does not support sstable formats 
> existing on other nodes?

I think this makes sense, whatever the mechanism.

Re: Welcome our next PMC Chair Josh McKenzie

[Brandon Williams]

Congrats Josh!  Thanks Mick!

Kind Regards,
Brandon

On Thu, Mar 23, 2023 at 3:22 AM Mick Semb Wever  wrote:
>
> It is time to pass the baton on, and on behalf of the Apache Cassandra 
> Project Management Committee (PMC) I would like to welcome and congratulate 
> our next PMC Chair Josh McKenzie (jmckenzie).
>
> Most of you already know Josh, especially through his regular and valuable 
> project oversight and status emails, always presenting a balance and 
> understanding to the various views and concerns incoming.
>
> Repeating Paulo's words from last year: The chair is an administrative 
> position that interfaces with the Apache Software Foundation Board, by 
> submitting regular reports about project status and health. Read more about 
> the PMC chair role on Apache projects:
> - https://www.apache.org/foundation/how-it-works.html#pmc
> - https://www.apache.org/foundation/how-it-works.html#pmc-chair
> - https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
>
> The PMC as a whole is the entity that oversees and leads the project and any 
> PMC member can be approached as a representative of the committee. A list of 
> Apache Cassandra PMC members can be found on: 
> https://cassandra.apache.org/_/community.html

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Brandon Williams]

I am +1 on a 5.0 branch freeze.

Kind Regards,
Brandon

On Fri, Mar 24, 2023 at 8:54 AM Benjamin Lerer  wrote:
>>
>> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch?
>
>
> I was thinking of a cassandra-5.0 branch freeze. So branching 5.0 and 
> allowing only CEP-15 and 21 + bug fixes there.
> Le ven. 24 mars 2023 à 13:55, Paulo Motta  a écrit :
>>
>> >  I would like to propose a partial freeze of 5.0 in June.
>>
>> Would that be a trunk freeze, or freeze of a cassandra-5.0 branch? I agree 
>> with a branch freeze, but not with trunk freeze.
>>
>> I might work on small features after June and would be happy to delay 
>> releasing these on 5.0+, but delaying merge to trunk until 5.0 is released 
>> could be disruptive to contributors workflows and I would prefer to avoid 
>> that if possible.
>>
>> On Fri, Mar 24, 2023 at 6:37 AM Mick Semb Wever  wrote:
>>>
>>>
 I would like to propose a partial freeze of 5.0 in June.

 …

 This partial freeze will be valid for every new feature except CEP-21 and 
 CEP-15.
>>>
>>>
>>>
>>> +1
>>>
>>> Thanks for summarising the thread this way Benjamin. This addresses my two 
>>> main concerns: letting the branch/release date slip too much into the 
>>> unknown, squeezing GA QA efforts, while putting in place exceptional 
>>> waivers for CEP-21 and CEP-15.
>>>
>>> I hope that in the future we will be more willing to commit to the release 
>>> train model: less concerned about "what the next release contains"; more 
>>> comfortable letting big features land where they land. But this is opinion 
>>> and discussion for another day… possibly looping back to the discussion on 
>>> preview releases…
>>>
>>>
>>> Do we have yet from anyone a (rough) eta on CEP-15 (post CEP-21) landing in 
>>> trunk?
>>>
>>>

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[Brandon Williams]

On Fri, Mar 24, 2023 at 10:39 AM Jeremiah D Jordan
 wrote:
>
> I have concerns with the majority of this being in the sidecar and not in the 
> database itself.  I think it would make sense for the server side of this to 
> be a new service exposed by the database, not in the sidecar.  That way it 
> can be able to properly integrate with the authentication and authorization 
> apis, and to make it a first class citizen in terms of having 
> unit/integration tests in the main DB ensuring no one breaks it.

I don't think this can/should happen until it supports the database's
default configuration with vnodes.

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[Brandon Williams]

Oh, that's significantly different and great news, please do!  Thanks
for the clarification, Doug!

Kind Regards,
Brandon

On Fri, Mar 24, 2023 at 4:42 PM Doug Rohrer  wrote:
>
> I agree that the analytics library will need to support vnodes. To be clear, 
> there’s nothing preventing the solution from working with vnodes right now, 
> and no assumptions about a 1:1 topology between a token and a node. However, 
> we don’t, today, have the ability to test vnode support end-to-end. We are 
> working towards that, however, and should be able to remove the caveat from 
> the released analytics library once we can properly test vnode support.
> If it helps, I can update the CEP to say something more like “Caveat: 
> Currently untested with vnodes - work is ongoing to remove this limitation” 
> if that helps?
>
> Doug
>
> > On Mar 24, 2023, at 11:43 AM, Brandon Williams  wrote:
> >
> > On Fri, Mar 24, 2023 at 10:39 AM Jeremiah D Jordan
> >  wrote:
> >>
> >> I have concerns with the majority of this being in the sidecar and not in 
> >> the database itself.  I think it would make sense for the server side of 
> >> this to be a new service exposed by the database, not in the sidecar.  
> >> That way it can be able to properly integrate with the authentication and 
> >> authorization apis, and to make it a first class citizen in terms of 
> >> having unit/integration tests in the main DB ensuring no one breaks it.
> >
> > I don't think this can/should happen until it supports the database's
> > default configuration with vnodes.
>

Re: [VOTE] CEP-26: Unified Compaction Strategy

[Brandon Williams]

+1

On Tue, Apr 4, 2023, 7:24 AM Branimir Lambov  wrote:

> Hi everyone,
>
> I would like to put CEP-26 to a vote.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
>
> JIRA and draft implementation:
> https://issues.apache.org/jira/browse/CASSANDRA-18397
>
> Up-to-date documentation:
>
> https://github.com/blambov/cassandra/blob/CASSANDRA-18397/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md
>
> Discussion:
> https://lists.apache.org/thread/8xf5245tclf1mb18055px47b982rdg4b
>
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>
> Thanks,
> Branimir
>

Re: [VOTE] Release Apache Cassandra 4.0.9

[Brandon Williams]

On Wed, Apr 5, 2023 at 1:36 AM Miklosovic, Stefan
 wrote:

> I think that we should fail the vote and bump zstd-jni to 1.5.5. I do not 
> think it is a good idea to release 4.0.9 with such a bug in it when we can 
> wait one more day or so.

I'm not sure it makes sense to delay a release waiting for another
project to make their own release for a bug that is so rare it hasn't
surfaced in any release to date, since they all have it.  I think
getting CASSANDRA-18125 is probably a more prevalent issue and
delaying that for an unknown amount of time doesn't seem prudent.  We
could always make another release when Zstd is ready.

Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

[Brandon Williams]

+1


On Tue, Apr 11, 2023 at 2:54 AM Miklosovic, Stefan
 wrote:
>
> Lets just vote on that straight away. Nothing significant has changed except 
> zstd-jni update to 1.5.5. If all goes well it would be nice to have the vote 
> resolved by this Friday's noon UTC.
>
> Proposing the test build of Cassandra 4.0.9 for release.
>
> sha1: e9f8f2efa2ba75f223f31ca6801aff3fe2964745
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.9-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1286/org/apache/cassandra/cassandra-all/4.0.9/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.9/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.9-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.9-tentative

Re: Should we cut some new releases?

[Brandon Williams]

I think Berenguer was going to release it, but needed CASSANDRA-18249
which didn't pan out.  Berenguer, are you able to release or should
Stefan handle it?  I don't think there is anything to wait for;
there's already plenty important things to release.

Kind Regards,
Brandon

On Mon, Apr 17, 2023 at 10:44 AM Miklosovic, Stefan
 wrote:
>
> What about releasing 3.11.15? 3.11.14 was released 6 months ago. Is there 
> anything people want to see in 3.11.15 so we should wait a while?
>
> I give it some time and if I see no response I consider it as I can just cut 
> it.
>
> 
> From: Miklosovic, Stefan 
> Sent: Thursday, March 16, 2023 11:46
> To: dev@cassandra.apache.org
> Subject: Re: Should we cut some new releases?
>
> 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.
>
>
>
>
> OK. We can continue with 4.0.9, then 3.11.15, then 3.0.29 - in this order.
>
> 
> From: Benjamin Lerer 
> Sent: Thursday, March 16, 2023 11:43
> To: dev@cassandra.apache.org
> Subject: Re: Should we cut some new releases?
>
> 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.
>
>
>
> Not sure about 4.0.9. We released 4.0.8 just few weeks ago. I would do 4.1.1 
> first.
>
> It is true that there have not been many fixes since 4.0.8. Nevertheless 
> CASSANDRA-18125 is a 
> significant issue and 4.0 is certainly more used than 4.1 at this point so I 
> believe that we should also release a 4.0.9 version.
>
> Le mar. 14 mars 2023 à 17:27, Josh McKenzie 
> mailto:jmcken...@apache.org>> a écrit :
> +1
>
> On Tue, Mar 14, 2023, at 7:50 AM, Aleksey Yeshchenko wrote:
> +1
>
> On 14 Mar 2023, at 05:50, Berenguer Blasi 
> mailto:berenguerbl...@gmail.com>> wrote:
>
>
> +1
>
> On 13/3/23 21:25, Jacek Lewandowski wrote:
> +1
>
> pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan 
> mailto:stefan.mikloso...@netapp.com>> napisał:
> Yes, I was waiting for CASSANDRA-18125 to be in.
>
> I can release 4.1.1 to staging tomorrow morning CET if nobody objects that.
>
> Not sure about 4.0.9. We released 4.0.8 just few weeks ago. I would do 4.1.1 
> first.
>
> 
> From: Ekaterina Dimitrova 
> mailto:e.dimitr...@gmail.com>>
> Sent: Monday, March 13, 2023 18:12
> To: dev@cassandra.apache.org
> Subject: Re: Should we cut some new releases?
>
> 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.
>
>
>
> +1
>
> On Mon, 13 Mar 2023 at 12:23, Benjamin Lerer 
> mailto:ble...@apache.org>>>
>  wrote:
> Hi everybody,
>
> Benedict and Jon recently committed the patch for 
> CASSANDRA-18125 which 
> fixes some serious problems at the memtable/flush level. Should we consider 
> cutting some releases that contain this fix?

Re: [VOTE] Release Apache Cassandra 3.11.15

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, May 2, 2023 at 1:38 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 3.11.15 for release.
>
> sha1: 6cdcf5e56a77cf40c251125d68856a614eccbc53
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.15-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1287/org/apache/cassandra/cassandra-all/3.11.15/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.15/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.15-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.15-tentative

Re: [POLL] Vector type for ML

[Brandon Williams]

1. VECTOR
2. VECTOR FLOAT[n]
3. FLOAT[N]   (Non null by default)

Redundant or not, I think having the VECTOR keyword helps signify what
the app is generally about and helps get buy-in from ML stakeholders.

On Thu, May 4, 2023 at 3:45 AM Benedict  wrote:
>
> Hurrah for initial agreement.
>
> For syntax, I think one option was just FLOAT[N]. In VECTOR FLOAT[N], VECTOR 
> is redundant - FLOAT[N] is fully descriptive by itself. I don’t think VECTOR 
> should be used to simply imply non-null, as this would be very unintuitive. 
> More logical would be NONNULL, if this is the only condition being applied. 
> Alternatively for arrays we could default to NONNULL and later introduce 
> NULLABLE if we want to permit nulls.
>
> If the word vector is to be used it makes more sense to make it look like a 
> list, so VECTOR as here the word VECTOR is clearly not redundant.
>
> So, I vote:
>
> 1) (NON NULL) FLOAT[N]
> 2) FLOAT[N]   (Non null by default)
> 3) VECTOR
>
>
>
> On 4 May 2023, at 08:52, Mick Semb Wever  wrote:
>
> 
>>
>> Did we agree on a CQL syntax?
>>
>> I don’t believe there has been a pool on CQL syntax… my understanding 
>> reading all the threads is that there are ~4-5 options and non are -1ed, so 
>> believe we are waiting for majority rule on this?
>
>
>
> Re-reading that thread, IIUC the valid choices remaining are…
>
> 1. VECTOR FLOAT[n]
> 2. FLOAT VECTOR[n]
> 3. VECTOR
> 4. VECTOR[n]
> 5. ARRAY
> 6. NON-NULL FROZEN
>
>
> Yes I'm putting my preference (1) first ;) because (banging on) if the future 
> of CQL will have FLOAT[n] and FROZEN, where the VECTOR keyword is: 
> for general cql users; just meaning "non-null and frozen", these gel best 
> together.
>
> Options (5) and (6) are for those that feel we can and should provide this 
> type without introducing the vector keyword.
>
>

Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, May 4, 2023 at 11:47 AM Doug Rohrer  wrote:
>
> Hello all,
>
> I’d like to put CEP-28 to a vote.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
>
> Jira:
> https://issues.apache.org/jira/browse/CASSANDRA-16222
>
> Draft implementation:
>
> - Apache Cassandra Spark Analytics source code: 
> https://github.com/frankgh/cassandra-analytics
> - Changes required for Sidecar: 
> https://github.com/frankgh/cassandra-sidecar/tree/CEP-28-bulk-apis
>
> Discussion:
> https://lists.apache.org/thread/lrww4d7cdxgtg8o3gt8b8foymzpvq7z3
>
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding vetoes.
>
>
> Thanks,
>
> Doug Rohrer
>
>

Re: [VOTE] CEP-29 CQL NOT Operator

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
 wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com

Re: [VOTE] Release Apache Cassandra 3.0.29

[Brandon Williams]

+1

On Tue, May 9, 2023, 11:54 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Proposing the test build of Cassandra 3.0.29 for release.
>
> sha1: 087cffce636b63c12e328994d52bdf8f4ccc9750
> Git: https://github.com/apache/cassandra/tree/3.0.29-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1288/org/apache/cassandra/cassandra-all/3.0.29/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.29/
>
> 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://github.com/apache/cassandra/blob/3.0.29-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/3.0.29-tentative/NEWS.txt
>

Re: [DISCUSS] The future of CREATE INDEX

[Brandon Williams]

On Fri, May 12, 2023 at 11:29 AM Caleb Rackliffe
 wrote:
>
> Okay, so the proposal for 5.0...
>
> 1.) Add a YAML option that specifies a default implementation for CREATE 
> INDEX, and make this the legacy 2i for now. No existing DDL breaks. We don't 
> have to commit to the absolute superiority of SAI.

I really dislike the idea of the same CQL doing different things based
upon a per-node configuration.

Re: [VOTE] Release dtest-api 0.0.14

[Brandon Williams]

+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] Bring cassandra-harry in tree as a submodule

[Brandon Williams]

On Wed, May 24, 2023 at 7:45 AM Josh McKenzie  wrote:
> What prompted this thread was harry being external to the core codebase and 
> the lack of adoption and usage of it having led to atrophy of certain aspects 
> of it, which then led to redundant implementation of some fuzz testing and 
> lost time.
>
> We'd all be better served to have this closer to the main codebase as a 
> forcing function to smooth out the rough edges, integrate it, and make it a 
> collective artifact and first class citizen IMO.

This is a convincing argument for me, let's pull Harry in.

Re: [VOTE] Release dtest-api 0.0.15

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, May 24, 2023 at 10:31 AM Dinesh Joshi  wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.15 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/48af78d1d4b5f285d3dd4991afd4df3101e3983a
> tagged with 0.0.15
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1290/org/apache/cassandra/dtest-api/0.0.15/
>
> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
>
> Changes since last release:
>
> * CASSANDRA-18537: Add JMX utility class to in-jvm dtest to ease
> development of new tests using JMX
>
> 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: [VOTE] Release Apache Cassandra 4.0.10

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, May 25, 2023 at 10:13 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 4.0.10 for release.
>
> sha1: da77d3f729160e84fbab37666de99550be794265
> Git: https://github.com/apache/cassandra/tree/4.0.10-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1299/org/apache/cassandra/cassandra-all/4.0.10/
>
> 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.10/
>
> 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://github.com/apache/cassandra/blob/4.0.10-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.10-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.1.2

[Brandon Williams]

+1



On Thu, May 25, 2023 at 10:14 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 4.1.2 for release.
>
> sha1: c5c075f0080f3f499d2b01ffb155f89723076285
> Git: https://github.com/apache/cassandra/tree/4.1.2-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1302/org/apache/cassandra/cassandra-all/4.1.2/
>
> 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.1.2/
>
> 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://github.com/apache/cassandra/blob/4.1.2-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.2-tentative/NEWS.txt

Re: [VOTE] CEP-30 ANN Vector Search

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, May 25, 2023 at 10:45 AM Jonathan Ellis  wrote:
>
> Let's make this official.
>
> CEP: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-30%3A+Approximate+Nearest+Neighbor%28ANN%29+Vector+Search+via+Storage-Attached+Indexes
>
> POC that demonstrates all the big rocks, including distributed queries: 
> https://github.com/datastax/cassandra/tree/cep-vsearch
>
> --
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced

Re: Is simplenative in cassandra-stress still relevant?

[Brandon Williams]

On Tue, May 30, 2023 at 7:15 PM Brad  wrote:
> If you're performing stress testing, why would you not want to use the 
> official driver?  I've spoken to several people who all have said they've 
> never used simplenative mode.

I agree that it shouldn't be used normally, but I'm not sure we should
remove it, because we can't remove it fully: SimpleClient is still
used in many tests, and I think that should continue.

If you suspect any kind of native proto or driver issue it may be
useful to have another implementation easily accessible to aid in
debugging the problem, and the maintenance cost of keeping it in
stress is roughly zero in my opinion.  We can make it clear that it's
not recommended for use and is intended only as a debugging tool,
though.

Kind Regards,
Brandon

Re: [VOTE] CEP-8 Datastax Drivers Donation

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Jun 13, 2023 at 9:15 AM Jeremy Hanna  wrote:
>
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the 
> goal of this vote is simply to ensure that the community is in favor of the 
> donation. Nothing more.
> The plan is to introduce the drivers, one by one. Each driver donation will 
> need to be accepted first by the PMC members, as it is the case for any 
> donation. Therefore the PMC should have full control on the pace at which new 
> drivers are accepted.
>
> If this vote passes, we can start this process for the Java driver under the 
> direction of the PMC.
>
> Jeremy
>
> 1. 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp

Re: Adding wiremock to test dependencies

[Brandon Williams]

I was concerned about 'jre8' being in the dependency name and looked
into which java versions were supported, and it looks like 17 is, so
we should verify but I am +1 if that is the case.

https://github.com/wiremock/wiremock/issues/1655

Kind Regards,
Brandon

On Tue, Jun 20, 2023 at 6:35 AM Miklosovic, Stefan
 wrote:
>
> Hi,
>
> we want to introduce wiremock library (1) into the project as a test 
> dependency to test CASSANDRA-16555.
>
> In that patch, (wip here (2)), we want to test how would such snitch behave 
> based on what Amazon EC2 Identity Service of version 2 returned to that 
> snitch. AWS Identity service of version 2 is necessary to call in order to 
> get a token with which a snitch is going to get AZ of a node it is called 
> from.
>
> The last comment of mine in (3) elaborates about approaches we were 
> considering and mocking http communication / requests with wiremock seems to 
> be like the most comfortable and straightforward solution.
>
> Wiremock is Apache licence 2.0 (4) and is well maintained.
>
> Are people OK with us introducing this to the build?
>
> (1) https://wiremock.org/
> (2) 
> https://github.com/apache/cassandra/pull/2403/files#diff-dc04778c6659040f1c00f37e97a9b1530a532d3d1e3620427bd6628d1b2ec048
> (3) https://issues.apache.org/jira/browse/CASSANDRA-16555
> (4) https://github.com/wiremock/wiremock/blob/master/LICENSE.txt
>
> Regards

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Brandon Williams]

On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie  wrote:
>
> 2. Anyone concerned about us being specific about versions in 
> requirements.txt in the dtest repo?

My concern with this is atrophy; we'll set the version once and when
finally forced to update, find that a lot of other things must also be
updated in order to do so.  I think our current approach of only
setting them on things we require at a certain version like thrift has
been successful thus far, and I don't think having different versions
would be very common, but also not really affect repeatability if
encountered.  You can see what versions are used from the logs though
and could adjust them to be the same if necessary.

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Brandon Williams]

On Fri, Jun 23, 2023 at 8:36 AM Josh McKenzie  wrote:
> How frequently do we see failures in tests (straight failure, flakes, etc) 
> that are due to the versions of dependencies (JDK or python) that we're 
> running the tests with?
>
> Regardless of 1, if the answer to 2 is "almost never", then there's likely no 
> bridge to cross here.

For python, it's definitely in that category.  There aren't even that
many things that _could_ cause a failure, if the XML parser gets
upgraded it still works the same way.

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Brandon Williams]

The "artifacts" task is not quite the same since it builds other things
like docs, which significantly contributes to longer build time.  I don't
see why we couldn't add a new task that preserves the old behavior though,
"fulljar" or something like that.

Kind Regards,
Brandon


On Mon, Jun 26, 2023 at 6:12 AM Jacek Lewandowski <
lewandowski.ja...@gmail.com> wrote:

> Yes, I've mentioned that there is a property we can set to skip checkstyle.
>
> Currently such a goal is "artifacts" which basically validates everything.
>
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
> pon., 26 cze 2023 o 13:09 Mike Adamson  napisał(a):
>
>> While I like the idea of this because of added time these checks take, I
>> was under the impression that checkstyle (at least) can be disabled with a
>> flag.
>>
>> If we did do this, would it make sense to have a "release"  or "commit"
>> target (or some other name) that ran a full build with all checks that can
>> be used prior to pushing changes?
>>
>> On Mon, 26 Jun 2023 at 08:35, Berenguer Blasi 
>> wrote:
>>
>>> I would prefer sthg that is totally transparent to me and not add one
>>> more step I have to remember. Just to push/run CI to find out I missed it
>>> and rinse and repeat... With the recent fix to checkstyle I am happy as
>>> things stand atm. My 2cts
>>> On 26/6/23 8:43, Jacek Lewandowski wrote:
>>>
>>> Hi,
>>>
>>>
>>> The context is that we currently have 3 checks in the build:
>>>
>>> - Checkstyle,
>>>
>>> - Eclipse-Warnings,
>>>
>>> - RAT
>>>
>>>
>>> CheckStyle and RAT are executed with almost every target we run: build,
>>> jar, test, test-some, testclasslist, etc.; on the other hand,
>>> Eclipse-Warnings is executed automatically only with the artifacts target.
>>>
>>>
>>> Checkstyle currently uses some caching, so subsequent reruns without
>>> cleaning the project validate only the modified files.
>>>
>>>
>>> Both CI - Jenkins and Circle forces running all checks.
>>>
>>>
>>> I want to discuss whether you are ok with extracting all checks to their
>>> distinct target and not running it automatically with the targets which
>>> devs usually run locally. In particular:
>>>
>>>
>>>
>>>- "build", "jar", and all "test" targets would not trigger
>>>CheckStyle, RAT or Eclipse-Warnings
>>>- A new target "check" would trigger all CheckStyle, RAT, and
>>>Eclipse-Warnings
>>>- The new "check" target would be run along with the "artifacts"
>>>target on Jenkins-CI, and it as a separate build step in CircleCI
>>>
>>>
>>> The rationale for that change is:
>>>
>>>- Running all the checks together would be more consistent, but
>>>running all of them automatically with build and test targets could waste
>>>time when we develop something locally, frequently rebuilding and running
>>>tests.
>>>- On the other hand, it would be more consistent if the build did
>>>what we want - as a dev, when prototyping, I don't want to be forced to 
>>> run
>>>analysis (and potentially fix issues) whenever I want to build a project 
>>> or
>>>just run a single test.
>>>- There are ways to avoid running checks automatically by specifying
>>>some build properties. Though, the discussion is about the default 
>>> behavior
>>>- on the flip side, if one wants to run the checks along with the 
>>> specified
>>>target, they could add the "check" target to the command line.
>>>
>>>
>>> The rationale for keeping the checks running automatically with every
>>> target is to reduce the likelihood of not running the checks locally before
>>> pushing the branch and being surprised by failing CI soon after starting
>>> the build.
>>>
>>>
>>> That could be fixed by running checks in a pre-push Git hook. There are
>>> some benefits of this compared to the current behavior:
>>>
>>>- the checks would be run automatically only once
>>>- they would be triggered even for those devs who do everything in
>>>IDE and do not even touch Ant commands directly
>>>
>>>
>>> Checks can take time; to optimize that, they could be enforced locally
>>> to verify only the modified files in the same way as we currently determine
>>> the tests to be repeated for CircleCI.
>>>
>>> Thanks
>>> - - -- --- -  -
>>> Jacek Lewandowski
>>>
>>>
>>
>> --
>> [image: DataStax Logo Square]  *Mike Adamson*
>> Engineering
>>
>> +1 650 389 6000 <16503896000> | datastax.com 
>> Find DataStax Online: [image: LinkedIn Logo]
>> 
>>[image: Facebook Logo]
>> 

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[Brandon Williams]

+1

Kind Regards,
Brandon


On Tue, Jun 27, 2023 at 12:17 PM Shailaja Koppu  wrote:
>
> Hi Team,
>
> (Starting a new thread for VOTE instead of reusing the DISCUSS thread, to 
> follow usual procedure).
>
> Please vote on CEP 33 - CIDR filtering authorizer 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer.
>
> Thanks,
> Shailaja

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Brandon Williams]

This sounds good to me.  Can we shorten 'build-project' to just 'build'?

Kind Regards,
Brandon

On Thu, Jun 29, 2023 at 3:22 AM Jacek Lewandowski
 wrote:
>
> So given all the feedback, I'm going to do the following:
>
> "jar" will depend on "check" target
> "build-project", "build-test" and "test" targets will not depend on "check" 
> target
> "check" target will include checkstyle, rat and eclipse-warnings
>
> There is an additional flag "no-check" to disable checks in the "jar" target.
>
> Will not introduce any Git hook.
>
> wt., 27 cze 2023 o 18:35 Jacek Lewandowski  
> napisał(a):
>>
>> With git you can always opt-out by adding --no-verify flag to either push or 
>> commit
>>
>> I really prefer separate tasks than flags. Flags are not listed in the help 
>> message like "ant -p" and are not auto-completed in the terminal. That makes 
>> them almost undiscoverable for newcomers.
>>
>> Want to have jar include checks? Ok, but let's don't run checks 
>> automatically with "build" or "test"
>>
>>
>>
>> wt., 27 cze 2023 o 18:26 David Capwell  napisał(a):
>>>
>>> nobody referred to running checks in a pre-push (or pre-commit) hook
>>>
>>>
>>>
>>> In accord I added an opt-out for each hook, and will require such here as 
>>> well… as long as you can opt-out, its fine by me… I know I will likely 
>>> opt-out, but wouldn’t block such an effort
>>>
>>> Your point that pre-push hook might not be the best one is valid, and we 
>>> should rather think about pre-commit
>>>
>>>
>>> Pre-push is far better than pre-commit, with pre-commit you are forcing a 
>>> style on people…. I for one have many many commits in a single PR, where I 
>>> use commits to not loose track of progress (even if the code doesn’t 
>>> compile), so forcing the build to work would be a -1 from me…. Pre-push at 
>>> least means “you want the world to see this” so makes more sense there…
>>>
>>> Again, must have an opt-out
>>>
>>> proposed:
>>> ant jar (just build)
>>> git commit (run some checks)
>>>
>>>
>>> I am against this, jar should also check and ask users to opt-out if they 
>>> don’t want the checks….
>>>
>>> If we go with opt-out i'd like to see one flag that can disable all checks: 
>>> `-Dchecks.skip`
>>>
>>>
>>> Works for me, you can also do the following to disable and not worry about
>>>
>>> $ cat < build.properties
>>> checks.skip: true
>>> EOF
>>>
>>> On Jun 27, 2023, at 3:14 AM, Mick Semb Wever  wrote:
>>>
>>> The context is that we currently have 3 checks in the build:
>>>
>>> - Checkstyle,
>>> - Eclipse-Warnings,
>>> - RAT
>>>
>>>
>>>
>>> And dependency-check (owasp).
>>>
>>>
>>>
>>> I want to discuss whether you are ok with extracting all checks to their 
>>> distinct target and not running it automatically with the targets which 
>>> devs usually run locally. In particular:
>>>
>>>
>>> "build", "jar", and all "test" targets would not trigger CheckStyle, RAT or 
>>> Eclipse-Warnings
>>> A new target "check" would trigger all CheckStyle, RAT, and Eclipse-Warnings
>>> The new "check" target would be run along with the "artifacts" target on 
>>> Jenkins-CI, and it as a separate build step in CircleCI
>>>
>>>
>>>
>>> +0 I prefer this opt-in over an opt-out approach.
>>>
>>> It should be separated from `artifacts` too.
>>> We would need to encourage engineers to run `ant check` before
>>> starting CI and/or requesting review.
>>>
>>> I'm in favour of the opt-in approach because it keeps it visible.
>>> Folks configure flags and it "disappears" forever.  Also it's a
>>> headache in all the other ant targets where we actually don't want it,
>>> e.g. tests.
>>>
>>> If we go with opt-out i'd like to see one flag that can disable all
>>> checks: `-Dchecks.skip`
>>>
>>>
>>> That could be fixed by running checks in a pre-push Git hook. There are 
>>> some benefits of this compared to the current behavior:
>>>
>>>
>>>
>>> -1
>>> committing and pushing to a personal branch is often done to save work
>>> or for cross-machine or collaboration. We should not gate on checks or
>>> compilation here.
>>>
>>> PRs should fail if checks fail, to give newcomers clear feedback (and
>>> to take this nit-picking out of the review process).
>>>
>>>

Re: Improved DeletionTime serialization to reduce disk size

[Brandon Williams]

On Thu, Jun 29, 2023 at 11:42 AM Jeff Jirsa  wrote:
> 3-4% reduction on disk ... for what exactly?
>
> It seems exceptionally uncommon to have 3% of your data SIZE be tombstones.

If the data is TTL'd I think it's not entirely uncommon.

Kind Regards,
Brandon

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

[Brandon Williams]

On Fri, Jul 7, 2023 at 10:09 AM Josh McKenzie  wrote:
> 3. Multiplexed tests (changed, added) run against all JDK's and a broader 
> range of configs (no-vnode, vnode default, compression, etc)

I think this is going to be too heavy...we're taking 500 iterations
and multiplying that by like 4 or 5?

Re: Changing the output of tooling between majors

[Brandon Williams]

On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
 wrote:
> If that is the case, we should start to treat this problem completely 
> differently and we should not rely on the output of tooling at all and we 
> should either provide corresponding JMX method to retrieve it or we should 
> offer other formats tooling prints, like JSON or YAML.

We offer both JSON and YAML output in nodetool commands today, so I
would stick with those.  I want to shoot down JMX though, since that's
basically telling scripting languages to get bent.

Re: Changing the output of tooling between majors

[Brandon Williams]

On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
 wrote:
>
> Anyway, the main question here is if we are OK to change the output in majors.

I think we always want to strive for compatibility whenever possible.
My personal litmus test is "can this information be obtained
elsewhere?" and if the answer is no, then the format shouldn't change
as it is very likely to at least cause friction for anyone screen
scraping to get it programmatically.  However, as you mentioned,
adding a serialized format provides another, superior method of
programmatic access, freeing us of the issues with cosmetic changes.

Re: Changing the output of tooling between majors

[Brandon Williams]

On Fri, Jul 7, 2023 at 2:02 PM Miklosovic, Stefan
 wrote:
>
> There is just no clear path how to improve that over time and exposing the 
> same output via different format is not really solving it ... the 
> discrepancies are still there.

I'm not sure what you mean, can you explain?  In my mind, if we have a
serialized output format, we have divorced the display from the data
and so we should be free to modify how we display it all we like after
that point.

Re: Changing the output of tooling between majors

[Brandon Williams]

On Fri, Jul 7, 2023 at 2:11 PM Miklosovic, Stefan
 wrote:
>
> Yes, that is true, but the original, unfixed, output, is still there. Are we 
> OK with that?

When we have a serialized output available, we do whatever we like to
the display output.

Re: Changing the output of tooling between majors

[Brandon Williams]

On Fri, Jul 7, 2023 at 2:20 PM Miklosovic, Stefan
 wrote:
>
> Great thanks. That might work.
>
> So we do not change the default output unless there is json / yaml equivalent.
>
> Once there is, we are free to change the default output however we want.

Yes, exactly.  Then we have the best of both worlds: programmatic
access that isn't flimsy, and a pretty display however we want it.

Re: [DISCUSS] When to run CheckStyle and other verificiations

[Brandon Williams]

On Mon, Jul 10, 2023 at 6:07 AM Jacek Lewandowski
 wrote:
> Remove the checkstyle dependency from "jar" and "test"
> Create a single "check" target that includes all the checks we expect to pass 
> in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making this task 
> the default.

I support this.  Having checkstyle run when building is clearly
constant friction for many, even though you can disable it.

Re: Removal of CloudstackSnitch

[Brandon Williams]

I agree with Ekaterina, but also want to point out that snitches are
pluggable, so whatever we do should be pretty safe.  If someone
discovers after the removal that they need it, they can just plug it
back in.

Kind Regards,
Brandon

On Mon, Jul 10, 2023 at 8:54 AM Ekaterina Dimitrova
 wrote:
>
> Hi Stefan,
>
> I think we should follow our deprecation rules and deprecate it in 5.0, 
> potentially remove in 6.0. (Deprecate in one major, remove in the next major)
> Maybe the deprecation can come with a note on your findings for the users, 
> just in case someone somewhere uses it and did not follow the user mailing 
> list?
>
> Thank you
> Ekaterina
>
> On Mon, 10 Jul 2023 at 9:47, Miklosovic, Stefan 
>  wrote:
>>
>> Hi list,
>>
>> I want to ask about the future of CloudstackSnitch.
>>
>> This snitch was added 9 years ago (1). I contacted the original author of 
>> that snitch, Pierre-Yves Ritschard, who is currently CEO of a company he 
>> coded that snitch for.
>>
>> In a nutshell, Pierre answered that he does not think this snitch is 
>> relevant anymore and the company is using different way how to fetch 
>> metadata from a node, rendering CloudstackSnitch, as is, irrelevant for them.
>>
>> I also wrote an email to user ML list (2) about two weeks ago and nobody 
>> answered that they are using it either.
>>
>> The current implementation is using this approach (3) but I think that it is 
>> already obsolete in the snitch because snitch is adding a path to parsed 
>> metadata service IP which is probably not there at all in the default 
>> implementation of Cloudstack data server.
>>
>> What also bothers me is that we, as a community, seem to not be able to test 
>> the functionality of this snitch as I do not know anybody with a Cloudstack 
>> deployment who would be able to test this reliably.
>>
>> For completeness, in (1), Brandon expressed his opinion that unless users 
>> come forward for this snitch, he thinks the retiring it is the best option.
>>
>> For all cloud-based snitches, we did the refactorization of the code in 
>> 16555 an we work on improvement in 18438 which introduces a generic way how 
>> metadata services are called and plugging in custom logic or reusing a 
>> default implementation of a cloud connector is very easy, further making 
>> this snitch less relevant.
>>
>> This being said, should we:
>>
>> 1) remove it in 5.0
>> 2) keep it there in 5.0 but mark it @Deprecated
>> 3) keep it there
>>
>> Regards
>>
>> (1) https://issues.apache.org/jira/browse/CASSANDRA-7147
>> (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3
>> (3) 
>> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns

Re: [ANNOUNCE] Apache Cassandra 4.0.11 test artifact available

[Brandon Williams]

+1

Checked debian and boolean redhat installs

Kind Regards,
Brandon

On Wed, Jul 12, 2023 at 3:08 PM Miklosovic, Stefan
 wrote:
>
> The test build of Cassandra 4.0.11 is available.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/
>
> 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.11/
>
> A vote of this test build will be initiated within the next couple of days.
>
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.0.11-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.11-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.11

[Brandon Williams]

+1

On Thu, Jul 13, 2023, 2:13 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Proposing the test build of Cassandra 4.0.11 for release.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/
>
> 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.11/
>
> 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://github.com/apache/cassandra/blob/4.0.11-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.0.11-tentative/NEWS.txt

Re: [Discuss] CQLSH confusion

[Brandon Williams]

You forgot to link references,
https://issues.apache.org/jira/browse/CASSANDRA-18666 has it all
though I think

I think it's too late to align versions, that cat is out of the bag.
What we can do though is what I last suggested there: keep the C*
version somewhere in cqlsh and warn when it doesn't match the server.

Kind Regards,
Brandon

On Thu, Jul 13, 2023 at 12:14 PM German Eichberger via dev
 wrote:
>
> All,
>
> I am working with clusters with different Cassandra versions and have been 
> using some cqlsh which "just worked". Recently I wanted to use virtual tables 
> and ran into [1]. After that I filed [2].
>
> Brandon states that "do not use a cqlsh that is from a different version than 
> what is distributed with the server" since I have no idea what other 
> incompatibilities like this there are, compatibility of that kind has never 
> been a goal."
>
> I would like to open the discussion if this is what we want: cqlsh needs to 
> be in lockstep with the C* version.
>
> Assuming, this is how things should be, I would propose to change the cqlsh 
> versioning to be in line with the C* versioning. Right now I am using cqlsh 
> 6.0.1 and I have no idea to which C* version that translates to. Aligning 
> versions would make this much easier.
>
> Thanks,
> German

Re: Improved DeletionTime serialization to reduce disk size

[Brandon Williams]

On Sun, Jul 16, 2023 at 11:47 PM Berenguer Blasi
 wrote:
> one q that came up during the review: What should we do if we find a 
> markForDeleteAt (mfda) usging the MSByte? That is a mfda beyond year 4254:
>
> A. That is a mistake/bug. I makes no sense when localDeletionTime can't 
> already go any further than year 2106. We should reject/fail, maybe log and 
> add an upgrade note.

I think creation of doomstones is always a bug, but perhaps there is a
use case I cannot think of.  One option that was discussed is setting
a default for the maximum_timestamp_fail_threshold which I think could
make sense, since it would provide protection but allow a way out.

> B. That was supported, regardless of how weird it may be. Cap it to the 
> current max year 4254, maybe log and add an upgrade note.

I am not a fan of doing something other than what we were asked to do,
I think we should either reject it, or do it.

Re: [VOTE] Release Apache Cassandra 4.1.3

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Jul 19, 2023 at 1:28 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 4.1.3 for release.
>
> sha1: 2a4cd36475de3eb47207cd88d2d472b876c6816d
> Git: https://github.com/apache/cassandra/tree/4.1.3-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1304/org/apache/cassandra/cassandra-all/4.1.3/
>
> 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.1.3/
>
> 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://github.com/apache/cassandra/blob/4.1.3-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.3-tentative/NEWS.txt

Re: [DISCUSS] Using ACCP or tc-native by default

[Brandon Williams]

I think we could special-case and default to 'auto' but allow other
more explicit options.

Kind Regards,
Brandon

On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev
 wrote:
>
> In general I agree with Joey -- but I would prefer if this behavior is 
> configurable, e.g. there is an option to get a startup failure if the 
> configured fastest provider can't run for any reason to avoid a "silent" 
> performance degradation as Jordan was experiencing.
>
> Thanks,
> German
>
> 
> From: Joseph Lynch 
> Sent: Thursday, July 20, 2023 7:38 AM
> To: dev@cassandra.apache.org 
> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
>
> Having native dependencies shouldn't make the project x86 only, it
> should just accelerate the performance on x86 when available. Can't we
> just try to load the fastest available provider (so arm will use
> native java but x86 will use proper hardware acceleration) and failing
> that fall-back to the default? If I recall correctly from the
> messaging service patches (and zstd/lz4) it's reasonably
> straightforward to try to load native code and then fail-back if you
> fail.
>
> -Joey
>
> On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  
> wrote:
> >
> > Maybe we could start providing Dockerfile’s and/or make arch specific 
> > rpm/deb packages that have everything setup correctly per architecture?
> > We could also download them all and have the startup scripts put stuff in 
> > the right places depending on the arch of the machine running them?
> > I feel like there are probably multiple ways we could solve this without 
> > requiring users to jump through a bunch of hoops?
> > But I do agree we can’t make the project x86 only.
> >
> > -Jeremiah
> >
> > > On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
> > >  wrote:
> > >
> > > Hi,
> > >
> > > as I was reviewing the patch for this feature (1), we realized that it is 
> > > not quite easy to bundle this directly into Cassandra.
> > >
> > > The problem is that this was supposed to be introduced as a new 
> > > dependency:
> > >
> > > 
> > >software.amazon.cryptools
> > >AmazonCorrettoCryptoProvider
> > >2.2.0
> > >linux-x86_64
> > > 
> > >
> > > Notice "classifier". That means that if we introduced this dependency 
> > > into the project, what about ARM users? (there is corresponding aarch 
> > > classifier as well). ACCP is platform-specific but we have to ship 
> > > Cassandra platform-agnostic. It just needs to run OOTB everywhere. If we 
> > > shipped that with x86 and a user runs Cassandra on ARM, I guess that 
> > > would break things, right?
> > >
> > > We also can not just add both dependencies (both x86 and aarch) because 
> > > how would we differentiate between them in runtime? That all is just too 
> > > tricky / error prone.
> > >
> > > So, the approach we want to take is this:
> > >
> > > 1) nothing will be bundled in Cassandra by default
> > > 2) a user is supposed to download the library and put it to the class path
> > > 3) a user is supposed to put the implementation of ICryptoProvider 
> > > interface Cassandra exposes to the class path
> > > 3) a user is supposed to configure cassandra.yaml and its section 
> > > "crypto_provider" to reference the implementation he wants
> > >
> > > That way, we avoid the situation when somebody runs x86 lib on ARM or 
> > > vice versa.
> > >
> > > By default, NoOpProvider will be used, that means that the default crypto 
> > > provider from JRE will be used.
> > >
> > > It can seem like we have not done too much progress here but hey ... we 
> > > opened the project to the custom implementations of crypto providers a 
> > > community can create. E.g. as 3rd party extensions etc ...
> > >
> > > I want to be sure that everybody is aware of this change (that we plan to 
> > > do that in such a way that it will not be "bundled") and that everybody 
> > > is on board with this. Otherwise I am all ears about how to do that 
> > > differently.
> > >
> > > (1) 
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-18624&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kYGSZGi3caINvm%2FDT4ms3%2BrcnMTxg0E921cMjmUvHQw%3D&reserved=0
> > >
> > > 
> > > From: German Eichberger via dev 
> > > Sent: Friday, June 23, 2023 22:43
> > > To: dev
> > > Subject: Re: [DISCUSS] Using ACCP or tc-native by default
> > >
> > > 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.
> > >
> > >
> > >
> > > +1 to ACCP - we love performance.
> > > 
> > > From: David Capwell 

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Brandon Williams]

+1

Kind Regards,
Brandon

On Fri, Jul 21, 2023 at 11:58 AM Jyothsna Konisa  wrote:
>
> Hi Everyone!
>
> I would like to start a vote thread for CEP-34.
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
> JIRA   : 
> https://issues.apache.org/jira/browse/CASSANDRA-18554
> Draft Implementation : https://github.com/apache/cassandra/pull/2372
> Discussion : 
> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
>
> Thanks,
> Jyothsna Konisa.

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

[Brandon Williams]

+1 to everything stated here.

Kind Regards,
Brandon

On Wed, Jul 26, 2023 at 5:28 PM Mick Semb Wever  wrote:
>
>
> The previous thread¹ on when to freeze 5.0 landed on freezing the first week 
> of August, with a waiver in place for TCM and Accord to land later (but 
> before October).
>
> With JDK8 now dropped and SAI and UCS merged, the only expected 5.0 work that 
> hasn't landed is Vector search (CEP-30).
>
> Are there any objections to a waiver on Vector search?  All the groundwork: 
> SAI and the vector type; has been merged, with all remaining work expected to 
> land in August.
>
> I'm keen to freeze and see us shift gears – there's already SO MUCH in 5.0 
> and a long list of flakies.  It takes time and patience to triage and 
> identify the bugs that hit us before GA.  The freeze is about being "mostly 
> feature complete",  so we have room for things before our first beta 
> (precedence is to ask).   If we hope for a GA by December, account for the 6 
> weeks turnaround time for cutting and voting on one alpha, one beta, and one 
> rc release, and the quiet period that August is, we really only have 
> September and October left.
>
> I already feel this is asking a bit of a miracle from us given how 4.1 went 
> (and I'm hoping I will be proven wrong).
>
> In addition, are there any objections to cutting an 5.0-alpha1 release as 
> soon as we freeze?
>
> This is on the understanding vector, tcm and accord will become available in 
> later alphas.  Originally the discussion¹ was waiting for Accord for alpha1, 
> but a number of folk off-list have requested earlier alphas to help with 
> testing.
>
>
> ¹) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3

Re: [DISCUSSION] Shall we remove ant javadoc task?

[Brandon Williams]

I don't think even if it works anyone is going to use the output, so
I'm good with removal.

Kind Regards,
Brandon

On Wed, Aug 2, 2023 at 11:50 AM Ekaterina Dimitrova
 wrote:
>
> Hi everyone,
> We were looking into a user report around our ant javadoc task recently.
> That made us realize it is not run in CI; it finishes successfully even if 
> there are hundreds of errors, some potentially breaking doc pages.
>
> There was a ticket discussion where a few community members mentioned that 
> this task was probably unnecessary. Can we remove it, or shall we fix it?
>
> Best regards,
> Ekaterina

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

[Brandon Williams]

Is this intended to be used now and change the merge order?  I ask
because 18705 mentions bumping build.xml and CHANGES.txt amongst
others that haven't been done which is leading to confusion.

Kind Regards,
Brandon

On Sat, Aug 5, 2023 at 4:46 PM Mick Semb Wever  wrote:
>
>
> With no objections, and everything folk mentioned above in, the cassandra-5.0 
> branch is cut.
>
> Next steps are bumping trunk to 5.1 and then cutting a 5.0-alpha1
>
> The bumping to 5.1 has a few steps involved in it, but the initial in-tree 
> PRs are ready for review, with CI being run, see CASSANDRA-18705
>
>
>
> On Sat, 29 Jul 2023 at 00:00, Brandon Williams  wrote:
>>
>> +1 to everything stated here.
>>
>> Kind Regards,
>> Brandon
>>
>> On Wed, Jul 26, 2023 at 5:28 PM Mick Semb Wever  wrote:
>> >
>> >
>> > The previous thread¹ on when to freeze 5.0 landed on freezing the first 
>> > week of August, with a waiver in place for TCM and Accord to land later 
>> > (but before October).
>> >
>> > With JDK8 now dropped and SAI and UCS merged, the only expected 5.0 work 
>> > that hasn't landed is Vector search (CEP-30).
>> >
>> > Are there any objections to a waiver on Vector search?  All the 
>> > groundwork: SAI and the vector type; has been merged, with all remaining 
>> > work expected to land in August.
>> >
>> > I'm keen to freeze and see us shift gears – there's already SO MUCH in 5.0 
>> > and a long list of flakies.  It takes time and patience to triage and 
>> > identify the bugs that hit us before GA.  The freeze is about being 
>> > "mostly feature complete",  so we have room for things before our first 
>> > beta (precedence is to ask).   If we hope for a GA by December, account 
>> > for the 6 weeks turnaround time for cutting and voting on one alpha, one 
>> > beta, and one rc release, and the quiet period that August is, we really 
>> > only have September and October left.
>> >
>> > I already feel this is asking a bit of a miracle from us given how 4.1 
>> > went (and I'm hoping I will be proven wrong).
>> >
>> > In addition, are there any objections to cutting an 5.0-alpha1 release as 
>> > soon as we freeze?
>> >
>> > This is on the understanding vector, tcm and accord will become available 
>> > in later alphas.  Originally the discussion¹ was waiting for Accord for 
>> > alpha1, but a number of folk off-list have requested earlier alphas to 
>> > help with testing.
>> >
>> >
>> > ¹) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3

Re: Timing of the last releases of Cassandra 3.0.x / 3.11.x

[Brandon Williams]

On Wed, Aug 9, 2023 at 3:58 AM Miklosovic, Stefan
 wrote:
> There is a user on Slack asking for a release  of 3.11.16 because of 16555.

If people are showing interest, I think it's time.

> If we release right now, we might potentially do one more release before 5.0 
> is GA.

I think 5.0 is still far enough away from users' hands that we
shouldn't factor it into decisions about other releases.  We also
don't have to do a final release before 5.0, we can release anytime we
like.

Re: Timing of the last releases of Cassandra 3.0.x / 3.11.x

[Brandon Williams]

On Wed, Aug 9, 2023 at 8:48 AM Ekaterina Dimitrova
 wrote:
>
> Just thinking it might be easier to do the releases all together, from 
> operational perspective

I personally think, if anything, it's more overhead having multiple
releases in flight simultaneously.

Re: [DISCUSS] CASSANDRA-18743 Deprecation of metrics-reporter-config

[Brandon Williams]

+1

Kind Regards,
Brandon

On Fri, Aug 11, 2023 at 8:08 AM Ekaterina Dimitrova
 wrote:
>
>
> “ The rationale for this proposed deprecation is that the upcoming 5.0 
> release is a good time to evaluate dependencies that are no longer receiving 
> updates and will become risks in the future.”
>
> Thank you for raising it, I support your proposal for deprecation
>
> On Fri, 11 Aug 2023 at 8:55, Abe Ratnofsky  wrote:
>>
>> Hey folks,
>>
>> Opening a thread to get input on a proposed dependency deprecation in 5.0: 
>> metrics-reporter-config has been archived for 3 years and not updated in 
>> nearly 6 years.
>>
>> This project has a minor security issue with its usage of unsafe YAML 
>> loading via snakeyaml’s unprotected Constructor: 
>> https://nvd.nist.gov/vuln/detail/CVE-2022-1471
>>
>> This CVE is reasonable to suppress, since operators should be able to trust 
>> their YAML configuration files.
>>
>> The rationale for this proposed deprecation is that the upcoming 5.0 release 
>> is a good time to evaluate dependencies that are no longer receiving updates 
>> and will become risks in the future.
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-18743
>>
>> —
>> Abe
>>

Re: [Discuss] ​​CEP-35: Add PIP support for CQLSH

[Brandon Williams]

On Fri, Aug 11, 2023 at 2:13 AM Miklosovic, Stefan
 wrote:
>
> If we had an official PIP package, I can imagine that we would not ship CQLSH 
> in RPM at all (maybe not in DEB either?) so we would decouple this. A PIP 
> package is installable almost anywhere (if it is Python 3, that is the way 
> how I solved the problem in 18642, I just installed a PIP package because RPM 
> installation was broken).

I don't think we want to ship the database without any way to interact
with it.  Pip may also not be accessible to all installations.

> Another problem I see is that how do we say what CQLSH is compatible with 
> what Cassandra release? If we shipped CQLSH as a PIP package as part of the 
> tarball, we would guarantee that they play together. If it is living 
> somewhere online, how can be people sure that what they install is compatible 
> with Cassandra they run? I am sorry if this was already explained somewhere.

It is only guaranteed to work with the version it shipped with. It may
work with other versions, or it may have subtle issues that you could
spend a lot of time trying to figure out, as German and I recently
discovered.  To that end, I've created CASSANDRA-18745 so at least you
will know to expect problems when the versions don't match.

Re: [VOTE] Release Apache Cassandra 3.11.16

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Aug 10, 2023 at 1:43 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 3.11.16 for release.
>
> sha1: f86929eae086aa108cf58ee0164c3d12a59ad4af
> Git: https://github.com/apache/cassandra/tree/3.11.16-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1305/org/apache/cassandra/cassandra-all/3.11.16/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.16/
>
> 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://github.com/apache/cassandra/blob/3.11.16-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/3.11.16-tentative/NEWS.txt

Re: [Discuss] cleaning up build temp files

[Brandon Williams]

I think most of those use InMemoryAuditLogger so it's not a problem,
but we can call DatabaseDescriptor.setAuditLoggingOptions to change
the dir, the same way the AuditLoggerTest.testJMXArchive method does.

Kind Regards,
Brandon

On Mon, Aug 14, 2023 at 11:23 PM Derek Chen-Becker
 wrote:
>
> I think I'm 98% done with the needed changes (or at least a first pass; I'm 
> sure I'll get feedback), but I've hit an issue with AuditLoggerTest. While 
> AuditLogOptions has a String property for "audit_logs_dir", the test calls 
> StorageService.enableAuditLogs throught the test methods, and that method 
> does not take a parameter for the log directory. As a result, the 
> AuditLogOptions instance that is created always uses the default audit log 
> directory, which just happens to be the "audit" subdirectory of the project 
> root. This is getting into territory I'm not that familiar with, but it seems 
> like there might be three ways to fix this:
>
> 1. Write a new overload of StorageService.enableAuditLog that takes an 
> AuditLogOptions and delegate the other overloads to it
> 2. Add a new overload that also takes a Path or File pointing to the audit 
> log directory
> 3. Set the "cassandra.logdir.audit" property in the ant build, similar to 
> "tmp.dir"/"java.io.tmpdir"
>
> Thoughts?
>
> Derek
>
> On Sun, Aug 13, 2023 at 3:12 PM Josh McKenzie  wrote:
>>
>> There's also tests that hardcode
>>
>> I started mentally twitching when I hit that point in the sentence.
>>
>> Kill them with fire.
>>
>> On Sun, Aug 13, 2023, at 4:51 PM, Mick Semb Wever wrote:
>>
>>
>> https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/DirectoriesTest.java#L717-L719
>> https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/db/DirectoriesTest.java#L757-L759
>>
>> Can I open a ticket to track fixes for these and any other issues I run into 
>> while moving to using "build/tmp"?
>>
>>
>>
>> Go for it. :-)
>> There's also tests that hardcode other paths that breaks the use of 
>> `build.dir`
>>
>>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>

Re: [Discuss] cleaning up build temp files

[Brandon Williams]

On Tue, Aug 15, 2023 at 8:13 AM Derek Chen-Becker  wrote:
>
> Also, I noticed that the instructions on 
> https://cassandra.apache.org/_/development/how_to_commit.html mention "ant 
> jar check" as a recommended step, but there's not "check" target. Does it 
> mean "checkstyle"?

It exists in the cassandra-5.0 and trunk branches after CASSANDRA-18618

Re: [VOTE] Release Apache Cassandra 3.11.16 - SECOND ATTEMPT

[Brandon Williams]

+1

Kind Regards,
Brandon

On Tue, Aug 15, 2023 at 12:53 PM Miklosovic, Stefan
 wrote:
>
> This is the second attempt to pass the vote after [1] is fixed.
>
> Proposing the test build of Cassandra 3.11.16 for release.
>
> sha1: 681b6ca103d91d940a9fecb8cd812f58dd2490d0
> Git: https://github.com/apache/cassandra/tree/3.11.16-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1306/org/apache/cassandra/cassandra-all/3.11.16/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.16/
>
> 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]: https://issues.apache.org/jira/browse/CASSANDRA-18751
> [2]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/3.11.16-tentative/CHANGES.txt
> [3]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/3.11.16-tentative/NEWS.txt

Re: [VOTE] Release dtest-api 0.0.16

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi  wrote:
>
> Proposing the test build of in-jvm dtest API 0.0.16 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/1ba6ef93d0721741b5f6d6d72cba3da03fe78438
> tagged with 0.0.16
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1307/org/apache/cassandra/dtest-api/0.0.16/
>
> Key signature: 53371F9B1B425A336988B6A03B6042413D323470
>
> Changes since last release:
>
> * CASSANDRA-18727 - JMXUtil.getJmxConnector should retry connection attempts
>
> 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: [DISCUSSION] Shall we remove ant javadoc task?

[Brandon Williams]

big deal and can be easily fixed. From my point of
>> >> view, the problem is that the javadoc task is not given the attention
>> >> it deserves. The failonerror is currently 'false' and the task itself
>> >> is not a part of any build and/or release processes, correct me if I'm
>> >> wrong.
>> >>
>> >> So,
>> >> 1. Fix warnings/errors;
>> >> 2. Make the javadoc task part of the build (e.g. put it under
>> >> 'artifacts'), or make it part of the release process that is regularly
>> >> checked on the CI;
>> >> 3. Publish/deploy the javadoc htmls for release in the special
>> >> directory of the cassandra website to give them a chance of being
>> >> indexed;
>> >>
>> >> On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan  
>> >> wrote:
>> >> >
>> >> > I don’t think anyone wants to remove the javadocs.  This thread is 
>> >> > about removing the broken ant task which generates html files from them.
>> >> >
>> >> > +1 from me on removing the ant task.  If someone feels the task is 
>> >> > useful they can always implement one that does not crash and add it 
>> >> > back.
>> >> >
>> >> > -Jeremiah
>> >> >
>> >> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" 
>> >> >  wrote:
>> >> >>
>> >> >> I think that we can get more developers interested if there are 
>> >> >> available javadocs.  While many of the core classes are not going to 
>> >> >> be touched by someone just starting, being able to understand what the 
>> >> >> external touch points are and how they interact with other bits of the 
>> >> >> system can be invaluable, particularly when you don't have the entire 
>> >> >> code base in front of you.
>> >> >>
>> >> >> For example, I just wrote a tool that explores the distribution of 
>> >> >> keys across multiple sstables, I needed some of the tools classes but 
>> >> >> not much more.  Javadocs would have made that easy if I did not have 
>> >> >> the source code in front of me.
>> >> >>
>> >> >> I am -1 on removing the javadocs.
>> >> >>
>> >> >> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie  
>> >> >> wrote:
>> >> >>>
>> >> >>> If anything, the codebase could use a little more 
>> >> >>> package/class/method markup in some places
>> >> >>>
>> >> >>> I am impressed with how diplomatic and generous you're being here 
>> >> >>> Derek. :D
>> >> >>>
>> >> >>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
>> >> >>>
>> >> >>> That is a good idea. I would like to have Javadocs valid when going 
>> >> >>> through them in IDE. To enforce it, we would have to fix it first. If 
>> >> >>> we find a way how to validate Javadocs without actually rendering 
>> >> >>> them, that would be cool.
>> >> >>>
>> >> >>> There is a lot of legacy and rewriting of some custom-crafted 
>> >> >>> formatting of some comments might be quite a tedious task to do if it 
>> >> >>> is required to have them valid. I am in general for valid 
>> >> >>> documentation and even enforcing it but what to do with what is 
>> >> >>> already there ...
>> >> >>>
>> >> >>> 
>> >> >>> From: Jacek Lewandowski 
>> >> >>> Sent: Wednesday, August 2, 2023 23:38
>> >> >>> To: dev@cassandra.apache.org
>> >> >>> Subject: Re: [DISCUSSION] Shall we remove ant javadoc task?
>> >> >>>
>> >> >>> 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.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> With or without outputting JavaDoc to HTML, there are some errors 
>> >> >>> which we shou

Re: [Discuss] cleaning up build temp files

[Brandon Williams]

I will try to take a look tomorrow.

Kind Regards,
Brandon

On Sun, Aug 20, 2023 at 10:38 AM Derek Chen-Becker
 wrote:
>
> Hi,
>
> Would someone be able to review the trunk patch for 
> https://issues.apache.org/jira/browse/CASSANDRA-18750? I'm fighting CircleCI 
> to try and get anything to pass (everything fails with "Concurrency limit"), 
> but builds and tests work locally (via "ant test" and the docker 
> "run-tests.sh").
>
> Cheers,
>
> Derek
>
> On Tue, Aug 15, 2023 at 8:13 AM Derek Chen-Becker  
> wrote:
>>
>> Thanks, I thought I had updated against trunk but apparently missed it. It's 
>> working now.
>>
>> On Tue, Aug 15, 2023 at 7:27 AM Brandon Williams  wrote:
>>>
>>> On Tue, Aug 15, 2023 at 8:13 AM Derek Chen-Becker  
>>> wrote:
>>> >
>>> > Also, I noticed that the instructions on 
>>> > https://cassandra.apache.org/_/development/how_to_commit.html mention 
>>> > "ant jar check" as a recommended step, but there's not "check" target. 
>>> > Does it mean "checkstyle"?
>>>
>>> It exists in the cassandra-5.0 and trunk branches after CASSANDRA-18618
>>
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>

Re: [Discuss] Enabling JMX in in-jvm dtests (by default)

[Brandon Williams]

I would prefer to have one standard way to do it, and given the
options I would prefer it be proper JMX instead of mocking.

Kind Regards,
Brandon

On Fri, Aug 25, 2023 at 4:20 AM Miklosovic, Stefan
 wrote:
>
> Hi list,
>
> I want to gather a feedback for this comment (1).
>
> Long story short, until JMX feature was introduced, we kind of hacked / 
> mocked the calls to MBeans from IInstance, like this (2). If you notice, 
> there is a lot of methods throwing UnsupportedOperationException because we 
> had no proper JMX connection in place. That in turn means that tests which 
> call nodetool commands which are using these MBeans / operations are not 
> possible.
>
> The fix I made in CASSANDRA-18572 will use JMX feature and it will hook 
> nodetool to a proper JMX connection where we are not mocking anything etc ... 
> It will use same stuff as in production.
>
> However, this is happening only if one uses JMX feature. So all existing 
> tests calling nodetool without this feature will still use it like it was. 
> The patch I made takes care of both scenarios.
>
> My question is if we should not make JMX feature turned on by default. That 
> way we might further simplify the code base and get rid of the hacks.
>
> Another possibility is to not turn it on by default but we would add JMX 
> feature to each test which is using nodetool. That would also mean that any 
> future test which will use nodetool will fail if it does not have JMX feature 
> enabled.
>
> What would you like to see - dual solution (proper JMX connection if such 
> feature is used as well as the legacy way) or only one solution with a proper 
> JMX? (enabled by default or not).
>
> Regards
>
> (1) 
> https://issues.apache.org/jira/browse/CASSANDRA-18572?focusedCommentId=17758920&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17758920
> (2) 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/mock/nodetool/InternalNodeProbe.java

Re: [DISCUSS] Update default disk_access_mode to mmap_index_only on 5.0

[Brandon Williams]

Given https://issues.apache.org/jira/browse/CASSANDRA-17237 I think it
makes sense.  At the least I think we should restore disk_access_mode
so that users are more aware of the options available.

Kind Regards,
Brandon

On Wed, Sep 6, 2023 at 10:50 AM Paulo Motta  wrote:
>
> Hi,
>
> I've been bitten by OOMs with disk_access_mode:auto/mmap that were fixed by 
> changing to disk_access_mode:mmap_index_only. In a particular benchmark I got 
> 5x more read throughput on 3.11.x with disk_access_mode: mmap_index_only vs 
> disk_access_mode: auto/mmap.
>
> Changing disk_access_mode to mmap_index_only seems to be a common 
> recommendation on forums[1][2][3][4] and slack (find by searching 
> disk_access_mode in the #cassandra channel on https://the-asf.slack.com/).
>
> It's not clear to me when using the default disk_access_mode:auto/mmap is 
> beneficial, perhaps only when the read set fits in memory? Mick seems to 
> think on CASSANDRA-15531 [5], that mmap_index_only has a higher heap cost and 
> should be only used when warranted. However it's not uncommon to see people 
> being bitten with OOMs or lower read performance due to the default 
> disk_access_mode, so it makes me think it's not the best fool-proof default.
>
> Should we consider changing default "auto" behavior of "disk_access_mode" to 
> be "mmap_index_only" instead of "mmap" in 5.0 since it's likely safer and 
> perhaps more performant?
>
> Thanks,
>
> Paulo
>
> [1] 
> https://stackoverflow.com/questions/72272035/troubleshooting-and-fixing-cassandra-oom-issue
> [2] https://phabricator.wikimedia.org/T137419
> [3] https://stackoverflow.com/a/55975471
> [4] 
> https://support.datastax.com/s/article/FAQ-Use-of-disk-access-mode-in-DSE-51-and-earlier
> [5] https://issues.apache.org/jira/browse/CASSANDRA-15531

Re: [VOTE] Release Apache Cassandra 5.0-alpha1 (take3)

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Sep 4, 2023 at 3:26 PM Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER, this alpha release does not contain the expected 5.0
> features: Vector Search (CEP-30), Transactional Cluster Metadata
> (CEP-21) and Accord Transactions (CEP-15).  These features will land
> in a later alpha release.
>
> Please also note that this is an alpha release and what that means, further 
> info at 
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: bc5e3741d475e2e99fd7a10450681fd708431a89
> Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1316/org/apache/cassandra/cassandra-all/5.0-alpha1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/
>
> 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://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt
>

Re: [DISCUSS] Addition of smile-nlp test dependency for CEP-30

[Brandon Williams]

I don't see any problem with this, +1.

Kind Regards,
Brandon


On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson  wrote:

> CEP-30: [Approximate Nearest Neighbor(ANN) Vector Search via
> Storage-Attached Indexes] uses the smile-nlp library
> (com.github.haifengl.smile-nlp) in its testing to allow the creation of
> word2vec embeddings for valid input into the HNSW graph index.
>
> The reason for this library is that we found that using random vectors in
> testing produced very inconsistent results. Using the smile-nlp word2vec
> implementation with the glove.3k.50d library produces repeatable results.
>
> Does anyone have any objections to the use of this library as a test only
> dependency?
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSS] Addition of smile-nlp test dependency for CEP-30

[Brandon Williams]

On Wed, Sep 13, 2023 at 11:37 AM Jeff Jirsa  wrote:

> You can open a legal JIRA to confirm, but based on my understanding (and
> re-confirming reading
> https://www.apache.org/legal/resolved.html#category-a ):
>
>
We should probably get clarification here regardless, iirc this came up
when we were considering SpotBugs too.

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

[Brandon Williams]

I think it could be argued that not retrying messages is a bug, I am
+1 on including this in 5.0.

Kind Regards,
Brandon

On Tue, Sep 19, 2023 at 1:16 PM David Capwell  wrote:
>
> To try to get repair more stable, I added optional retry logic (patch is 
> still in review) to a handful of critical repair verbs.  This patch is 
> disabled by default but allows you to opt-in to retries so ephemeral issues 
> don’t cause a repair to fail after running for a long time (assuming they 
> resolve within the retry window). There are 2 protocol level changes to 
> enable this: VALIDATION_RSP and SYNC_RSP now send an ACK (if the sender 
> doesn’t attach a callback, these ACKs get ignored in all versions; see 
> org.apache.cassandra.net.ResponseVerbHandler#doVerb and Verb.REPAIR_RSP).  
> Given that we have already forked, I believe we would need to give a waiver 
> to allow this patch due to this change.
>
> The patch was written on trunk, but figured back porting 5.0 would be rather 
> trivial and this was brought up during the review, so floating this to a 
> wider audience.
>
> If you look at the patch you will see that it is very large, but this is only 
> to make testing of repair coordination easier and deterministic, the biggest 
> code changes are:
>
> 1) Moving from ActiveRepairService.instance to ActiveRepairService.instance() 
> (this is the main reason so many files were touched; this was needed so unit 
> tests don’t load the whole world)
> 2) Repair no longer reaches into global space and instead is provided the 
> subsystems needed to perform repair; this change is local to repair code
>
> Both of these changes were only for testing as they allow us to simulate 1k 
> repairs in around 15 seconds with 100% deterministic execution.

Re: [VOTE] Accept java-driver

[Brandon Williams]

+1

Kind Regards,
Brandon

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

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

[Brandon Williams]

On Fri, Oct 6, 2023 at 5:50 PM David Capwell  wrote:
> Lets say you now need to host replace node1

Won't the replacement have a newer generation?

> avoid peers mutating endpoint states they don’t own

This sounds reasonable to me.

> This would be a protocol change, so would need to make sure everyone is cool 
> with me doing this in 5.0.>

I don't think it is, this is just fixing a gossip bug, and we should
do so in all affected versions.

Kind Regards,
Brandon

Re: Need Confluent "Create" permission for filing a CEP

[Brandon Williams]

I've added you, you should have access now.

Kind Regards,
Brandon

On Tue, Oct 10, 2023 at 1:24 AM Jaydeep Chovatia
 wrote:
>
> Hi,
>
> I want to create a new CEP request but do not see the "Create" page 
> permission on Confluent. Could someone permit me?
> Here is the CEP draft: [DRAFT] CEP - Apache Cassandra Official Repair 
> Solution - Google Docs
>
> My confluent user-id is: chovatia.jayd...@gmail.com
>
> Jaydeep

Re: CASSANDRA-18775 (Cassandra supported OSs)

[Brandon Williams]

As noted on CASSANDRA-16565 we don't actually need sigar for anything,
so I don't see a reason to keep any of it, especially if that is going
to force us to specify OSes.

Kind Regards,
Brandon

On Fri, Oct 20, 2023 at 9:04 AM Claude Warren, Jr via dev
 wrote:
>
> I am looking at https://issues.apache.org/jira/browse/CASSANDRA-18775 and 
> want to ensure that I do not remove too many libraries.
>
> I think that preserving any sigar library where the file name contains the 
> word "linux" or "macosx" should be acceptable.  This will preserve:
> libsigar-amd64-linux.so
> libsigar-ia64-linux.so
> libsigar-ppc-linux.so
> libsigar-ppc64-aix-5.so
> libsigar-ppc64-linux.so
> libsigar-ppc64le-linux.so
> libsigar-s390x-linux.so
> libsigar-universal-macosx.dylib
> libsigar-universal64-macosx.dylib
> libsigar-x86-linux.so
>
> and remove:
>
> libsigar-amd64-freebsd-6.so
> libsigar-amd64-solaris.so
> libsigar-ia64-hpux-11.sl
> libsigar-pa-hpux-11.sl
> libsigar-ppc-aix-5.so
> libsigar-sparc-solaris.so
> libsigar-sparc64-solaris.so
> libsigar-x86-freebsd-5.so
> libsigar-x86-freebsd-6.so
> libsigar-x86-solaris.so
>
> resulting in a savings of 3,105,384 bytes out of 6,450,526 from the 
> /lib/sigar-bin directory, a 48% reduction.
>
> Does anyone see any reason _not_ to do this?

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Brandon Williams]

The concern I have with this is that is a big slippery 'if' that
involves development time estimation, and if it tends to take longer
than we estimate (as these things tend to do), then I can see a future
where 5.0 is delayed until the middle of 2024, and I really don't want
that to happen.  Maybe it won't be a glamorous release but shipping
5.0 mitigates our worst case scenario.

Kind Regards,
Brandon

On Mon, Oct 23, 2023 at 4:02 PM Dinesh Joshi  wrote:
>
> I have a strong preference to move out the 5.0 date to have accord and TCM. I 
> don’t see the point in shipping 5.0 without these features especially if 5.1 
> is going to follow close behind it.
>
> Dinesh
>
> On Oct 23, 2023, at 4:52 AM, Mick Semb Wever  wrote:
>
> 
>
> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
> propose the following.
>
> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
> immediate 5.1-alpha1 release.
>
> I see this as a win-win scenario for us, considering our current situation.  
> (Though it is unfortunate that Accord is included in this scenario because we 
> agreed it to be based upon TCM.)
>
> This will mean…
>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
> features users want.
>  - We get an alpha release with TCM and Accord into users hands quickly for 
> broader testing and feedback.
>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
> engineers time and patience reviewing and testing.  TCM will be the biggest 
> patch ever to land in C*.
>  - Give users a choice for a more incremental upgrade approach, given just 
> how many new features we're putting on them in one year.
>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 4.x 
> versions, just as if it had landed in 5.0.
>
>
> The risks/costs this introduces are
>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
> at some point decide to undo this work, while we can throw away the 
> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
> in trunk.  This is a _very_ edge case, as confidence levels on the design and 
> implementation of both are already tested and high.
>  - We will have to maintain an additional branch.  I propose that we treat 
> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
> and 3.11).  This also adds the merge path overhead.
>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
> not our normal practice, but this work will have already received its two +1s 
> from committers, and such ongoing review effort is akin to GA stabilisation 
> work on release branches.
>
>
> I see no other ok solution in front of us that gets us at least both the 5.0 
> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
> to start experimenting with these features, and our Cassandra Summit in 
> December.
>
>
> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>
>

Re: CASSANDRA-16565

[Brandon Williams]

On Tue, Oct 24, 2023 at 7:48 AM Claude Warren, Jr via dev
 wrote:
>
> Is there someplace I can stash the tgz that others can download it from? The 
> file info is : 6269066 okt 24 12:46 compare_oshi_sigar.tgz

Is posting a github branch not sufficient?

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai  wrote:
>
> Hi,
>
> I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to trunk 
> and hope we are all OK with it.
>
> In CASSANDRA-18941, I am adding the capability to produce size-bounded 
> SSTables in CQLSSTableWriter for sorted data. It can greatly benefit 
> Cassandra Analytics (https://github.com/apache/cassandra-analytics) for bulk 
> writing SSTables, since it avoids buffering and sorting on flush, given the 
> data source is sorted already in the bulk write process. Cassandra Analytics 
> supports Cassandra 4.0 and depends on the cassandra-all 4.0.x library. 
> Therefore, we are mostly interested in using the new capability in 4.0.
>
> CQLSSTableWriter is only used in offline tools and never in the code path of 
> Cassandra server.
>
> Any objections to merging the patch to 4.0 and up to trunk?
>
> - Yifan

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Brandon Williams]

, my point of view is changing.
>>
>>
>> Josh's point about what's best for users is crucial. Users deserve stable
>>
>> code with a regular cadence of features that make their lives easier. If we
>>
>> put 5.0 on hold for TCM + Accord, users will get neither for a very long
>>
>> time. And I mentioned a disaster yesterday. A bigger disaster would be
>>
>> shipping Accord with a major bug that causes data loss, eroding community
>>
>> trust. Accord has to be the most bulletproof of all bulletproof features.
>>
>> The pressure to ship is only going to increase and that's fertile ground
>>
>> for that sort of bug.
>>
>>
>> So, taking a step back and with a clearer picture, I support the 5.0 + 5.1
>>
>> plan mainly because I don't think 5.1 is (or should be) a fast follow.
>>
>>
>> For the user community, the communication should be straightforward. TCM +
>>
>> Accord are turning out to be much more complicated than was originally
>>
>> scoped, and for good reasons. Our first principle is to provide a stable
>>
>> and reliable system, so as a result, we'll be de-coupling TCM + Accord from
>>
>> 5.0 into a 5.1 branch, which is available in parallel to 5.0 while
>>
>> additional hardening and testing is done. We can communicate this in a blog
>>
>> post.,
>>
>>
>> To make this much more palatable to our use community, if we can get a
>>
>> build and docker image available ASAP with Accord, it will allow developers
>>
>> to start playing with the syntax. Up to this point, that hasn't been widely
>>
>> available unless you compile the code yourself. Developers need to
>>
>> understand how this will work in an application, and up to this point, the
>>
>> syntax is text they see in my slides. We need to get some hands-on and that
>>
>> will get our user community engaged on Accord this calendar year. The
>>
>> feedback may even uncover some critical changes we'll need to make. Lack of
>>
>> access to Accord by developers is a critical problem we can fix soon and
>>
>> there will be plenty of excitement there and start building use cases
>>
>> before the final code ships.
>>
>>
>> I'm bummed but realistic. It sucks that I won't have a pony for Christmas,
>>
>> but maybe one for my birthday?
>>
>>
>> Patrick
>>
>>
>>
>>
>> On Tue, Oct 24, 2023 at 7:23 AM Josh McKenzie  wrote:
>>
>>
>> > Maybe it won't be a glamorous release but shipping
>>
>> > 5.0 mitigates our worst case scenario.
>>
>> >
>>
>> > I disagree with this characterization of 5.0 personally. UCS, SAI, Trie
>>
>> > memtables and sstables, maybe vector ANN if the sub-tasks on C-18715 are
>>
>> > accurate, all combine to make 5.0 a pretty glamorous release IMO
>>
>> > independent of TCM and Accord. Accord is a true paradigm-shift game-changer
>>
>> > so it's easy to think of 5.0 as uneventful in comparison, and TCM helps
>>
>> > resolve one of the biggest pain-points in our system for over a decade, but
>>
>> > I think 5.0 is a very meaty release in its own right today.
>>
>> >
>>
>> > Anyway - I agree with you Brandon re: timelines. If things take longer
>>
>> > than we'd hope (which, if I think back, they do roughly 100% of the time on
>>
>> > this project), blocking on these features could both lead to a significant
>>
>> > delay in 5.0 going out as well as increasing pressure and risk of burnout
>>
>> > on the folks working on it. While I believe we all need some balanced
>>
>> > urgency to do our best work, being under the gun for something with a hard
>>
>> > deadline or having an entire project drag along blocked on you is not where
>>
>> > I want any of us to be.
>>
>> >
>>
>> > Part of why we talked about going to primarily annual calendar-based
>>
>> > releases was to avoid precisely this situation, where something that
>>
>> > *feels* right at the cusp of merging leads us to delay a release
>>
>> > repeatedly. We discussed this a couple times this year:
>>
>> > 1: https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3,
>>
>> > where Mick proposed a "soft-freeze" for everything w/out exception and 1st
>>
>> > week October "hard-fr

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Oct 30, 2023 at 4:47 PM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 5.0-alpha2 for release.
>
> DISCLAIMER, this alpha release does not contain the features:
> Transactional Cluster Metadata (CEP-21) and Accord Transactions
> (CEP-15).  These features are under discussion to be pushed to a
> 5.1-alpha1 release, with an eta still this year.
>
> This release does contain Vector Similarity Search (CEP-30).
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: ea76d148c374198fede6978422895668857a927f
> Git: https://github.com/apache/cassandra/tree/5.0-alpha2-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1317/org/apache/cassandra/cassandra-all/5.0-alpha2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha2/
>
> 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://github.com/apache/cassandra/blob/5.0-alpha2-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-alpha2-tentative/NEWS.txt

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

[Brandon Williams]

I agree and just now opened it for 5.0-beta (among others.)

Kind Regards,
Brandon

On Sat, Nov 4, 2023 at 11:08 AM Benedict  wrote:
>
> I think before we cut a beta we need to have diagnosed and fixed 18993 
> (assuming it is a bug).
>
> > On 4 Nov 2023, at 16:04, Mick Semb Wever  wrote:
> >
> > 
> >>
> >> With the publication of this release I would like to switch the
> >> default 'latest' docs on the website from 4.1 to 5.0.  Are there any
> >> objections to this ?
> >
> >
> > I would also like to propose the next 5.0 release to be 5.0-beta1
> >
> > With the aim of reaching GA for the Summit, I would like to suggest we
> > work towards the best-case scenario of 5.0-beta1 in two weeks and
> > 5.0-rc1 first week Dec.
> >
> > I know this is a huge ask with lots of unknowns we can't actually
> > commit to.  But I believe it is a worthy goal, and possible if nothing
> > sideswipes us – but we'll need all the help we can get this month to
> > make it happen.
>

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

[Brandon Williams]

As long as it's disabled by default that's an easy +1 from me.

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 7:03 AM Jacek Lewandowski
 wrote:
>
> Hey,
>
> I'd like to ask if we can include 
> https://issues.apache.org/jira/browse/CASSANDRA-18464 in the 5.0-beta1 
> release. This introduces the ability to write to the commitlog using direct 
> I/O and bringing some noticeable performance improvements when enabled 
> (disabled by default).
>
> Since it introduces a change in the yaml config, it probably cannot be 
> delivered in RC or 5.0.x - hence my question.
>
> The ticket has been reviewed and tested. It is basically in the 
> read-to-commit state.
>
> thanks,
> Jacek
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

On Mon, Nov 27, 2023 at 9:25 AM Mick Semb Wever  wrote:
>
> It was agreed to move them to 5.0-rc

Where?

Re: [DISCUSS] Harry in-tree

[Brandon Williams]

I am +1 on including Harry in-tree.

Kind Regards,
Brandon

On Fri, Nov 24, 2023 at 9:44 AM Alex Petrov  wrote:
>
> Hi everyone,
>
> With TCM landed, there will be way more Harry tests in-tree: we are using it 
> for many coordination tests, and there's now a simulator test that uses 
> Harry. During development, Harry has allowed us to uncover and resolve 
> numerous elusive edge cases.
>
> I had conversations with several folks, and wanted to propose to move 
> harry-core to Cassandra test tree. This will substantially 
> simplify/streamline co-development of Cassandra and Harry. With a new 
> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
> will also be much more approachable.
>
> Besides making it easier for everyone to develop new fuzz tests, it will also 
> substantially lower the barrier to entry. Currently, debugging an issue found 
> by Harry involves a cumbersome process of rebuilding and transferring jars 
> between Cassandra and Harry, depending on which side you modify. This not 
> only hampers efficiency but also deters broader adoption. By merging 
> harry-core into the Cassandra test tree, we eliminate this barrier.
>
> Thank you,
> --Alex
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: Request to create a Jira account

[Brandon Williams]

Please request one here: https://selfserve.apache.org/jira-account.html

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 3:29 PM Rajneesh  wrote:
>
> Hi,
>
> I am looking to contribute to Cassandra.
>
> I am going through the How-To here - 
> https://cassandra.apache.org/_/development/index.html
>
> Following what is mentioned in the above guide, I'm planning to start from 
> the Low Hanging Fruit.
>
> May I please have a Jira account?
>
> - Regards

Re: Request to create a Jira account

[Brandon Williams]

You should hopefully have your account now, welcome to Apache
Cassandra, Rajneesh!

Kind Regards,
Brandon

On Mon, Nov 27, 2023 at 4:30 PM Rajneesh  wrote:
>
> Thank you, Brandon!
>
> -Regards
>
>
> On Mon, Nov 27, 2023 at 1:34 PM Brandon Williams  wrote:
>>
>> Please request one here: https://selfserve.apache.org/jira-account.html
>>
>> Kind Regards,
>> Brandon
>>
>> On Mon, Nov 27, 2023 at 3:29 PM Rajneesh  wrote:
>> >
>> > Hi,
>> >
>> > I am looking to contribute to Cassandra.
>> >
>> > I am going through the How-To here - 
>> > https://cassandra.apache.org/_/development/index.html
>> >
>> > Following what is mentioned in the above guide, I'm planning to start from 
>> > the Low Hanging Fruit.
>> >
>> > May I please have a Jira account?
>> >
>> > - Regards