Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 On 2023/02/06 16:15:19 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/h25skwkbdztz9hj2pxtgh39r

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

Good suggestion Mike. I'm +1 on the idea and agree the name KEYSPACE is confusing to new users. Jon On 2023/04/04 15:48:26 Mike Adamson wrote: > Hi, > > I'd like to propose that we add DATABASE to the CQL grammar as an > alternative to KEYSPACE. > > Background: While TABLE was introduced as a

Re: [DISCUSS] [PATCH] Enable Direct I/O For CommitLog Files

This sounds awesome. Could you share the fio configuration you used to benchmark and what hardware you used? On 2023/04/18 18:10:24 "Pawar, Amit" wrote: > [Public] > > Hi, > > I shared my investigation about Commitlog I/O issue on large core count > system in my previous email dated July-2

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

+1. Awesome work Doug! Great to see this moving forward. On 2023/05/04 18:34:46 "C. Scott Andreas" wrote: > +1nb.As someone familiar with this work, it's pretty hard to overstate the > impact it has on completing Cassandra's HTAP story. Eliminating the overhead > of bulk reads and writes on

Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 On 2023/06/13 14:14:35 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 d

Re: [Discuss] Repair inside C*

I'm 100% in favor of repair being part of the core DB, not the sidecar. The current (and past) state of things where running the DB correctly *requires* running a separate process (either community maintained or official C* sidecar) is incredibly painful for folks. The idea that your data inte

Re: Status Update on CEP-7 Storage Attached Indexes (SAI)

Very nice! I'll kick the tires a bit, and add a sai test to tlp-stress On 2023/07/26 18:56:29 Caleb Rackliffe wrote: > Alright, the cep-7-sai branch is now merged to trunk! > > Now we move to addressing the most urgent items from "Phase 2" ( > CASSANDRA-18473

Re: Tokenization and SAI query syntax

Certain bits of functionality also already exist on the SASI side of things, but I'm not sure how much overlap there is. Currently, there's a LIKE keyword that handles token matching, although it seems to have some differences from the feature set in SAI. That said, there seems to be enough

Re: [Discuss] Repair inside C*

heduling solution in the sidecar, and there is nothing > that would prevent someone from continuing to use a sidecar-based solution in > perpetuity if they preferred. > > - Scott > > > On Jul 26, 2023, at 3:25 PM, Jon Haddad wrote: > > > > I'm 100% in favo

Re: Tokenization and SAI query syntax

; > > I do not think LIKE actually applies here. LIKE is used for prefix, > > contains, or suffix searches in SASI depending on the index type. > > > > This is about exact matching of tokens. > > > >> On Aug 2, 2023, at 5:53 PM, Jon Haddad wrote: >

Re: Tokenization and SAI query syntax

ing/not liking. > > > > > On Aug 2, 2023, at 7:18 PM, J. D. Jordan > > wrote: > > > > > > I do not think LIKE actually applies here. LIKE is used for prefix, > > contains, or suffix searches in SASI depending on the index type. > > > > > &g

Re: Tokenization and SAI query syntax

to : > >>>> > >>>> It is very dissimilar to our current operators. CQL is already not the > >>>> prettiest language, but let’s not make it a total mish mash. > >>>> > >>>> > >>>> > >>>

Re: Tokenization and SAI query syntax

point. > > > On Aug 13, 2023, at 12:53 PM, Jon Haddad wrote: > > > > Functions make sense to me too. In addition to the reasons listed, I if > > we acknowledge that functions in predicates are inevitable, then it makes > > total sense to use them here. I

Re: [VOTE] Accept java-driver

+1 On 2023/10/03 04:52:47 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

Re: [DISCUSS] CommitLog default disk access mode

I haven't looked at the patch, but at a high level, defaulting to direct I/O for commit logs makes a lot of sense to me. On 2023/10/16 06:34:05 "Pawar, Amit" wrote: > [Public] > > Hi, > > CommitLog uses mmap (memory mapped ) segments by default. Direct-IO feature > is proposed through new PR

Re: [DISCUSS] CommitLog default disk access mode

of direct IO could well be of > benefit eg in compaction - and also in future if we manage to bring a page > management in process. So laying foundations there could be of benefit, even > if the commit log eventually does not use it. > > > On 16 Oct 2023, at 17:00, Jon Haddad

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

>From the folks I've been talking to - Accord is one of the biggest things to >be excited about in 5.0. Everyone giving a presentation about the 5.0 release >has been hyping up accord. Shipping a release to make a date (that means practically nothing to most people) by gutting one of the mos

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

I think this is a great more generally useful than the two scenarios you've outlined. I think it could / should be possible to use an object store as the primary storage for sstables and rely on local disk as a cache for reads. I don't know the roadmap for TCM, but imo if it allowed for more

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

I guess at the end of the day, shipping a release with a bunch of awesome features is better than holding it back. If there's 2 big releases in 6 months the community isn't any worse off. We either ship something, or nothing, and something is probably better. Jon On 2023/10/24 16:27:04 Pat

Re: Voice of Apache (Feathercast) at summit?

Count me in! On 2023/12/05 14:34:48 Rich Bowen wrote: > Hey, folks. I'll be at Cassandra Summit next week, and was wondering if any > of you who might be there would be interested in doing a podcast interview > with me for Voice Of Apache (the podcast formerly known as Feathercast - see > https

Ext4 data corruption in stable kernels

Hey folks, Just wanted to raise awareness about a I/O issue that seems to be affecting some Linux Kernal releases that were listed as STABLE, causing corruption when using the ext4 filesystem with direct I/O. I don't have time to get a great understanding of the full scope of the issue, what vers

Re: Ext4 data corruption in stable kernels

s > > > pon., 11 gru 2023, 20:45 użytkownik Jon Haddad > napisał: > >> Hey folks, >> >> Just wanted to raise awareness about a I/O issue that seems to be >> affecting some Linux Kernal releases that were listed as STABLE, causing >> corruption when us

Re: [DISCUSS] CEP-39: Cost Based Optimizer

I think it makes sense to see what the actual overhead is of CBO before making the assumption it'll be so high that we need to have two code paths. I'm happy to provide thorough benchmarking and analysis when it reaches a testing phase. I'm excited to see where this goes. I think it sounds very

Re: Future direction for the row cache and OHC implementation

I think we should probably figure out how much value it actually provides by getting some benchmarks around a few use cases along with some profiling. tlp-stress has a --rowcache flag that I added a while back to be able to do this exact test. I was looking for a use case to profile and write up

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

At a high level I really like the idea of being able to better leverage cheaper storage especially object stores like S3. One important thing though - I feel pretty strongly that there's a big, deal breaking downside. Backups, disk failure policies, snapshots and possibly repairs would get more

Re: Future direction for the row cache and OHC implementation

Sure, I’d love to work with you on this. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Mon, Dec 18, 2023 at 8:30 AM Ariel Weisberg wrote: > Hi, > > Thanks for the generous offer. Before you do that can you give me a chance > to add back support for Caffeine for t

Re: [DISCUSSION] CEP-38: CQL Management API

I like the idea of the ability to execute certain commands via CQL, but I think it only makes sense for the nodetool commands that cause an action to take place, such as compact or repair. We already have virtual tables, I don't think we need another layer to run informational queries. I see litt

Re: [DISCUSSION] CEP-38: CQL Management API

t; I think this is a solvable problem, and I think the benefits of having a > single, elegant way of interacting with a cluster and configuring it > justifies the investment for us as a project. Assuming someone has the > cycles to, you know, actually do the work. :D > > On Sun, Jan 7

Re: [DISCUSSION] CEP-38: CQL Management API

e emails. Jon On Mon, Jan 8, 2024 at 4:11 PM Jon Haddad wrote: > > Syntactically, if we’re updating settings like compaction throughput, I > would prefer to simply update a virtual settings table > > e.g. UPDATE system.settings SET compaction_throughput = 128 > > I agr

Re: [DISCUSSION] CEP-38: CQL Management API

the JMX and CQL APIs, so that > users will have a sense of the commands they are using and are less > likely to check the documentation; > - It will be easier for us to move the nodetool from the jmx client > that is used under the hood to an implementation based on a > java-driver and use the

Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

Server side rate limiting can be useful, but imo if we were to focus effort into a single place, time would be much better spent adding adaptive rate limiting to the drivers. Rate limiting at the driver level can be done based on 2 simple feedback mechanisms - error rate and latency. When a node

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

I am definitely +1 on the ability to rate limit operations to tables and keyspaces, and if we can do it at a granular level per user I'm +1 to that as well. I think this would need to be exposed to the operator regardless of any automatic rate limiter. Thinking about the bigger picture for a minu

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

ead of pretending we can outsmart the very > complex system > > On Jan 18, 2024, at 4:56 PM, Jon Haddad wrote: > >  > I am definitely +1 on the ability to rate limit operations to tables and > keyspaces, and if we can do it at a granular level per user I'm +1 to that >

Re: [Discuss] CASSANDRA-16999 introduction of a column in system.peers_v2

+1 to deprecating dual ports and removing in 5.0 On Tue, Feb 13, 2024 at 4:29 AM Štefan Miklošovič < stefan.mikloso...@gmail.com> wrote: > Alright ... so how I am interpreting this, even more so after Sam's and > Brandon's mail, is that we should just get rid of that completely in trunk > and de

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

Stefan, can you elaborate on what you are proposing? It's not clear (at least to me) what level of testing you're advocating for. Dropping testing both on dev branches, every commit, just on release? In addition, can you elaborate on what is a hassle about it? It's been a long time since I comm

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

Would it make sense to only block commits on the test strategy you've listed, and shift the entire massive test suite to post-commit? If there really is only a small % of times the entire suite is useful this seems like it could unblock the dev cycle but still have the benefit of the full test sui

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

hing. All suites, all supported JDK's, both config files. >> >> With Butler + the *jenkins-jira* integration script >> <https://github.com/apache/cassandra-builds/blob/trunk/jenkins-jira-integration/jenkins_jira_integration.py>(need >> to dust that off but it should re

Re: [DISCUSS] CQL handling of WHERE clause predicates

I like the idea of accepting more types of queries with fewer restrictions. I think we've been moving in the right direction, with SAI opening up more types of query possibilities. I think the long term path towards more flexibility requires paying off some technical debt. We have a ton of place

Re: [DISCUSS] Modeling JIRA fix version for subprojects

Imo it would be better to have standalone JIRA projects for each of the subprojects we have, just like we do the sidecar. On Thu, Apr 4, 2024 at 10:47 AM Francisco Guerrero wrote: > Hi Bret, > > Thanks for bringing up this issue. The Cassandra Analytics library will > also need to have its own v

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

This seems like a lot of work to create an rsync alternative. I can't really say I see the point. I noticed your "rejected alternatives" mentions it with this note: - However, it might not be permitted by the administrator or available in various environments such as Kubernetes or virtual

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

SSH privileges of particular users; and eliminates the need to manage >> and secure rsyncd processes on each instance if not via SSH. >> >> – An ecosystem-native approach is more instrumentable and measurable than >> rsync. Support for data migration endpoints in the sidecar

Re: [VOTE] Release Apache Cassandra 3.0.30

+1 On Mon, Apr 15, 2024 at 7:49 AM Mick Semb Wever wrote: > > > >> Proposing the test build of Cassandra 3.0.30 for release. >> > > > +1 > > > Checked > - signing correct > - checksums are correct > - source artefact builds > - binary artefact runs > - debian package runs > - debian repo install

Re: [VOTE] Release Apache Cassandra 3.11.17

+1 On Mon, Apr 15, 2024 at 8:03 AM Mick Semb Wever wrote: > > > >> Proposing the test build of Cassandra 3.11.17 for release. > > > > > > +1 > > > Checked > - signing correct > - checksums are correct > - source artefact builds > - binary artefact runs > - debian package runs > - debian repo ins

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Ariel, having it in C* process makes sense to me. Please correct me if I'm wrong here, but shouldn't using ZCS to transfer have no distinguishable difference in overhead from doing it using the sidecar? Since the underlying call is sendfile, never hitting userspace, I can't see why we'd opt for t

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Hmm... I guess if you're using encryption you can't use ZCS so there's that. It probably makes sense to implement kernel TLS: https://www.kernel.org/doc/html/v5.7/networking/tls.html Then we can get ZCS all the time, for bootstrap & replacements. Jon On Thu, Apr 18, 2

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

gt;> instance. >> >> Alternatively, Cassandra itself could have some flag to start up with >> limited >> subsystems enabled to allow live migration. >> >> In any case, we'll need to weigh in the pros and cons of each alternative >> and >> decide

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

Jeff, this is probably the best explanation and justification of the idea that I've heard so far. I like it because 1) we really should have something official for backups 2) backups / object store would be great for analytics 3) it solves a much bigger problem than the single goal of moving inst

Re: discuss: add to_human_size function

I can’t see a good reason not to support it. Seems like extra work to avoid with no benefit. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Thu, Apr 25, 2024 at 7:16 AM Štefan Miklošovič < stefan.mikloso...@gmail.com> wrote: > Can you elaborate on intentionally not s

[DISCUSS] Donating easy-cass-stress to the project

I've been asked by quite a few people, both in person and in JIRA [1] about contributing easy-cass-stress [2] to the project. I've been happy to maintain the project myself over the years but given its widespread use I think it makes sense to make it more widely available and under the project's u

Re: [DISCUSS] Donating easy-cass-stress to the project

in-tree. > > Kind Regards, > Brandon > > On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad wrote: > > > > I've been asked by quite a few people, both in person and in JIRA [1] > about contributing easy-cass-stress [2] to the project. I've been happy to > main

Re: [DISCUSS] Donating easy-cass-stress to the project

ustify creating a subproject > > And if there’s not 2-3 people expressing interest, even pulling it into > the main project seems risky > > So: besides Jon, who in the community expects/desires to maintain this > going forward? > > On Apr 25, 2024, at 5:55 PM, Jon Haddad wro

Re: [DISCUSS] Donating easy-cass-stress to the project

it's only going to make my life harder to move under the project umbrella. I don't want to go from my wild west style of committing whatever I want to waiting around for days or weeks to get features committed. Project rename happened here: commit 6c9493254f7bed57f19aaf5bda19f0b773

Re: [VOTE] Release Apache Cassandra 4.1.5

+1 On Thu, May 2, 2024 at 9:37 AM Brandon Williams wrote: > Proposing the test build of Cassandra 4.1.5 for release. > > sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a > Git: https://github.com/apache/cassandra/tree/4.1.5-tentative > Maven Artifacts: > > https://repository.apache.org/content/rep

Re: [RESULT] [VOTE] Release Apache Cassandra 3.0.30

Brandon, myself, and Mick are +1 PMC votes. On Tue, May 7, 2024 at 4:46 PM Justin Mclean wrote: > Hi, > > In the vote thread, there are only two explicit +1 PMC votes. In the > future, it would be best to wait for three +1 votes, or the release manager > should also vote. > > Kind Regards, > Jus

Re: [RESULT] [VOTE] Release Apache Cassandra 3.0.30

Justin, I just re-read what you wrote, and I think you're saying that you're not counting Brandon's original email as a vote? Is that correct? Jon On Tue, May 7, 2024 at 6:01 PM Jon Haddad wrote: > Brandon, myself, and Mick are +1 PMC votes. > > On Tue, May 7, 2024

Re: [DISCUSS] Adding support for BETWEEN operator

Is there a technical limitation that would prevent a range write that functions the same way as a range tombstone, other than probably needing a version bump of the storage format? On Tue, May 14, 2024 at 12:03 AM Benjamin Lerer wrote: > Range restrictions (>, >=, =<, < and BETWEEN) do not work

Re: [DISCUSS] Adding support for BETWEEN operator

r in the long term. > > On 14/05/2024 16:59, Benjamin Lerer wrote: > > It should be like range tombstones ... in much worse ;-). A tombstone is a > simple marker (deleted). An update can be far more complex. > > Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : > >&

Re: [DISCUSS] Adding support for BETWEEN operator

; > It is not simply a gut feeling, Jon. This change impacts read, write, > indexing, storage, compaction, repair... The risk and cost associated with > it are pretty significant and I am not convinced at this point of its > benefit. > > Le mar. 14 mai 2024 à 19:05, Jon Haddad a écrit :

Re: [DISCUSS] Gossip Protocol Change

I have also recently worked with a teams who lost critical data as a result of gossip issues combined with collision in our token allocation. I haven’t filed a jira yet as it slipped my mind but I’ve seen it in my own testing as well. I’ll get a JIRA in describing it in detail. It’s severe enough

Re: [DISCUSS] Adding support for BETWEEN operator

gt; operator, and there’s no reason we should pollute the conversation of “add > a missing SQL operator that basically maps to existing functionality” with > creation of a brand new form of update that definitely doesn’t map to any > existing concepts. > > > > > > On May 14

Re: [DISCUSS] CEP-42: Constraints Framework

The idea is interesting. I think it would help to have more concrete examples. It's a bit sparse at the moment, and I have a hard time getting on board with new features where the main selling point is Extensibility over the value they provide on their own. I think it would help a lot if we knew

Re: [DISCUSS] CEP-42: Constraints Framework

CONSTRAINT b < 255, > ) > > > Another types of constraints and functions can be added in the future to > provide even more flexibility, but are out of the scope of this CEP. > > Bernardo > > On Jun 4, 2024, at 1:01 PM, Jon Haddad wrote: > > The idea is interesting.

Re: [DISCUSS] CEP-42: Constraints Framework

log. >>>> >>>> Let's take this into consideration (T = time) >>>> >>>> T0 - a node is started with no guardrails set >>>> T1 - guardrail is set via JMX to not allow anything bigger than size of >>>> 10 (whatever size mea

Re: [DISCUSS] CEP-42: Constraints Framework

I think having JSON validation on existing text fields is a pretty reasonable idea, regardless if we have a JSON type or not. I could see folks wanting to add a JSON constraint to an existing text field, for example. I like the idea of a postgres-style JSONB type, but I don't want to derail this

Re: Suggestions for CASSANDRA-18078

Agreed. If we release it, we can’t remove it after. Option 2 is off the table. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Thu, Jun 20, 2024 at 7:13 PM Jeff Jirsa wrote: > If we have a public-facing API that we’re contemplating releasing to the > public, and we don’t

Re: Suggestions for CASSANDRA-18078

I’m on vacation, so I’ll keep this brief. While its not the end of the world, I think shipping a feature that’s immediately deprecated reflects poorly on the project and our ability to manage it. I don’t know how much work need to be done to merge that patch, so its hard to say if we should wait

Re: [DISCUSS] Increments on non-existent rows in Accord

Seems to me that this should use the same behavior as a counter unless IF EXISTS is supplied. I can see a solid argument for failing though, if the argument is that only counters behave that way, vs increment / decrement. On Fri, Jun 21, 2024 at 4:32 PM Josh McKenzie wrote: > What about abort

Re: [DISCUSS] spark-cassandra-connector donation to Analytics subproject

I also think it would be a great contribution, especially since the bulk analytics library can’t be used by the majority of teams, since it’s hard coded to only work with single token clusters. On Mon, Jun 24, 2024 at 9:51 AM Dinesh Joshi wrote: > This would be a great contribution to have for

Re: [DISCUSS] CEP-42: Constraints Framework

duplicate concepts we should. — Jon Haddad Rustyrazorblade Consulting rustyrazorblade.com On Mon, Jun 24, 2024 at 4:19 PM Doug Rohrer wrote: > To your point about Guardrails vs. Constraints, I do think the distinct > roles of “cluster operator” and “application developer” help show how

Re: [DISCUSS] CEP-42: Constraints Framework

I think my suggestion was unclear. I was referring to the name guardrail, using the same infra as guardrails, rather than a separate concept. Not applying it like we do table options. On Tue, Jun 25, 2024 at 12:44 AM Bernardo Botella < conta...@bernardobotella.com> wrote: > Hi Ariel and Jon, >

Re: [VOTE] Release Apache Cassandra 5.0-rc1

5.0 is a massive milestone. A huge thank you to everyone that's invested their time into the release. I've done a lot of testing, benchmarking, and tire kicking and it's truly mind blowing how much has gone into 5.0 and how great it is for the community. I am a bit concerned that CASSANDRA-19668

Re: [VOTE][IP CLEARANCE] GoCQL driver

+1. On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan wrote: > +1 nb. Good to see this heavily used driver get continued development in > the project. > > > On Jun 25, 2024, at 5:29 PM, Michael Shuler > wrote: > > > > +1 > > > > Kind regards, > > Michael > > > >> On 6/25/24 12:29, Mick Semb Wever w

Re: [VOTE] Release Apache Cassandra 5.0-rc1

et a sense of strong usage from the community, > >>> so I agree that RC shouldn't be blocked but this can get fixed before > >>> GA. +1 from me. > >>> > >>> Kind Regards, > >>> Brandon > >>> > >>> On Tue, Jun 25

Re: [VOTE] Release Apache Cassandra 5.0-rc1

Thanks for confirming this, Blake. I agree that we should not knowingly ship new versions with severe bugs that cause the DB to crash, regression or not. -1 from me as well On Fri, Jun 28, 2024 at 1:39 AM Blake Eggleston wrote: > Looking at the ticket, I’d say Jon’s concern is legitimate. The

Re: [VOTE] Release Apache Cassandra 5.0-rc1

be a blocker for me, if that's the case. https://issues.apache.org/jira/browse/CASSANDRA-19735 Jon On Thu, Jun 27, 2024 at 9:49 PM Jon Haddad wrote: > Thanks for confirming this, Blake. I agree that we should not knowingly > ship new versions with severe bugs that cause the DB to crash,

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

> I personally don't have anything against what you suggested, however I think that this kind of work will put additional stress on us being sure that the output of the commands will be exactly as it is now. We do have nodetool tests which are covering the tests for the output which is very handy i

Re: [VOTE] CEP-42: Constraints Framework

+1 On Tue, Jul 2, 2024 at 5:06 AM wrote: > +1 > > > On Jul 1, 2024, at 8:34 PM, Doug Rohrer wrote: > > +1 (nb) - Thanks for all of the suggestions and Bernardo for wrangling the > CEP into shape! > > Doug > > On Jul 1, 2024, at 3:06 PM, Dinesh Joshi wrote: > > +1 > > On Mon, Jul 1, 2024 at 11:

Re: [VOTE] Release Apache Cassandra 5.0-rc1 (take2)

+1 Thanks Mick! On Tue, Jul 2, 2024 at 4:20 AM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 5.0-rc1 for release. > > sha1: 01eea8a0d74deaede236edb25335fa470502106e > Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative > Maven Artifacts: > https://repository.apach

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

Without getting into the pros and cons of both libraries, I have to point out there's something unsettling about making decisions about libraries we used based on arbitrary rules an employer has put into place on its employees. The project isn't governed by Apple, it's governed by individual contr

Re: Audit logging to tables.

paction > > >> > > > >> > > pressure, > > >> > > > >> > > > > > >>> flushing > > >> > > > >> > > > > > >>>>> pressure, etc) from that, there's a > > compounding > > >> > effect > > >> > > > of > > >> > > > >> > >

Re: Stabilising Internode Messaging in 4.0

Given the number of issues that are addressed, I definitely think it's worth strongly considering merging this in. I think it might be a little unrealistic to cut the first alpha after the merge though. Being realistic, any 20K+ LOC change is going to introduce its own bugs, and we should be hones

TLP tools for stress testing and building test clusters in AWS

I don't want to derail the discussion about Stabilizing Internode Messaging, so I'm starting this as a separate thread. There was a comment that Josh made [1] about doing performance testing with real clusters as well as a lot of microbenchmarks, and I'm 100% in support of this. We've been workin

Re: TLP tools for stress testing and building test clusters in AWS

hchenko > > wrote: > > > > Hey Jon, > > > > This sounds exciting and pretty useful, thanks. > > > > Looking forward to using tlp-stress for validating 15066 performance. > > > > We should touch base some time next week to pick a comprehensive

Re: TLP tools for stress testing and building test clusters in AWS

t; > > > I am from Australia so 5pm London time is ours 2am next day so your > > > Wednesday morning is my Thursday night. Wednesday early morning so > > > your Tuesday morning and London's afternoon would be the best. > > > > > > Recording the thing

Re: TLP tools for stress testing and building test clusters in AWS

Yes, sorry about that. Wednesday morning 9am PT On Tue, Apr 16, 2019 at 3:26 AM Benedict Elliott Smith wrote: > Just to confirm, this is on Wednesday? > > > On 15 Apr 2019, at 22:38, Jon Haddad wrote: > > > > Hey all, > > > > I've set up a Zoom call for

Re: TLP tools for stress testing and building test clusters in AWS

Miklosovic < > >>> stefan.mikloso...@instaclustr.com> wrote: > >>> > >>>> Hi Jon, > >>>> > >>>> I would like be on that call too but I am off on Thursday. > >>>> > >>>> I am from Australia so 5pm London time is our

Re: TLP tools for stress testing and building test clusters in AWS

always do the afternoon. > > >> > > > >> > Cheers, > > >> > Anthony > > >> > > > >> > > > >> > On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic < > > >> > stefan.mikloso...@instaclustr.com&g

Re: Jira Suggestion

Great idea. +1 On Tue, May 14, 2019, 12:10 PM Benedict Elliott Smith wrote: > It will be possible to insert n/a. It will simply be a text field - Jira > doesn’t know anything about the concept of a SHA, and I don’t intend to > introduce validation logic. It’s just a logical and consistent plac

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

Sept is a pretty long ways off. I think the ideal case is we can announce 4.0 release at the summit. I'm not putting this as a "do or die" date, and I don't think we need to announce it or make promises. Sticking with "when it's ready" is the right approach, but we need a target, and this is imo

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

testing, I dont think it will take as long > as 3.0 but want to know what is your thinking with this. > > Thanks, > Sankalp > > On Tue, May 28, 2019 at 9:40 AM Jon Haddad wrote: > > > Sept is a pretty long ways off. I think the ideal case is we can > announce > >

Re: [DISCUSS] Moving chats to ASF's Slack instance

+1 On Tue, May 28, 2019, 2:54 PM Joshua McKenzie wrote: > +1 to switching over. One less comms client + history + searchability is > enough to get my vote easy. > > On Tue, May 28, 2019 at 5:52 PM Jonathan Ellis wrote: > > > I agree. This lowers the barrier to entry for new participants. Slac

[VOTE] remove the old wiki

I assume everyone here knows the old wiki hasn't been maintained, and is years out of date. I propose we sunset it completely and delete it forever from the world. I'm happy to file the INFRA ticket to delete it, I'd just like to give everyone the opportunity to speak up in case there's something

Re: [VOTE] remove the old wiki

erms of establishing a framework > in which to think about something. Maybe. > > On Tue, Jun 4, 2019 at 2:47 PM Jon Haddad wrote: > > > I assume everyone here knows the old wiki hasn't been maintained, and is > > years out of date. I propose we sunset it completely and

Re: Stability of MaterializedView in 3.11.x | 4.0

I've helped a lot of teams (a dozen to two dozen maybe) migrate away from MVs due to inconsistencies, issues with streaming (have you added or removed nodes yet?), and massive performance issues to the point of cluster failure under (what I consider) trivial load. I haven't gone too deep into anal

4.0 alpha before apachecon?

Hey folks, I think it's time we cut a 4.0 alpha release. Before I put up a vote thread, is there a reason not to have a 4.0 alpha before ApacheCon / Cassandra Summit? There's a handful of small issues that I should be done for 4.0 (client list in virtual tables, dynamic snitch improvements, fixi

Re: 4.0 alpha before apachecon?

rowse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA > >. > Is there another artifact reflecting what testing people have in flight to > better reflect what risk of needing to re-test we have from these (and > other) post-freeze changes? > > > &g

Re: Stability of MaterializedView in 3.11.x | 4.0

discusses the risk appetite vs. mitigation aspect of > it. There's a reason banks do end-of-day close-out validation analysis and > have redundant systems for things like this. > > On Wed, Aug 28, 2019 at 11:49 AM Jon Haddad wrote: > > > I've helped a lot of teams (

Re: 4.0 alpha before apachecon?

pache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > On Aug 28, 2019, at 10:27 AM, Jon Haddad wrote: > > > > Regarding the dynamic snitch improvements, it's gone through several > rounds > > of review already and there's b

Re: 4.0 alpha before apachecon?

Agreed. There's no point in a branch if we aren't committing new features to trunk, and I don't think we should yet. On Thu, Aug 29, 2019 at 3:50 PM Dinesh Joshi wrote: > We should not branch trunk at least until the RC is out. > > Dinesh > > > On Aug 29, 2019, at 3:32 PM, Sankalp Kohli > wrote

Re: Stability of MaterializedView in 3.11.x | 4.0

node, we don’t > have cluster setup (3 nodes+ i.e). > > Does MVs perform well on single node machine ? > > Note: I know about HA, so lets keep it side for now and it's only possible > when we have cluster setup. > > On 29/08/19, 06:21, "Dor Laor" wrote: >

  1   2   3   4   >