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

[C. Scott Andreas]

These are the salient points here for me, yes:> My understanding from the proposal is that Sidecar would be able to migrate from a Cassandra instance that is already dead and cannot recover.> That’s one thing I like about having it an external process — not that it’s bullet proof but it’s one less thing to worry about.The manual/rsync version of the state machine Hari describes in the CEP is one of the best escape hatches for migrating an instance that’s overstressed, limping on ailing hardware, or that has exhausted disk. If the system is functional but the C* process is in bad shape, it’s great to have a paved-path flow for migrating the instance and data to more capable hardware.I also agree in principle that “streaming should be just as fast via the C* process itself.” This hits a couple snags today:- This option isn’t available when the C* instance is struggling.- In the scenario of replacing an entire cluster’s hardware with new machines, applying this process to an entire cluster via host replacements of all instances (which also requires repairs) or by doubling then halving capacity is incredibly cumbersome and operationally-impacting to the database’s users - especially if the DB is already having a hard time.- The host replacement process also puts a lot of stress on gossip and is a great way to encounter all sorts of painful races if you perform it hundreds or thousands of times (but shouldn’t be a problem in TCM-world).So I think I agree with both points:- Cassandra should be able to do this itself.- It is also valuable to have a paved path implementation of a safe migration/forklift state machine when you’re in a bind, or need to do this hundreds or thousands of times.On zero copy: what really makes ZCS fast compared to legacy streaming is that the JVM is able to ship entire files around, rather than deserializing SSTables and reserializing them to stream each individual row. That’s the slow and expensive part. It’s true that TLS means you incur an extra memcpy as that stream is encrypted before it’s chunked into packets — but the cost of that memcpy for encryption pales in comparison to how slow deserializing/reserializing SSTables is/was.ZCS with TLS can push 20Gbps+ today on decent but not extravagant Xeon hardware. In-kernel TLS would also still encounter a memcpy in the encryption path; the kernel.org doc alludes to this via “the kernel will need to allocate a buffer for the encrypted data.” But it would allow using sendfile and cut a copy in userspace. If someone is interested in testing it out I’d love to learn what they find. It’s always a great surprise to learn there’s a more perf left on the table. This comparison looks promising: https://tinselcity.github.io/SSL_Sendfile/– Scott—MobileOn Apr 19, 2024, at 11:31 AM, Jordan West  wrote:If we are considering the main process then we have to do some additional work to ensure that it doesn’t put pressure on the JVM and introduce latency. That’s one thing I like about having it an external process — not that it’s bullet proof but it’s one less thing to worry about. Jordan On Thu, Apr 18, 2024 at 15:39 Francisco Guerrero  wrote:My understanding from the proposal is that Sidecar would be able to migrate
from a Cassandra instance that is already dead and cannot recover. This is a
scenario that is possible where Sidecar should still be able to migrate to a new
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 if the live migration process can be handled within the C* process itself
or if we allow this functionality to be handled by Sidecar.

I am looking forward to this feature though, as it will be of great value for many
users across the ecosystem.

On 2024/04/18 22:25:23 Jon Haddad wrote:
> 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, 2024 at 12:50 PM Jon Haddad  wrote:
> 
> > 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 the transfer in sidecar.  What's the
> > advantage of duplicating the work that's already been done?
> >
> > I can see using the sidecar for coordination to start and stop instances
> > or do things that require something out of process.
> >
> > Jon
> >
> >
> > On Thu, Apr 18, 2024 at 12:44 PM Ariel Weisberg  wrote:
> >
> >> Hi,
> >>
> >> If there is a faster/better way to replace a node 

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

[C. Scott Andreas]

Oh, one note on this item:>  The operator can ensure that files in the destination matches with the source. In the first iteration of this feature, an API is introduced to calculate digest for the list of file names and their lengths to identify any mismatches. It does not validate the file contents at the binary level, but, such feature can be added at a later point of time.When enabled for LCS, single sstable uplevel will mutate only the level of an SSTable in its stats metadata component, which wouldn't alter the filename and may not alter the length of the stats metadata component. A change to the level of an SSTable on the source via single sstable uplevel may not be caught by a digest based only on filename and length.Including the file’s modification timestamp would address this without requiring a deep hash of the data. This would be good to include to ensure SSTables aren’t downleveled unexpectedly during migration.- ScottOn Apr 8, 2024, at 2:15 PM, C. Scott Andreas  wrote:Hi Jon,Thanks for taking the time to read and reply to this proposal. Would encourage you to approach it from an attitude of seeking understanding on the part of the first-time CEP author, as this reply casts it off pretty quickly as NIH.The proposal isn't mine, but I'll offer a few notes on where I see this as valuable:– It's valuable for Cassandra to have an ecosystem-native mechanism of migrating data between physical/virtual instances outside the standard streaming path. As Hari mentions, the current ecosystem-native approach of executing repairs, decommissions, and bootstraps is time-consuming and cumbersome.– An ecosystem-native solution is safer than a bunch of bash and rsync. Defining a safe protocol to migrate data between instances via rsync without downtime is surprisingly difficult - and even moreso to do safely and repeatedly at scale. Enabling this process to be orchestrated by a control plane mechanizing offical endpoints of the database and sidecar – rather than trying to move data around behind its back – is much safer than hoping one's cobbled together the right set of scripts to move data in a way that won't violate strong / transactional consistency guarantees. This complexity is kind of exemplified by the "Migrating One Instance" section of the doc and state machine diagram, which illustrates an approach to solving that problem.– An ecosystem-native approach poses fewer security concerns than rsync. mTLS-authenticated endpoints in the sidecar for data movement eliminate the requirement for orchestration to occur via (typically) high-privilege SSH, which often allows for code execution of some form or complex efforts to scope 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 would allow for metrics reporting, stats collection, and alerting via mature and modern mechanisms rather than monitoring the output of a shell script.I'll yield to Hari to share more, though today is a public holiday in India.I do see this CEP as solving an important problem.Thanks,– ScottOn Apr 8, 2024, at 10:23 AM, Jon Haddad  wrote: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 instances like EC2. Enabling data transfer through a sidecar facilitates smooth instance migration.This feels more like NIH than solving a real problem, as what you've listed is a hypothetical, and one that's easily addressed.JonOn Fri, Apr 5, 2024 at 3:47 AM Venkata Hari Krishna Nukala <n.v.harikrishna.apa...@gmail.com> wrote:Hi all,I have filed CEP-40 [1] for live migrating Cassandra instances using the Cassandra Sidecar.When someone needs to move all or a portion of the Cassandra nodes belonging to a cluster to different hosts, the traditional approach of Cassandra node replacement can be time-consuming due to repairs and the bootstrapping of new nodes. Depending on the volume of the storage service load, replacements (repair + bootstrap) may take anywhere from a few hours to days.Proposing a Sidecar based solution to address these challenges. This solution proposes transferring data from the old host (source) to the new host (destination) and then bringing up the Cassandra process at the destination, to enable fast instance migration. This approach would help to minimise node downtime, as it is based on a Sidecar solution for data transfer and avoids repairs and bootstrap.Looking forward to the discussions.[1] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Transfer+Using+Cassandra+Sidecar+for+Live+Migrating+InstancesThanks!Hari

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

[C. Scott Andreas]

Hi Jon, Thanks for taking the time to read and reply to this proposal. Would encourage you to approach it from 
an attitude of seeking understanding on the part of the first-time CEP author, as this reply casts it off 
pretty quickly as NIH. The proposal isn't mine, but I'll offer a few notes on where I see this as valuable: – 
It's valuable for Cassandra to have an ecosystem-native mechanism of migrating data between physical/virtual 
instances outside the standard streaming path. As Hari mentions, the current ecosystem-native approach of 
executing repairs, decommissions, and bootstraps is time-consuming and cumbersome. – An ecosystem-native 
solution is safer than a bunch of bash and rsync. Defining a safe protocol to migrate data between instances 
via rsync without downtime is surprisingly difficult - and even moreso to do safely and repeatedly at scale. 
Enabling this process to be orchestrated by a control plane mechanizing offical endpoints of the database and 
sidecar – rather than trying to move data around behind its back – is much safer than hoping one's cobbled 
together the right set of scripts to move data in a way that won't violate strong / transactional consistency 
guarantees. This complexity is kind of exemplified by the "Migrating One Instance" section of the doc 
and state machine diagram, which illustrates an approach to solving that problem. – An ecosystem-native 
approach poses fewer security concerns than rsync. mTLS-authenticated endpoints in the sidecar for data 
movement eliminate the requirement for orchestration to occur via (typically) high-privilege SSH, which often 
allows for code execution of some form or complex efforts to scope 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 would allow for metrics reporting, stats collection, and alerting via mature and 
modern mechanisms rather than monitoring the output of a shell script. I'll yield to Hari to share more, though 
today is a public holiday in India. I do see this CEP as solving an important problem. Thanks, – Scott On Apr 
8, 2024, at 10:23 AM, Jon Haddad  wrote: 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 instances like EC2. Enabling data transfer through a sidecar 
facilitates smooth instance migration . This feels more like NIH than solving a real problem, as what you've 
listed is a hypothetical, and one that's easily addressed. Jon On Fri, Apr 5, 2024 at 3:47 AM Venkata Hari 
Krishna Nukala < n.v.harikrishna.apa...@gmail.com > wrote: Hi all, I have filed CEP-40 [1] for live 
migrating Cassandra instances using the Cassandra Sidecar. When someone needs to move all or a portion of the 
Cassandra nodes belonging to a cluster to different hosts, the traditional approach of Cassandra node 
replacement can be time-consuming due to repairs and the bootstrapping of new nodes. Depending on the volume of 
the storage service load, replacements (repair + bootstrap) may take anywhere from a few hours to days. 
Proposing a Sidecar based solution to address these challenges. This solution proposes transferring data from 
the old host (source) to the new host (destination) and then bringing up the Cassandra process at the 
destination, to enable fast instance migration. This approach would help to minimise node downtime, as it is 
based on a Sidecar solution for data transfer and avoids repairs and bootstrap. Looking forward to the 
discussions. [1] 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Transfer+Using+Cassandra+Sidecar+for+Live+Migrating+Instances
 Thanks! Hari

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[C. Scott Andreas]

Bowen and Jeremiah, thanks for remembering this. I'd remembered the DKIM/SPF issue, but not its relationship to the message footer - 
appreciate your work fixing that, Bowen. I'm part of a few Google Groups that relay messages with an appended footer that don't seem to 
encounter invalidation, but am not curious enough to learn how they make that work right now. :) I withdraw the proposal.  – Scott On 
Jan 22, 2024, at 10:56 AM, Brandon Williams  wrote: That's right, I'd forgotten about this. I change my +1 to 
-1, there's not enough value in this to break signatures. Kind Regards, Brandon On Mon, Jan 22, 2024 at 12:42 PM Jeremiah Jordan < 
jerem...@datastax.com > wrote: Here was the thread where it was removed: lists.apache.org On Jan 22, 2024, at 12:37 PM, J. D. Jordan 
< jeremiah.jor...@gmail.com > wrote: I think we used to have this and removed them because it was breaking the encryption 
signature on messages or something which meant they were very likely to be treated as spam? Not saying we can’t put it back on, but it 
was removed for good reasons from what I recall. On Jan 22, 2024, at 12:19 PM, Brandon Williams < dri...@gmail.com > wrote: +1 
Kind Regards, Brandon On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas < sc...@paradoxica.net > wrote: Hi all, I'd like to 
propose appending the following two footers to messages sent to the user@ and dev@ lists. The proposed postscript including line breaks 
is between the "X" blocks below. User List Footer: X --- Unsubscribe: Send a blank email to 
user-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow other mailing lists or join us in 
Slack: https://cassandra.apache.org/_/community.html X Dev List Footer: X --- Unsubscribe: Send a blank email to 
dev-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow other mailing lists or join us in 
Slack: https://cassandra.apache.org/_/community.html X Offering this proposal for three reasons: – Many users are sending 
"Unsubscribe" messages to the full mailing list which prompts others to wish to unsubscribe – a negative cascade that affects 
the size of our user community. – Many users don't know where to go to figure out how to unsubscribe, especially if they'd joined many 
years ago. – Nearly all mailing lists provide a one-click mechanism for unsubscribing or built-in mail client integration to do so via 
message headers. Including compact instructions on how to leave is valuable to subscribers. #asfinfra indicates that such footers can 
be appended given project consensus and an INFRA- ticket: https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079 If we reach 
consensus on adding a message footer, I'll file an INFRA ticket with a link to this thread. Thanks, – Scott 

[DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[C. Scott Andreas]

Hi all, I'd like to propose appending the following two footers to messages sent to the user@ and 
dev@ lists. The proposed postscript including line breaks is between the "X" blocks 
below. User List Footer: X --- Unsubscribe: Send a blank email to 
user-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow 
other mailing lists or join us in Slack: https://cassandra.apache.org/_/community.html X Dev 
List Footer: X --- Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org . Do 
not reply to this message. Cassandra Community: Follow other mailing lists or join us in Slack: 
https://cassandra.apache.org/_/community.html X Offering this proposal for three reasons: – 
Many users are sending "Unsubscribe" messages to the full mailing list which prompts 
others to wish to unsubscribe – a negative cascade that affects the size of our user community. – 
Many users don't know where to go to figure out how to unsubscribe, especially if they'd joined 
many years ago. – Nearly all mailing lists provide a one-click mechanism for unsubscribing or 
built-in mail client integration to do so via message headers. Including compact instructions on 
how to leave is valuable to subscribers. #asfinfra indicates that such footers can be appended 
given project consensus and an INFRA- ticket: 
https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079 If we reach consensus on adding a 
message footer, I'll file an INFRA ticket with a link to this thread. Thanks, – Scott

Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

[C. Scott Andreas]

Jaydeep, thanks for reaching out and for sharing this proposal. I like the direction. Please also take a look at 
https://issues.apache.org/jira/browse/CASSANDRA-16663 , which adds coordinator-level rate limiting on request rate. This ticket 
introduced a lockless rate limiter patterned on an approach in Guava, adapted for Cassandra. This will likely be the rate 
limiter you'd like to actuate via changes in the database metrics your proposal describes. One challenge we've had with the 
rate limiter introduced in C-16663 is that it's difficult to determine what value to set it to. Another aspect of C-16663 that 
I find valuable is that the rate limiter can dispatch notifications to clients that rate limiting is taking effect, implemented 
via client warnings. Users should/need to be able to know that their request rate is being artificially reduced due to 
server-side throttling. Appreciate your thinking along the lines of different metrics that operators may want to trigger on, as 
this will vary per-workload. There are probably extremely read-heavy workloads that push CPU hard but which don't incur 
compaction backlog/other balance-of-humors issues and are comfortable running at high CPU, as an example. I like the idea of 
adaptive request volumes in clients as well and don't see this and Jon's proposal as mutually exclusive. There are many 
different Cassandra clients, including some outside the project written in Go and Rust that are beyond the scope of our direct 
control. Any server should have mechanisms to defend itself against any client; official or non–. Jon's also right that an 
implementation in the Spark Cassandra Connector may help jobs make progress at the maximum safe pace. Thanks for sharing this 
thoughtful document. – Scott On Jan 16, 2024, at 10:46 AM, Jon Haddad  wrote: 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 is throwing errors (or exceeds the defined latency SLO), requests to that node can be rate limited. It 
does a better job of preventing issues than server side rate limiting as we don't get the DDOS effect in addition to whatever 
issue the node is dealing with at the time. Netflix has a good post on it here [1], and I've incorporated the latency version 
into my fork of tlp-stress [2] for benchmarking. Adding this to the driver means the DS Spark Connector can also take advantage 
of it, which is nice because tuning it to get the optimal throughput is a bit of a headache. Regarding the server side, I think 
the proposal to use various system metrics is overly complicated. The only metrics that matter are latency and error rate. As 
long as you're within acceptable thresholds, you don't need to rate limit. Jon [1] 
https://netflixtechblog.medium.com/performance-under-load-3e6fa9a60581 [2] 
https://rustyrazorblade.com/post/2023/2023-10-31-tlp-stress-adaptive-scheduler/ On Tue, Jan 16, 2024 at 10:02 AM Štefan 
Miklošovič < stefan.mikloso...@gmail.com > wrote: Hi Jaydeep, That seems quite interesting. Couple points though: 1) It 
would be nice if there is a way to "subscribe" to decisions your detection framework comes up with. Integration with 
e.g. diagnostics subsystem would be beneficial. This should be pluggable - just coding up an interface to dump / react on the 
decisions how I want. This might also act as a notifier to other systems, e-mail, slack channels ... 2) Have you tried to 
incorporate this with the Guardrails framework? I think that if something is detected to be throttled or rejected (e.g writing 
to a table), there might be a guardrail which would be triggered dynamically in runtime. Guardrails are useful as such but here 
we might reuse them so we do not need to code it twice. 3) I am curious how complex this detection framework would be, it can 
be complicated pretty fast I guess. What would be desirable is to act on it in such a way that you will not put that node under 
even more pressure. In other words, your detection system should work in such a way that there will not be any "doom 
loop" whereby mere throttling of various parts of Cassandra you make it even worse for other nodes in the cluster. For 
example, if a particular node starts to be overwhelmed and you detect this and requests start to be rejected, is it not 
possible that Java driver would start to see this node as "erroneous" with delayed response time etc and it would 
start to prefer other nodes in the cluster when deciding what node to contact for query coordination? So you would put more 
load on other nodes, making them more susceptible to be throttled as well ... Regards Stefan Miklosovic On Tue, Jan 16, 2024 at 
6:41 PM Jaydeep Chovatia < chovatia.jayd...@gmail.com > wrote: Hi, Happy New Year! I would like to discuss the following 

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

[C. Scott Andreas]

Thanks for this proposal and apologies for my delayed engagement during the Cassandra Summit last week. Benjamin, I appreciate your work on this and your engagement on this thread – I know it’s a lot of discussion to field.On ALLOW FILTERING:I share Chris Lohfink’s experience in operating clusters that have made heavy use of ALLOW FILTERING. It is a valuable guardrail for the database to require users specifically annotate queries that may cost 1000x+ that of a simple lookup for a primary key. For my own purposes, I’d actually like to go a step further and disable queries that require ALLOW FILTERING by default unless explicitly reviewed - but haven’t taken the step of adding such a guardrail yet.CBOs, CQL, and SQL:The CBO proposal cuts to the heart of one of the fundamental differences between SQL and CQL that I haven’t seen exercised yet.SQL allows users to define schemas that provide structure to data and to issue queries over them based on a relational algebra. SQL’s purpose is to decouple the on-disk representation of data from the query language used to access and aggregate it. This produces a very flexible query language that can be used to ask a database anything - but at a cost of execution that may be effectively infinite (think recursive subqueries).CQL is very different. While SQL is designed to decouple query language and on-disk representation, CQL is designed specifically to couple them. A CQL schema declares data placement, query routing, and disk serialization, and sorting to enable efficient retrieval. This is a very different design goal from a general-purpose query language. In time CQL may gain many SQL-like capabilities (and I hope it does!), but it will require careful work to do so without creating many footguns.Feature evolution:I agree that in the coming years, Cassandra is likely to gain semi-relational features via maturation of the byte-ordered partitioner (via range splitting, via TCM); the availability of SAI and its evolution (e.g., via new functionality enabled by Lucene libraries); potentially joins via BOP; and others. This is a really exciting future, and one that probably requires a planner and optimizer.My general inclination is that a planner + optimizer seem valuable for Cassandra, but that the proposal feels a year or two early. The database doesn’t yet have a plan of record to add support for some of the semirelational constructs we’ve talked about, and I’m not aware of active CEPs that propose designs for features like these yet.Like Jeff, I’d find this much easier to discuss in the context of a database gaining support for these features with specific designs available to discuss. The ALLOW FILTERING and constant folding examples are a little slim. Index selection is probably the best one I can think of right now - e.g., if we wanted to add the ability to issue partition-restricted queries over a base table with multiple indexes defined without users specifically declaring an index. I haven’t seen an at-scale use case that would be better served by planner-driven index selection vs. user-driven, but they might be out there.It’s not my role to suggest changes in prioritization for work that isn’t mine. But I feel that the project could design better interfaces and a better planner/optimizer if that work were oriented toward improving particular features that are in wide use.To summarize my thoughts:– I agree that it is valuable for Apache Cassandra to gain a planner/optimizer.– I disagree with removing or deprecating ALLOW FILTERING and see this as a necessary guardrail.– I think the proposal surfaces the differences between the design goals of CQL and SQL, but I don’t feel that it quite addresses it.– I think we could collectively build a stronger planner/optimizer once some of the features it’s meant to optimize are in place.– I’m not quite sold on the need for the implementation to be bespoke based on discussion so far (vs. Calcite/Catalyst etc), but haven’t done the legwork to investigate this myself.– I *love* the idea of capturing many of the execution and hotness statistics that are proposed in the CEP. It would be very valuable to surface query cost to users independent of a CBO. Stats like these would also be valuable toward retrofitting Cassandra for multitenancy by bounding or rate-limiting users on query cost. Tracking SSTable hotness would also be useful toward evaluating feasibility of tiered storage, too.Thanks for this proposal and discussion so far — appreciate and enjoying it.– Scott–––MobileOn Dec 20, 2023, at 7:52 AM, Benjamin Lerer  wrote:
If we are to address that within the CEP itself then we should discuss 
it here, as I would like to fully understand the approach as well as how
 it relates to consistency of execution and the idea of triggering 
re-optimisation.

Sure, that was my plan.
I’m not sold on the proposed set of characteristics, and 
think my coupling an execution plan to a given prepared statement for 
clients to supply is 

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

[C. Scott Andreas]

Thanks for this proposal and apologies for my delayed engagement during the Cassandra Summit last week. Benjamin, I appreciate your work on this and your engagement on this thread – I know it’s a lot of discussion to field. On ALLOW FILTERING: I share Chris Lohfink’s 
experience in operating clusters that have made heavy use of ALLOW FILTERING. It is a valuable guardrail for the database to require users specifically annotate queries that may cost 1000x+ that of a simple lookup for a primary key. For my own purposes, I’d actually like to 
go a step further and disable queries that require ALLOW FILTERING by default unless explicitly reviewed - but haven’t taken the step of adding such a guardrail yet. CBOs, CQL, and SQL: The CBO proposal cuts to the heart of one of the fundamental differences between SQL and 
CQL that I haven’t seen exercised yet. SQL allows users to define schemas that provide structure to data and to issue queries over them based on a relational algebra. SQL’s purpose is to decouple the on-disk representation of data from the query language used to access and 
aggregate it. This produces a very flexible query language that can be used to ask a database anything - but at a cost of execution that may be effectively infinite (think recursive subqueries). CQL is very different. While SQL is designed to decouple query language and 
on-disk representation, CQL is designed specifically to couple them. A CQL schema declares data placement, query routing, and disk serialization, and sorting to enable efficient retrieval. This is a very different design goal from a general-purpose query language. In time CQL 
may gain many SQL-like capabilities (and I hope it does!), but it will require careful work to do so without creating many footguns. Feature evolution: I agree that in the coming years, Cassandra is likely to gain semi-relational features via maturation of the byte-ordered 
partitioner (via range splitting, via TCM); the availability of SAI and its evolution (e.g., via new functionality enabled by Lucene libraries); potentially joins via BOP; and others. This is a really exciting future, and one that probably requires a planner and optimizer. My 
general inclination is that a planner + optimizer seem valuable for Cassandra, but that the proposal feels a year or two early. The database doesn’t yet have a plan of record to add support for some of the semirelational constructs we’ve talked about, and I’m not aware of 
active CEPs that propose designs for features like these yet. Like Jeff, I’d find this much easier to discuss in the context of a database gaining support for these features with specific designs available to discuss. The ALLOW FILTERING and constant folding examples are a 
little slim. Index selection is probably the best one I can think of right now - e.g., if we wanted to add the ability to issue partition-restricted queries over a base table with multiple indexes defined without users specifically declaring an index. I haven’t seen an 
at-scale use case that would be better served by planner-driven index selection vs. user-driven, but they might be out there. It’s not my role to suggest changes in prioritization for work that isn’t mine. But I feel that the project could design better interfaces and a 
better planner/optimizer if that work were oriented toward improving particular features that are in wide use. To summarize my thoughts: – I agree that it is valuable for Apache Cassandra to gain a planner/optimizer. – I disagree with removing or deprecating ALLOW FILTERING 
and see this as a necessary guardrail. – I think the proposal surfaces the differences between the design goals of CQL and SQL, but I don’t feel that it quite addresses it. – I think we could collectively build a stronger planner/optimizer once some of the features it’s meant 
to optimize are in place. – I’m not quite sold on the need for the implementation to be bespoke based on discussion so far (vs. Calcite/Catalyst etc), but haven’t done the legwork to investigate this myself. – I *love* the idea of capturing many of the execution and hotness 
statistics that are proposed in the CEP. It would be very valuable to surface query cost to users independent of a CBO. Stats like these would also be valuable toward retrofitting Cassandra for multitenancy by bounding or rate-limiting users on query cost. Tracking SSTable 
hotness would also be useful toward evaluating feasibility of tiered storage, too. Thanks for this proposal and discussion so far — appreciate and enjoying it. – Scott On Dec 20, 2023, at 7:52 AM, Benjamin Lerer  wrote: If we are to address that 
within the CEP itself then we should discuss it here, as I would like to fully understand the approach as well as how it relates to consistency of execution and the idea of triggering re-optimisation. Sure, that was my plan. I’m not sold on the proposed set of 
characteristics, and think my coupling an execution plan to a given prepared statement for 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[C. Scott Andreas]

Congratulations, Francisco!

- Scott

> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
> 
> The PMC members are pleased to announce that Francisco Guerrero Hernandez 
> has accepted
> the invitation to become committer today.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[C. Scott Andreas]

Agreed with Brandon, yes. I'm at a "-0 (nb)" on a beta release at this point. We're clearly finding (and 
resolving) lots of significant and in some case serious issues - ones that violate fundamental properties of the 
database. I'm very glad that we're finding and fixing these, but they feel like late and lucky catches rather than 
the result of a standardized and rigorous validation process. This sentiment isn't specific to a particular feature. 
As of this time, I'm also not aware of a user of the project operating a build from the 5.0 branch at substantial 
scale to suss out the operational side of what can be expected. If someone is running a build supporting 
non-perf-test traffic derived from the 5.0 branch and has an experience report to share it would be great to read. 
Compared to the rigor of our previous major release, this feels rushed and timeline-driven rather than anchored in 
values of quality and data integrity. – Scott On Nov 28, 2023, at 9:20 AM, Brandon Williams  
wrote: If we are going to commit to beta2 before the summit because "putting a beta w/ SAI in this state into 
users’ hands at summit would be very, very bad" I don't see why we need to have a subpar beta1 at all? Kind 
Regards, Brandon On Tue, Nov 28, 2023 at 11:16 AM Mick Semb Wever  wrote: On Tue, 28 Nov 2023 
at 18:06, Caleb Rackliffe  wrote: Just to update this thread, Mike has identified the 
root cause of 19011 and in the process uncovered 2 additional very closely related issues. (Fantastic job fuzzing 
there!) Fixes for all three issues are in hand, and he continues to test. After some conversation w/ Mick, Alex, and 
Mike, I feel like cutting a beta1 now is fine as long as we commit to a beta2 before summit that includes 19011. 
Putting a beta w/ SAI in this state into users’ hands at summit would be very, very bad. In case this sounds weird, 
to clarify: this is a mitigation action – there's a risk with every release that it does not make it through. beta1 
might not be great for SAI, but getting it out is better than having only alpha1 available come Summit. It might feel 
odd to have a beta2 right after a beta1, but I don't mind (and would rather) take the time and investment. beta1 
would be announced with an appropriate disclaimer.

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

[C. Scott Andreas]

I’d happily be the first to vote -1(nb) on a release containing a known and reproducible bug that can result in data loss or an incorrect response to a query. And I certainly wouldn’t run it.Since we have a programmatic repro within just a few seconds, this should not take long to root-cause.On Friday, Alex worked to get this reproducing on a Cassandra branch rather than via unstaged changes. We should have a published / shareable example with details near the beginning of the week.– ScottOn Nov 4, 2023, at 10:17 AM, Josh McKenzie  wrote:I think before we cut a beta we need to have diagnosed and fixed 18993 (assuming it is a bug).Before a beta? I could see that for rc or GA definitely, but having a known (especially non-regressive) data loss bug in a beta seems like it's compatible with the guarantees we're providing for it: https://cwiki.apache.org/confluence/display/CASSANDRA/Release+LifecycleThis release is recommended for test/QA clusters where short(order of minutes) downtime during upgrades is not an issueOn Sat, Nov 4, 2023, at 12:56 PM, Ekaterina Dimitrova wrote:Totally agree with the others. Such an issue on its own should be a priority in any release. Looking forward to the reproduction test mentioned on the ticket.Thanks to Alex for his work on harry!On Sat, 4 Nov 2023 at 12:47, Benedict  wrote:Alex can confirm but I think it actually turns out to be a new bug in 5.0, but either way we should not cut a release with such a serious potential known issue.  > On 4 Nov 2023, at 16:18, J. D. Jordan  wrote: >  > Sounds like 18993 is not a regression in 5.0? But present in 4.1 as well?  So I would say we should fix it with the highest priority and get a new 4.1.x released. Blocking 5.0 beta voting is a secondary issue to me if we have a “data not being returned” issue in an existing release? >  >> On Nov 4, 2023, at 11:09 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: [DISCUSS] CommitLog default disk access mode

[C. Scott Andreas]

Let’s please not change the default at the same time the feature is introduced.Making the capability available will allow users to evaluate and quantify the benefit of the work, as well as to call out any unintended consequences. As users and the project gain confidence in the results, we can evaluate changing the default.– ScottOn Oct 17, 2023, at 4:25 AM, guo Maxwell  wrote:-1I still think we should keep it as it is until the  direct io  for commitlog (read and write) is ready and relatively stable. And then we may change the default value to direct io from mmap in a future version, such as 5.2, or 6.0.Pawar, Amit  于2023年10月17日周二 19:03写道：







[AMD Official Use Only - General]




Thank you all for your input. Received total 6 replies and below is the summary.
 
1. Mmap   : 2/6
2. Direct-I/O : 4/6
 
Default should be changed to Direct-IO then ? please confirm.
 
Thanks,
Amit
 




Strongly agree with this point of view that direct IO  can bring great benefits. 


 

I have reviewed part of the code, and my preliminary judgment is that it is not very common and limited in some situations, for example, it  works for commitlog's write path only for this patch.So I suggest that
 the default value should not be modified until the entire function is comprehensive and stable, and then modified in a future version.


 



Sam 
于2023年10月17日周二 05:39写道：




Glad you brought up compaction here - I think there would be a significant benefit to moving compaction to direct i/o.


 


+1. Would love to see this get traction.

 


On Mon, 16 Oct 2023 at 19:38, Jon Haddad  wrote:


Glad you brought up compaction here - I think there would be a significant benefit to moving compaction to direct i/o.


On 2023/10/16 16:14:28 Benedict wrote:
> I have some plans to (eventually) use the commit log as memtable payload storage (ie memtables would reference the commit log entries directly, storing only indexing info), and to back first level of sstables by reference to commit log entries. This will
 permit us to deliver not only much bigger memtables (cutting compaction throughput requirements by the ratio of size increase - so pretty dramatically), and faster flushing (so better behaviour ling write bursts), but also a fairly cheap and simple way to
 support MVCC - which will be helpful for transaction throughput.
> 
> There is also a new commit log (“journal”) coming with Accord, that the rest of C* may or may not transition to.
> 
> I only say this because this makes the utility of direct IO for commit log suspect, as we will be reading from the files as a matter of course should this go ahead; and we may end up relying on a different commit log implementation before long anyway.
> 
> This is obviously a big suggestion and is not guaranteed to transpire, and probably won’t within the next year or so, but it should perhaps form some minimal part of any calculus. If the patch is otherwise simple and beneficial I don’t have anything against
 it, and the use 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  wrote:
> > 
> > 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[1] to improve the CommitLog IO speed. Enabling this by default could be useful feature to address IO bottleneck seen during peak load.
> >> 
> >> Need your input regarding changing this default. Please suggest.
> >> 
> >> 
https://issues.apache.org/jira/browse/CASSANDRA-18464
> >> 
> >> thanks,
> >> Amit Pawar
> >> 
> >> [1] - 
https://github.com/apache/cassandra/pull/2777
> >> 
> 









 

--


you are the apple of my eye !






-- you are the apple of my eye !

Re: [VOTE] Accept java-driver

[C. Scott Andreas]

+1 (nb)Accepting this donation would mark a huge milestone for the project.On Oct 3, 2023, at 4:25 AM, Josh McKenzie  
wrote:I see now this will likely be instead apache/cassandra-java-driverI was wondering about that. apache/java-driver seemed pretty broad. 
:)From the linked page:Check that all active committers have a signed CLA on record. TODO – attach listI've been part of these discussions and 
work so am familiar with the status of it (as well as guidance and clearance from the foundation re: folks we couldn't reach) - but might be 
worthwhile to link to the sheet or perhaps instead provide a summary of the 49 java contributors, their CLA signing status, attempts to reach 
out, etc for other PMC members that weren't actively involved back when we were working through it.As for my vote: +1Thanks everyone for the hard 
work getting to this point. This really is a significant contribution to the project.On Tue, Oct 3, 2023, at 6:48 AM, Brandon Williams 
wrote:+1Kind Regards,BrandonOn 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] Update default disk_access_mode to mmap_index_only on 5.0

[C. Scott Andreas]

Supportive of switching the default to mmap_index_only as well.

I don’t have numbers handy to share, but my experience has been significantly 
lower read latency and I wouldn’t run with auto. I’ve also not observed 
substantial heap pressure after switching - it was strictly an improvement.

- Scott

—
Mobile

> On Sep 6, 2023, at 8: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

[C. Scott Andreas]

A snapshot artifact seems more appropriate for early testing to me, rather than a voted / released build issued by the project given how much has yet to land.- ScottOn Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova  wrote:+1On Fri, 25 Aug 2023 at 11:14, 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.0features: Vector Search (CEP-30), Transactional Cluster Metadata(CEP-21) and Accord Transactions (CEP-15).  These features will landin 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: 62cb03cc7311384db6619a102d1da6a024653fa6Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentativeMaven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1314/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: [DISCUSSION] Dependency management in our first alpha release

[C. Scott Andreas]

Given how early we are in the cycle with even the branch only recently cut (and how 
much is not yet present in the alpha), housecleaning seems like a positive impulse.On 
Aug 23, 2023, at 7:28 AM, Ekaterina Dimitrova  wrote:Hi 
everyone,I wanted to clarify something. I understood dependency updates/cleaning can 
also be done in an alpha release if they lead to minimal user-facing changes, if any 
at all. I agree with that in our first 5.0 alpha release because we are not yet 
feature-complete. It is a good time for people to do a bit of housekeeping and 
tighten some loose ends. Do you think this is a valid statement? Thoughts?I wanted to 
clear this topic as we have a few in-flight tickets/discussions:- CASSANDRA-14667 - 
upgrade dropwizard metrics, for which to be accommodated, Bret is creating a new 
3.11.4 drivers version. So we should update the driver. I am unsure how much effort 
and change it will be on our side to update the drivers though. Maxim, did you try 
it? Any thoughts?- CASSANDRA-18789 - commons-lang3, a pretty non-controversial bump 
with two versions. The one we are on is tested to Java 11, and the newest one tests 
up to JDK17 and beyond. This is enough reason for me honestly to update it.- In [1], 
Maxim mentioned that we can clean org.caffinitas.ohc:ohc-core-j8.- In [2], Stefan and 
Mick made a point that we could even remove in 5.0 
metrics-reporter-config(CASSANDRA-18743) and commons-codec(CASSANDRA-18772) I think 
this should be a good idea - let's make some noise in the user group to ensure people 
are aware and no one raises any significant concerns and then clean those two. I also 
want to hear if Abe still has concerns about not following deprecation process here. 
And if we decide, we can find a few more loose ends to deal with. I am sure.Looking 
forward to your feedback and thoughts.Best regards,Ekaterina[1] 
https://lists.apache.org/thread/9m1vz5qyows97wlppkwk1fd8386rj9q1[2] 
https://lists.apache.org/thread/9m1vz5qyows97wlppkwk1fd8386rj9q1

Re: [VOTE] Release dtest-api 0.0.16

[C. Scott Andreas]

+1nbOn Aug 19, 2023, at 9:50 AM, Blake Eggleston  wrote:+1On Aug 17, 2023, at 12:37 AM, Alex Petrov  wrote:+1On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote:+1Kind Regards,BrandonOn 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: [Discuss] Repair inside C*

[C. Scott Andreas]

I agree that it would be ideal for Cassandra to have a repair scheduler in-DB.

That said I would happily support an effort to bring repair scheduling to the 
sidecar immediately. This has nothing blocking it, and would potentially enable 
the sidecar to provide an official repair scheduling solution that is 
compatible with current or even previous versions of the database.

Once TCM has landed, we’ll have much stronger primitives for repair 
orchestration in the database itself. But I don’t think that should block 
progress on a repair scheduling 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 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 integrity 
> needs to be opt-in has never made sense to me from the perspective of either 
> the product or the end user.
> 
> I've worked with way too many teams that have either configured this 
> incorrectly or not at all.  
> 
> Ideally Cassandra would ship with repair built in and on by default.  Power 
> users can disable if they want to continue to maintain their own repair 
> tooling for some reason.
> 
> Jon
> 
>> On 2023/07/24 20:44:14 German Eichberger via dev wrote:
>> All,
>> We had a brief discussion in [2] about the Uber article [1] where they talk 
>> about having integrated repair into Cassandra and how great that is. I 
>> expressed my disappointment that they didn't work with the community on that 
>> (Uber, if you are listening time to make amends ) and it turns out Joey 
>> already had the idea and wrote the code [3] - so I wanted to start a 
>> discussion to gauge interest and maybe how to revive that effort.
>> Thanks,
>> German
>> [1] 
>> https://www.uber.com/blog/how-uber-optimized-cassandra-operations-at-scale/
>> [2] https://the-asf.slack.com/archives/CK23JSY2K/p1690225062383619
>> [3] https://issues.apache.org/jira/browse/CASSANDRA-14346

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

[C. Scott Andreas]

I think these concerns are well-intended, but they feel rooted in uncertainty rather than in factual examples of areas where risk is present. I 
would appreciate elaboration on the specific areas of risk that folks imagine.I would encourage those who express skepticism to try the patch, 
and I endorse Ayushi's proposal to enable it by default.– ScottOn Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" 
 wrote:We can make it opt-in, wait one major to see what bugs pop up and we might do that opt-out 
eventually. We do not need to hurry up with this. I understand everybody's expectations and excitement but it really boils down to one line 
change in yaml. People who are so much after the performance will be definitely aware of this knob to turn on to squeeze even more perf ...I 
look around dtests Jeremiah mentioned but I would just moved on and make it opt-in if we are not 100% persuaded about it 
_yet_.From: Mick Semb Wever Sent: Wednesday, July 26, 2023 20:48To: 
dev@cassandra.apache.orgSubject: Re: [DISCUSS] Using ACCP or tc-native by defaultNetApp 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.What comes to mind is how we brought down people 
clusters and made sstables unreadable with the introduction of the chunk_length configuration in 1.0.  It wasn't about how tested the 
compression libraries were, but about the new configuration itself.  Introducing silent defaults has more surface area for bugs than 
introducing explicit defaults that only apply to new clusters and are so opt-in for existing clusters.On Wed, 26 Jul 2023 at 20:13, J. D. 
Jordan mailto:jeremiah.jor...@gmail.com>> wrote:Enabling ssl for the upgrade dtests would cover this use 
case. If those don’t currently exist I see no reason it won’t work so I would be fine for someone to figure it out post merge if there is a 
concern.  What JCE provider you use should have no upgrade concerns.-JeremiahOn Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:Am I understanding it correctly that tests you are 
talking about are only required in case we make ACCP to be default provider?I can live with not making it default and still deliver it if tests 
are not required. I do not think that these kind of tests were required couple mails ago when opt-in was on the table.While I tend to agree 
with people here who seem to consider testing this scenario to be unnecessary exercise, I am afraid that I will not be able to deliver that as 
testing something like this is quite complicated matter. There is a lot of aspects which could be tested I can not even enumerate right now ... 
so I try to meet you somewhere in the middle.From: Mick Semb Wever 
mailto:m...@apache.org>>Sent: Wednesday, July 26, 2023 17:34To: 
dev@cassandra.apache.orgSubject: Re: [DISCUSS] Using ACCP or tc-native by defaultNetApp 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.Can you 
say more about the shape of your concern?Integration testing where some nodes are running JCE and others accp, and various configurations that 
are and are not accp compatible/native.I'm not referring to (re-) unit testing accp or jce themselves, or matrix testing over them, but our 
commitment to always-on upgrades against all possible configurations that integrate.  We've history with config changes breaking upgrades, for 
as simple as they are.

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

[C. Scott Andreas]

Peter, thanks for your message.You are receiving these emails because your address is subscribed to 
the Apache Cassandra "dev@" developer mailing list. You can unsubscribe from this list by 
sending an email to dev-unsubscr...@cassandra.apache.org. Subscribers to the mailing list are not 
able to take this action on others' behalf.More information on the project's mailing lists and how to 
join/leave them is here: https://cassandra.apache.org/_/community.htmlCheers,– ScottOn Jul 26, 2023, 
at 7:11 AM, C. Scott Andreas  wrote:Can you say more about the shape of 
your concern?JCA/JCE conformance and correctness of the functions implemented are a responsibility of 
the ACCP/Corretto test suite (link). These are thoroughly exercised by Amazon and bundled into the 
Corretto JDK distribution Amazon ships as well.With regard to Cassandra, the hash and cryptographic 
functions utilized in ACCP are also thoroughly exercised by Cassandra’s unit and in-JVM dtest suite.I 
wouldn’t propose fragmenting our build into a matrix of JDK x arch x ACCP/no, in the same way that we 
wouldn’t for tcnative vs. not.- ScottOn Jul 26, 2023, at 6:48 AM, Mick Semb Wever 
 wrote:So if a service is not there it will just search where it is next. I 
completely forgot this aspect of it ... Folks from Corretto forgot to mention this behavior as well, 
interesting. It is not as we are going to use this _as the only provider_.I'm still uncomfortable 
assuming upgrades work without having the appropriate tests in place.  That's the crux for me.  
Existing JCE tests (with and without accp) should cover this?

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

[C. Scott Andreas]

Can you say more about the shape of your concern?JCA/JCE conformance and correctness of the functions implemented are a responsibility of the ACCP/Corretto test suite (link). These are thoroughly exercised by Amazon and bundled into the Corretto JDK distribution Amazon ships as well.With regard to Cassandra, the hash and cryptographic functions utilized in ACCP are also thoroughly exercised by Cassandra’s unit and in-JVM dtest suite.I wouldn’t propose fragmenting our build into a matrix of JDK x arch x ACCP/no, in the same way that we wouldn’t for tcnative vs. not.- ScottOn Jul 26, 2023, at 6:48 AM, Mick Semb Wever  wrote:So if a service is not there it will just search where it is next. I completely forgot this aspect of it ... Folks from Corretto forgot to mention this behavior as well, interesting. It is not as we are going to use this _as the only provider_.I'm still uncomfortable assuming upgrades work without having the appropriate tests in place.  That's the crux for me.  Existing JCE tests (with and without accp) should cover this?

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

[C. Scott Andreas]

Jeremiah, that’s my understanding as well. ACCP accelerates a subset of 
functions and delegates the rest.

In years of using ACCP with Cassandra, I have yet to see an issue - or any case 
in which adopting ACCP was anything other than a strict benefit.

- Scott

> On Jul 26, 2023, at 5:33 AM, J. D. Jordan  wrote:
> 
> 
> I thought the crypto providers were supposed to “ask the next one down the 
> line” if something is not supported?  Have you tried some unsupported thing 
> and seen it break?  My understanding of the providers being an ordered list 
> was that isn’t supposed to happen.
> 
> -Jeremiah
> 
>>> On Jul 26, 2023, at 3:23 AM, Mick Semb Wever  wrote:
>>> 
>> 
>> 
>> 
>>  
>> 
>>> That means that if somebody is on 4.0 and they upgrade to 5.0, if they use 
>>> some ciphers / protocols / algorithms which are not in Corretto, it might 
>>> break their upgrade.
>> 
>> 
>> 
>> If there's any risk of breaking upgrades we have to go with (2).  We support 
>> a variation of JCE configurations, and I don't see we have the test coverage 
>> in place to de-risk it other than going with (2).  
>> 
>> Once the yaml configuration is in place we can then change the default in 
>> the next major version 6.0.
>> 
>> 

Re: [ANNOUNCEMENT] Expect failures today. Dropping JDK 8 and adding JDK 11

[C. Scott Andreas]

Ekaterina, thank you for spearheading JDK17 support for Apache Cassandra! Exciting to get to this point.- ScottOn Jul 24, 2023, at 7:11 PM, Ekaterina Dimitrova  wrote:Good news! After run #1638-39 you should not see anything else failing than SSLFactory test class. This known issue will be fixed by potentially adding  bounty castle. More info in CASSANDRA-17992 and this netty PR:https://github.com/netty/netty/issues/10317We can probably mark the test class with @Ignore, but knowing how easily those are forgotten and 17992 being already in review, I prefer not to do it. The only new failure I found in #1636 is a rare flaky test we never saw in CircleCI before. (unit tests were running only there; they were not enabled in Jenkins until we cleaned them ). Ticket already opened -  CASSANDRA-18685Last but not least, eclipse-warnings is already removed (it doesn't work with post JDK8 versions), but the new static analysis from Checker Framework is already in review and soon to land in trunk - CASSANDRA-18239As usual - if you have any questions or concerns, please do let me know.Last but not least - thank you to everyone who helped in one way or another with this effort!!On Mon, 24 Jul 2023 at 16:37, Ekaterina Dimitrova  wrote:Ninja fix was required for Jenkins, new build started #1636On Mon, 24 Jul 2023 at 15:42, Ekaterina Dimitrova  wrote:Done!All commits from 18255 are in.The first run to monitor will be in Jenkins #1635There will be still fixes to be applied for some unit and in-jvm tests that were pending on the drop but I will do it when I see Jenkins kicking in this run properly.  (Which are those can be seen in CASSANDRA-16895, there is a table in its description)I will keep you posted on any new developments.On Mon, 24 Jul 2023 at 14:52, Ekaterina Dimitrova  wrote:Starting commits for 18255. Please put on hold any trunk commits. I will let you know when it is done. Thank youOn Mon, 24 Jul 2023 at 11:29, Ekaterina Dimitrova  wrote:Hi everyone,Happy Monday! I am working on dropping JDK 8 and adding JDK17 on trunk in both CI systems today.This requires numerous patches in a few repos so you will be seeing more failures in CI throughout the day today, but it shouldn’t be anything more 爛 than what we have listed in the table of failures in CASSANDRA-16895’s description. I will be applying the fixes one by one today.I will keep you posted with updates. Also, please, do let me know if you have any questions or concerns.Best regards,Ekaterina

Re: Changing the output of tooling between majors

[C. Scott Andreas]

Dinesh's message cautions against making "breaking" changes that are likely to break parsing of output by current users (e.g., changes to naming/meaning/position of existing fields vs. adding new ones). I don't read his message as saying that any change to nodetool output is conditional on 
offering a JSON/YAML representation, though.What are some changes that you'd like to make?– ScottOn Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan"  wrote:For example Dinesh said this:"Until nodetool can support JSON as output format for all interaction and 
there is a significant adoption in the user community, I would strongly advise against making breaking changes to the CLI output."That is where I get the need to have a JSON output in order to fix a typo from. That is if we look at fixing a typo as a breaking change. Which I would say it is as if 
somebody is "greping" it and it is not there, it will break.Do you understand that the same way or am I interpreting that wrong?________From: C. Scott Andreas Sent: Thursday, July 13, 2023 16:35To: dev@cassandra.apache.orgCc: devSubject: 
Re: Changing the output of tooling between majorsNetApp 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."From what I see you guys want to condition any change by offering json/yaml as well."I don't 
think I've seen a proposal to block changes to nodetool output on machine-parseable formats in this thread.Additions of new delimited fields to nodetool output are mostly straightforward. Changes to fields that exist today are likely to cause problems - as Josh mentions. These seem best to take on a 
case-by-case basis rather than trying to hammer out an abstract policy. What changes would you like to make?I do think we will have difficulty evolving output formats of text-based Cassandra tooling until we offer machine-parseable output formats.– ScottOn Jul 13, 2023, at 6:39 AM, Josh McKenzie 
 wrote:I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about that.Well, we're talking about programmatic parsing here. This feels like complaining about a compiler that won't let you build if 
you're missing a ;We can change it, but that doesn't mean the aggregate cost/benefit across our entire ecosystem is worth it. The value of correcting a typo is pretty small, and the cost for everyone downstream is not. This is why we should spellcheck things in API's before we release them. :)On Wed, Jul 
12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:Eric,I appreciate your feedback on this, especially more background about where you are comming from in the second paragraph.I think we are on the same page afterall. I definitely understand that people are depending on this output and we need to be careful. 
That is why I propose to change it only each major. What I feel is that everybody's usage / expectations is little bit different and outputs of the commands are very diverse and it is hard to balance this so everybody is happy.I am trying to come up with a solution which would not change the most important 
commands unnecessarily while also having some free room to tweak the existing commands where we see it appropriate. I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about that.If I had to summarize this whole discussion, 
the best conclustion I can think of is to not change what is used the most (this would probably need to be defined more explicitly) and if we have to change something else we better document that extensively and provide json/yaml for people to be able to divorce from the parsing of human-readable format 
(which probably all agree should not happen in the first place).What I am afraid of is that in order to satisfy these conditions, if, for example, we just want to fix a typo or the format of a key of some value, the we would need to deliver JSON/YAML format as well if there is not any yet and that would 
mean that the change of such triviality would require way more work in terms of the implementation of JSON/YAML format output. Some commands are quite sophisticated and I do not want to be blocked to change a field in human-readable out because providing corresponding JSON/YAML format would be gigantic 
portion of the work itself.From what I see you guys want to condition any change by offering json/yaml as well and I dont know if that is just not too much.From: Eric Evans mailto:eev...@wikimedia.org>>Sent: Wednesday, July 12, 2023 
19:48To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>Subject: Re: Changing the output of tooling between majorsYou don't often get email from eev...@wikimedia.org<mailto:eev...@wikimedia

Re: Changing the output of tooling between majors

[C. Scott Andreas]

"From what I see you guys want to condition any change by offering json/yaml as well."I don't think I've seen a proposal to block changes to nodetool output on machine-parseable formats in 
this thread.Additions of new delimited fields to nodetool output are mostly straightforward. Changes to fields that exist today are likely to cause problems - as Josh mentions. These seem best to take 
on a case-by-case basis rather than trying to hammer out an abstract policy. What changes would you like to make?I do think we will have difficulty evolving output formats of text-based Cassandra 
tooling until we offer machine-parseable output formats.– ScottOn Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:I just find it ridiculous we can not change 
"someProperty: 10" to "Some Property: 10" and there is so much red tape about that.Well, we're talking about programmatic parsing here. This feels like complaining about a compiler 
that won't let you build if you're missing a ;We can change it, but that doesn't mean the aggregate cost/benefit across our entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck things in API's before we release them. :)On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:Eric,I appreciate your 
feedback on this, especially more background about where you are comming from in the second paragraph.I think we are on the same page afterall. I definitely understand that people are depending on this 
output and we need to be careful. That is why I propose to change it only each major. What I feel is that everybody's usage / expectations is little bit different and outputs of the commands are very 
diverse and it is hard to balance this so everybody is happy.I am trying to come up with a solution which would not change the most important commands unnecessarily while also having some free room to 
tweak the existing commands where we see it appropriate. I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about 
that.If I had to summarize this whole discussion, the best conclustion I can think of is to not change what is used the most (this would probably need to be defined more explicitly) and if we have to 
change something else we better document that extensively and provide json/yaml for people to be able to divorce from the parsing of human-readable format (which probably all agree should not happen in 
the first place).What I am afraid of is that in order to satisfy these conditions, if, for example, we just want to fix a typo or the format of a key of some value, the we would need to deliver 
JSON/YAML format as well if there is not any yet and that would mean that the change of such triviality would require way more work in terms of the implementation of JSON/YAML format output. Some 
commands are quite sophisticated and I do not want to be blocked to change a field in human-readable out because providing corresponding JSON/YAML format would be gigantic portion of the work 
itself.From what I see you guys want to condition any change by offering json/yaml as well and I dont know if that is just not too much.From: Eric Evans 
Sent: Wednesday, July 12, 2023 19:48To: dev@cassandra.apache.orgSubject: Re: Changing the output of tooling between majorsYou don't often get email from 
eev...@wikimedia.org. Learn why this is importantNetApp 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.On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan mailto:stefan.mikloso...@netapp.com>> wrote:I agree 
with Jackson that having a different output format (JSON/YAML) in order to be able to change the default output resolves nothing in practice.As Jackson said, "operators who maintain these scripts 
aren’t going to re-write them just because a better way of doing them is newly available, usually they’re too busy with other work and will keep using those old scripts until they stop 
working".This is true. If this approach is adopted, what will happen in practice is that we change the output and we provide a different format and then a user detects this change because his 
scripts changed. As he has existing solution in place which parses the text from human-readable output, he will try to fix that, he will not suddenly convert all scripting he has to parsing JSON just 
because we added it. Starting with JSON parsing might be done if he has no scripting in place yet but then we would not cover already existing deployments.I think this is quite an extreme conclusion to 
draw.  If tooling had stable, structured output formats, and if we documented an expectation that human-readable console output was unstable, then presumably it would be safe to assume that any new 

Re: Changing the output of tooling between majors

[C. Scott Andreas]

Agreed with Eric’s point here, yes.- ScottOn Jul 12, 2023, at 10:48 AM, Eric Evans  wrote:On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan  wrote:I agree with Jackson that having a different output format (JSON/YAML) in order to be able to change the default output resolves nothing in practice.

As Jackson said, "operators who maintain these scripts aren’t going to re-write them just because a better way of doing them is newly available, usually they’re too busy with other work and will keep using those old scripts until they stop working".

This is true. If this approach is adopted, what will happen in practice is that we change the output and we provide a different format and then a user detects this change because his scripts changed. As he has existing solution in place which parses the text from human-readable output, he will try to fix that, he will not suddenly convert all scripting he has to parsing JSON just because we added it. Starting with JSON parsing might be done if he has no scripting in place yet but then we would not cover already existing deployments.I think this is quite an extreme conclusion to draw.  If tooling had stable, structured output formats, and if we documented an expectation that human-readable console output was unstable, then presumably it would be safe to assume that any new scripters would avail themselves of the stable formats, or expect breakage later.  I think it's also fair to assume that at least some people would spend the time to convert their scripts, particularly if forced to revisit them (for example, after a breaking change to console output).  As someone who manages several large-scale mission-critical Cassandra clusters under constrained resources, this is how I would approach it.TL;DR Don't let perfect by the enemy of good[ ... ] 
For that reason, what we could agree on is that we would never change the output for "tier 1" commands and if we ever changed something, it would be STRICT ADDITIONS only. In other words, everything it printed, it would continue to print that for ever. Only new lines could be introduced. We need to do this because Cassandra is evolving over time and we need to keep the output aligned as new functionality appears. But the output would be backward compatible. Plus, we are talking about majors only.

The only reason we would ever changed the output on "tier 1" commands, if is not an addition, is the fix of the typo in the existing output. This would again happened only in majors.

All other output for all other commands might be changed but their output will not need to be strictly additive. This would again happen only between majors.

What is you opinion about this?To be clear about where I'm coming from: I'm not arguing against you or anyone else making changes like these (in major versions, or otherwise).  If —for example— we had console output that was incorrect, incomplete, or obviously misleading, I'd absolutely want to see that fixed, script breakage be damned.  All I want is for folks to recognize the problems this sort of thing can create, and show a bit of empathy before submitting a change.  For operators on the receiving end, it can be really frustrating, especially when there is no normative change (i.e. it's in service of aesthetics). -- Eric EvansStaff SRE, Data PersistenceWikimedia Foundation

Re: [DISCUSS] Conducting a User Survey

[C. Scott Andreas]

Thanks Patrick. I like the idea of a user survey.Added a handful of comments in the doc. – 
ScottOn Jul 11, 2023, at 12:51 AM, Mick Semb Wever  wrote:Looks good 
to me, thanks Patrick.On Tue, 11 Jul 2023 at 03:11, Patrick McFadin 
 wrote:For quite a few years, I have done Twitter polls to gather 
helpful information about how people use Apache Cassandra. Twitter is no longer the best 
place to conduct this kind of activity since it has become a ghost town.We should ask more 
comprehensive questions to get the pulse of our user community. I want to do a simple 
Google Form survey that we can promote on every channel for a few weeks. I'll anonymize the 
results and post them on cassandra.apache.org.Here are the proposed questions I have 
compiled. A pretty basic set of questions, but it would be fun to know the answer to 
several of these: 
https://docs.google.com/document/d/18627E1UV-BjLyuNFgV0cgPwPmtjUHy7Th9Mk15ll1IA/edit?usp=sharingComments
 are open to all. Please let me know what you think.Patrick

Re: [VOTE] CEP 33 - CIDR filtering authorizer

[C. Scott Andreas]

+1nbOn Jun 28, 2023, at 6:40 PM, Abe Ratnofsky  wrote:+1 (nb)On Jun 28, 2023, at 18:38, guo Maxwell  wrote:+1 Nate McCall 于2023年6月29日 周四上午9:25写道：+1 On Wed, Jun 28, 2023 at 5:17 AM 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
-- you are the apple of my eye !

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

[C. Scott Andreas]

+1 for ACCP and can attest to its results. ACCP also optimizes for a range of hash 
functions and other cryptographic primitives beyond TLS acceleration for Netty.On Jun 22, 
2023, at 2:07 PM, Jeff Jirsa  wrote:Either would be better than 
today. On Thu, Jun 22, 2023 at 1:57 PM Jordan West  wrote:Hi,I’m 
wondering if there is appetite to change the default SSL provider for Cassandra going 
forward to either ACCP [1] or tc-native in Netty? Our deployment as well as others I’m 
aware of make this change in their fork and it can lead to significant performance 
improvement. When recently qualifying 4.1 without using ACCP (by accident) we noticed p99 
latencies were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and also 
requires some amount of customization. I think it could be great for the wider community to 
adopt it. The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. 
Anything else I am missing before opening a JIRA and submitting a patch?Jordan [1] 
https://github.com/corretto/amazon-corretto-crypto-provider

Re: [VOTE] CEP-8 Datastax Drivers Donation

[C. Scott Andreas]

+1nbOn Jun 13, 2023, at 10:25 AM, German Eichberger via dev  wrote:






+ 1




Great to see this moving forward!


From: Abe Ratnofsky 
Sent: Tuesday, June 13, 2023 10:09 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] CEP-8 Datastax Drivers Donation
 



+1 (nb)

On Jun 13, 2023, at 09:23, Andrés de la Peña  wrote:





+1



On Tue, 13 Jun 2023 at 16:40, Yifan Cai  wrote:





+1






From: David Capwell 
Sent: Tuesday, June 13, 2023 8:37:10 AM
To: dev 
Subject: Re: [VOTE] CEP-8 Datastax Drivers Donation
 

+1


On Jun 13, 2023, at 7:59 AM, Josh McKenzie  wrote:



+1




On Tue, Jun 13, 2023, at 10:55 AM, Jeremiah Jordan wrote:


+1 nb




On Jun 13, 2023 at 9:14:35 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: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[C. Scott Andreas]

+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 production OLTP clusters is transformative.– ScottOn May 4, 2023, at 9: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+AnalyticsJira:https://issues.apache.org/jira/browse/CASSANDRA-16222Draft
 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-apisDiscussion:https://lists.apache.org/thread/lrww4d7cdxgtg8o3gt8b8foymzpvq7z3The
 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: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

[C. Scott Andreas]

If there’s lack of clarity around EOL policy and dates, we should absolutely make this clear.Most releases of the project have been “LTS” in that the release cadence since 2018 has not been rapid but focused on minor enhancements on long-lived branches like 3.0, 3.11, and 4.0.x. But I’d distinguish between the idea of “LTS” and stability, as stability is continually improving and contributors are bringing a stronger focus to low-effort upgrades and minimizing deprecations.Cassandra 3.11 was released six years ago, with major progress in quality, stability, and features since that time. Contributors have brought more attention to a smooth upgrade experience than I’ve seen in nearly any OSS database.If there are vendors who offer Apache Cassandra as a service or provide paid support who wish to offer extended security updates for EOL’d releases, this seems like a fine area to step in - e.g., via an affirmative commitment of resources to identify vulnerabilities in legacy releases and provide targeted patches to address them.It feels like another thing to ask the project (who are a community of contributors) to provide post-EOL support for releases with a published end-of-support date. Who will do that, and who will honor that commitment? The project does not have the ability to demand specific contributions from its contributors, and most contributors are focused on advancing the project forward.It seems likely that such contributions would be welcome - e.g., dependency bumps, surgical fixes, or default config changes needed to address a vulnerability found in an older release — especially if a future “log4j”-like discovery were to occur. But it seems difficult for the project to bind itself to this as a matter of policy, and a great area for a vendor who is interested in this being warranted to commit the resources needed for it to be possible.— ScottOn Apr 14, 2023, at 9:14 AM, German Eichberger via dev  wrote:





All,


What does it mean to be OpenSource? For me the community is developers/maintainers who
 work on Cassandra, operators who run Cassandra, and developers who write applications which use Cassandra. We all need to work together to make Cassandra successful - and we need to listen to each other to make the project successful.


It's apparent that a sizable number of people haven't migrated from 3.11 to 4.x - this
 might be because the EOL announcement has been confusing and what EOL means is fuzzy. Does the project still fix CVEs, will there be infrastructure if someone wants to fix something, etc.  So at a minimum I would expect documentation and agreement around those
 things.


If you look at Ubuntu and Java they distinguish between LTS releases and normal releases
 - but they are also doing this for a long time. The quicker release cycle (a new release every year) is sort of new-ish and hasn't been digested by all operators and users. So given 3.11 only extra support for a limited time to aid the transition like OpenJDK
 is doing for Java 8 might be prudent - Mick raises a valid point that if we go out and say "this is the new EOL, but this time we mean it" might encourage people to hope for another extension. I have no good answer other than communicate harder and more clearly
 - the status quo lacks clarity which is worse.


The other point Mick raises which releases to support gets to another discussion: As of
 today operators need to upgrade every two years and (also jump versions) aka I would need to go 3.11->4.1 right when it came out to get the full two year "support". I might feel uncomfortable going to a release which has just been released so realistically
 I need to update in between one and two years - give or take. This raises the question if we should dedicate some versions as LTS releases meaning they get longer support. Five years is common but that is also up for discussion. As an added benefit if there
 are commercial entities wanting to offer paid support they could focus on the LTS releases and bundle resources for the upstream support.


This is a good discussion and I feel especially the implied CVE support needs to be more
 formalized.


Thanks for indulging me,
German



From: Jacek Lewandowski 
Sent: Thursday, April 13, 2023 11:23 PM
To: dev@cassandra.apache.org 
Subject: Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL
 



To me, as this is an open source project, we, the community, do not have to do anything, we can, but we are not obliged to, and we usually do that because we want to :-) 


To me, EOL means that we move focus to newer releases. Not that we are forbidden to do anything in the older ones. One formal point though is the machinery - as long as we have the machinery
 to test and release, that's all we need. However, in face of coming changes in testing, I suppose some extra effort will have to be done to support older versions. Finding people who want to help out with that could be a kind of validation whether that effort
 is 

Re: Please grant Wiki access for CEP

[C. Scott Andreas]

Done, thanks Doug!On Mar 21, 2023, at 2:22 PM, Doug Rohrer  
wrote:Hi folks:I’d like to post a CEP, but given it’s the first time I’m trying to 
contribute to the wiki, I don’t have access.If someone with access could please grant 
user drohrer access to post, I’d greatly appreciate it.Thanks,Doug Rohrer

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

[C. Scott Andreas]

I agree with Aleksey's view here.To expand on the final point he makes re: requiring 
SSTables be fully rewritten prior to rev'ing from 4.x to 5.x (if the cluster previously ran 
3.x) –This would also invalidate incremental backups. Operators would either be required to 
perform a full snapshot backup of each cluster to object storage prior to upgrading from 
4.x to 5.x; or to enumerate the contents of all snapshots from an incremental backup series 
to ensure that no m*-series SSTables were present prior to upgrading.If one failed to take 
on the work to do so, incremental backup snapshots would not be restorable to a 5.x cluster 
if an m*-series SSTable were present.– ScottOn Mar 14, 2023, at 4:38 AM, Aleksey Yeshchenko 
 wrote:Raising messaging service minimum, I have a less strong 
opinion on, but on dropping m* sstable code I’m strongly -1.1. This is code on a rarely 
touched path2. It’s very stable and battle tested at this point3. Removing it doesn’t 
reduce much complexity at all, just a few branches are affected4. Removing code comes with 
risk5. There are third-party tools that I know of which benefit from a single C* jar that 
can read all relevant stable versions, and relevant here includes 3.0 onesRemoving a little 
of battle-tested reliable code and a tinier amount of complexity is not, to me, a benefit 
enough to justify intentionally breaking perfectly good and useful functionality.Oh, to add 
to that - if an operator wishes to upgrade from 3.0 to 5.0, and we don’t support it 
directly, I think most of us are fine with the requirement to go through a 4.X release 
first. But it’s one thing to require a two rolling restarts (3.0 to 4.0, 4.0 to 5.0), it’s 
another to require the operator to upgrade every single m* sstable to n*. Especially when 
we have perfectly working code to read those. That’s incredibly wasteful.AYOn 13 Mar 2023, 
at 22:54, Mick Semb Wever  wrote:If we do not recommend and do not 
test direct upgrades from 3.x to5.x, we can clean up a fair bit by removing code related to 
sstableformats m*, as Cassandra versions 4.x and  5.0 are all on sstableformats n*.We don't 
allow mixed-version streaming, so it's not possible today tostream any such older sstable 
format between nodes. Thiscompatibility-break impacts only node-local and/or offline.Some 
arguments raised to keep m* sstable formats are:- offline cluster upgrade, e.g. direct from 
3.x to 5.0,- single-invocation sstableupgrade usage- third-party tools based on the 
abovePersonally I am not in favour of keeping, or recommending users use,code we don't 
test.An _example_ of the code that can be cleaned up is in the patchattached to the 
ticket:CASSANDRA-18312 – Drop support for sstable formats before `na`What do you think?

Re: [DISCUSS] Enhanced Disk Error Handling

[C. Scott Andreas]

Realized I’m somewhat mistaken here -

The repair of surviving replicas would be necessary for correctness prior to 
the node with deleted data files to be able to serve client/internode reads.

But the repair of the node with deleted data files prior to being brought back 
into the cluster is more of an optimization to avoid read repair for queries 
over the affected range grinding traffic to a halt, rather than necessary for 
safety.

— Scott

> On Mar 8, 2023, at 8:54 AM, C. Scott Andreas  wrote:
> 
> For this to be safe, my understanding is that:
> 
> – A repair of the affected range would need to be completed among the 
> replicas without such corruption (including paxos repair).
> – And we'd need a mechanism to execute repair on the affected node without it 
> being available to respond to queries, either via the client protocol or via 
> internode (similar to a partial bootstrap).
> 
> My hunch is that the examples where this are desirable might be limited 
> though. It might allow one to limp along on a bad drive momentarily while a 
> proper replacement is bootstrapped, but typically with disk failures where 
> there's smoke there's fire - I wouldn't expect a drive reporting 
> uncorrectable errors / filesystem corruption to be long for this world.
> 
> Can you say more about the scenarios you have in mind?
> 
> – Scott
> 
>> On Mar 8, 2023, at 5:24 AM, Bowen Song via dev  
>> wrote:
>> 
>> 
>> At the moment, when a read error, such as unrecoverable bit error or data 
>> corruption, occurs in the SSTable data files, regardless of the 
>> disk_failure_policy configuration, manual (or to be precise, external) 
>> intervention is required to recover from the error.
>> 
>> Commonly, there's two approach to recover from such error:
>> 
>> The safer, but slower recover strategy: replace the entire node.
>> The less safe, but faster recover strategy: shut down the node, delete the 
>> affected SSTable file(s), and then bring the node back online and run repair.
>> Based on my understanding of Cassandra, it should be possible to recover 
>> from such error by marking the affected token range in the existing SSTable 
>> as "corrupted" and stop reading from them (e.g. creating a "bad block" file 
>> or in memory), and then streaming the affected token range from the healthy 
>> replicas. The corrupted SSTable file can then be removed upon the next 
>> successful compaction involving it, or alternatively an anti-compaction is 
>> performed on it to remove the corrupted data.
>> 
>> The advantage of this strategy is:
>> 
>> Reduced node down time - node restart or replacement is not needed
>> Less data streaming is required - only the affected token range
>> Faster recovery time - less streaming and delayed compaction or 
>> anti-compaction
>> No less safe than replacing the entire node
>> This process can be automated internally, removing the need for operator 
>> inputs
>> The disadvantage is added complexity on the SSTable read path and it may 
>> mask disk failures from the operator who is not paying attention to it.
>> 
>> What do you think about this?
>> 
> 

Re: [DISCUSS] Enhanced Disk Error Handling

[C. Scott Andreas]

For this to be safe, my understanding is that:– A repair of the affected range would 
need to be completed among the replicas without such corruption (including paxos 
repair).– And we'd need a mechanism to execute repair on the affected node without it 
being available to respond to queries, either via the client protocol or via 
internode (similar to a partial bootstrap).My hunch is that the examples where this 
are desirable might be limited though. It might allow one to limp along on a bad 
drive momentarily while a proper replacement is bootstrapped, but typically with disk 
failures where there's smoke there's fire - I wouldn't expect a drive reporting 
uncorrectable errors / filesystem corruption to be long for this world.Can you say 
more about the scenarios you have in mind?– ScottOn Mar 8, 2023, at 5:24 AM, Bowen 
Song via dev  wrote:At the moment, when a read error, 
such as unrecoverable bit error
 or data corruption, occurs in the SSTable data files, regardless
 of the disk_failure_policy configuration, manual (or to be
 precise, external) intervention is required to recover from the
 error.Commonly, there's two approach to recover from such error:The safer, 
but slower recover strategy: replace the entire
   node.The less safe, but faster recover strategy: shut down the
   node, delete the affected SSTable file(s), and then bring the
   node back online and run repair.Based on my understanding of Cassandra, 
it should be possible to
 recover from such error by marking the affected token range in the
 existing SSTable as "corrupted" and stop reading from them (e.g.
 creating a "bad block" file or in memory), and then streaming the
 affected token range from the healthy replicas. The corrupted
 SSTable file can then be removed upon the next successful
 compaction involving it, or alternatively an anti-compaction is
 performed on it to remove the corrupted data.The advantage of this 
strategy is:Reduced node down time - node restart or replacement is not
   neededLess data streaming is required - only the affected token
   rangeFaster recovery time - less streaming and delayed compaction
   or anti-compactionNo less safe than replacing the entire nodeThis 
process can be automated internally, removing the need
   for operator inputsThe disadvantage is added complexity on the SSTable 
read path and
 it may mask disk failures from the operator who is not paying
 attention to it.What do you think about this?

Re: Degradation of availability when using NTS and RF > number of racks

[C. Scott Andreas]

Modifying NTS in place would not be possible if it changes rack placement in a 
way that breaks existing clusters on upgrade. A strategy introducing a change 
to placement like this would need a new name. A new strategy would be fine in 
trunk.

Logging a warning seems appropriate if RF > rack count.

A discuss thread seems fine for this rather than a CEP to me.

— Scott

> On Mar 6, 2023, at 2:51 AM, Miklosovic, Stefan  
> wrote:
> 
> Hi all,
> 
> some time ago we identified an issue with NetworkTopologyStrategy. The 
> problem is that when RF > number of racks, it may happen that NTS places 
> replicas in such a way that when whole rack is lost, we lose QUORUM and data 
> are not available anymore if QUORUM CL is used.
> 
> To illustrate this problem, lets have this setup:
> 
> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place 
> replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in 
> rack3. Hence, when rack1 is lost, we do not have QUORUM.
> 
> It seems to us that there is already some logic around this scenario (1) but 
> the implementation is not entirely correct. This solution is not computing 
> the replica placement correctly so the above problem would be addressed.
> 
> We created a draft here (2, 3) which fixes it.
> 
> There is also a test which simulates this scenario. When I assign 256 tokens 
> to each node randomly (by same mean as generatetokens command uses) and I try 
> to compute natural replicas for 1 billion random tokens and I compute how 
> many cases there will be when 3 replicas out of 5 are inserted in the same 
> rack (so by losing it we would lose quorum), for above setup I get around 6%.
> 
> For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10% cases.
> 
> To interpret this number, it basically means that with such topology, RF and 
> CL, when a random rack fails completely, when doing a random read, there is 
> 6% chance that data will not be available (or 10%, respectively).
> 
> One caveat here is that NTS is not compatible with this new strategy anymore 
> because it will place replicas differently. So I guess that fixing this in 
> NTS will not be possible because of upgrades. I think people would need to 
> setup completely new keyspace and somehow migrate data if they wish or they 
> just start from scratch with this strategy.
> 
> Questions:
> 
> 1) do you think this is meaningful to fix and it might end up in trunk?
> 
> 2) should not we just ban this scenario entirely? It might be possible to 
> check the configuration upon keyspace creation (rf > num of racks) and if we 
> see this is problematic we would just fail that query? Guardrail maybe?
> 
> 3) people in the ticket mention writing "CEP" for this but I do not see any 
> reason to do so. It is just a strategy as any other. What would that CEP 
> would even be about? Is this necessary?
> 
> Regards
> 
> (1) 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
> (2) https://github.com/apache/cassandra/pull/2191
> (3) https://issues.apache.org/jira/browse/CASSANDRA-16203

Re: [DISCUSS] Next release date

[C. Scott Andreas]

Regarding “We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window.” —Speaking solely from my perspective, the single biggest time draw was tracking down and resolving https://issues.apache.org/jira/browse/CASSANDRA-18110.One of the strategies we employ to validate a build is to simply run it. Reproducing and resolving this issue was a prerequisite for running the branch and performing further qualification as it blocked host replacements in mercurial circumstances. That work began prior to ApacheCon and was completed in December with continuous focus, but wasn’t something other contributors were able to reproduce (and was difficult for us, too).Inability to replace a host and run the build slowed subsequent issue-finding/fixing - in many cases past release, with bugs I think we’d have been able to find prior to 4.1.0 if we’d been able to lean harder on it (18194, 18119, 18292, probably a couple others).I do wish we’d have been able to find the cause of C-18110 faster - or at least its workaround.- ScottOn Feb 28, 2023, at 9:06 AM, Benedict  wrote:I agree, we shouldn’t be branching annually, we should be releasing annually - and we shouldn’t assume that will take six months. We should be aiming for 1-2mo and so long as our trajectory towards that is good, I don’t think there’s anything to worry about (and we’ll get our first comparative data point this release)On 28 Feb 2023, at 16:02, Ekaterina Dimitrova  wrote:By “not to have to delay again” I mean GA, not the agreement for when to branch and start feature freeze. Just to be clear as I realized I might be misunderstood :-) On Tue, 28 Feb 2023 at 10:47, Ekaterina Dimitrova  wrote:I agree that November-May falls too short so +1 on postponing the day on my endNow I think Mick brought excellent point - let’s get into separate discussion about the root cause of releasing 4.1 only in December and see what we need to change/improve on so we do not get into future delays and we do not sacrifice QA of course. “Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?“I’d say move it, get to the bottom of how not to have to delay again or at least reduce the window and commitOn Tue, 28 Feb 2023 at 9:38, Mick Semb Wever  wrote:We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for 4.1 we were only able to release GA in December which impacted how much time we could spend focussing on the next release and the progress that we could do. By consequence, I am wondering if it makes sense for us to branch 5.0 in May or if we should postpone that date.What is your opinion?My initial preference is to stick with the May branch and its initial alpha/beta release. Giving in to the delays doesn't improve the causes of them.We should focus on why it took 6 months to go from 4.1 first alpha to GA and what happened inside that time window. I'm not convinced summer holidays can be to blame for. I think a lack of QA/CI and folk dedicating time to get it to GA is the bigger problem. On the QA/CI front I believe we have made significant improvements already. And we saw less releases of 4.1 before its GA. I also think reducing the focus and scope of the subsequent release cycle is a cost that creates the correct incentive, so long as we share the burden of the stabilising_to_GA journey. While it might be difficult for folk to commit their time over summer holidays, the three months of May-July should be way more than enough if we are serious about it.My thoughts don't touch on CEPs inflight. But my feeling is this should not be about what we want to "squeeze in" (which only makes the problem worse), rather whether the folk that are offering their time to stabilise to GA have a preference for May-July or their September-November."Postponing" suggests a one-off move, but I'm presuming this would be a permanent change?

Re: Downgradability

[C. Scott Andreas]

I realize my feedback on this has been spread across tickets and older mailing list / wiki discussions, so I'll offer a proposal here.Starting with goals -1. Cassandra users must be able to abort and 
revert an upgrade to a new version of the database that introduces a new major SSTable format.This reduces risk of upgrading to a build that also introduces a non-data-format-related bug that is 
intolerable. This goal does not specify a mechanism or downgrade target - just the "downgradability" goal.2. Where possible, Cassandra users should be able to opt into writing of a new major 
SSTable format.This reduces that risk further by allowing users to decouple data format changes from the upgrade itself. There may be cases where new features or bug fixes prevent this from being possible, 
but I'll offer it as a goal.3. It should be possible for users to perform the downgrade in-place by launching the database using a previous version's binary.This avoids the need for complex orchestration 
of offline commands like a hypothetical `downgradesstables`.The following approach would allow us to accomplish these goals:1. Major SSTable changes should begin with forward-compatibility in a prior 
release.In a release prior to one that revs major SSTable versions, we should implement the ability to read the SSTables that we intend to write in the next major version. This would allow someone to 
(eg.,) revert from 5.0 to 4.2 if they encountered a regression that caused an outage without data loss. This downgrade path should be well-specified and called out in NEWS.txt.2. Where possible, major 
SSTable format changes should be opt-in (if the features / bugfixes introduced allow).This would be via a flag to enable writing the new format once an operator has determined that post-upgrade their 
clusters are sufficiently stable. This is an approach that HDFS has adopted. Following a rolling upgrade of HDFS, downgrade remains possible until an operator executes a "finalize" operation to 
migrate NameNode metadata to the new version's. An approach like this would allow users to perform a staged upgrade in which they first rev the version of the database, followed by opting into its new 
format to derisk (eg.,) adoption of BTI-indexed SSTables.These approaches aren't meant to discourage SSTable format evolution - but to make it safer, and ideally faster. They don't specify duplicative 
serialization or a game of Twister to hide fields in locations where old versions don't think to look. Forward compatibility in a prior release could be landed at the same time as the major format revision 
itself, so long as we cut releases from both branches.Ability to back out an upgrade until finalized would dramatically lower the risk of adopting new releases of Apache Cassandra. For many users, the 
qualification cycle for a new release is more than a year - and a *lot* of work.Reducing the risk of upgrading to new releases repositions Cassandra as a database that can be treated with greater trust -- 
especially for multi-petabyte, mission critical systems. Our user community will advance to newer releases more quickly and we'll be able to shorten the maintenance cycles for older releases. In the same 
way that CI stability enables us to move faster and more confidently in the project, safety features like this will enable our users (and indeed ourselves) to move more confidently to adopt them.– ScottOn 
Feb 21, 2023, at 4:51 AM, "Claude Warren, Jr via dev"  wrote:My goal in implementing CASSANDRA-8928 was to be able to take the current version 4.x and write it as 
the earliest 3.x version possible.  The reasoning being that if that was possible then whatever 3.x version was executed would be able to automatically read the early 3.x version.  My thought was that each 
release version would have the ability to downgrade to the earliest previous version.  In this way if users need to they could string together a number of downgrader versions to move from 5.x to 3.x. My 
testing has been pretty straightforward, I created 4 docker containers using the standard published Cassandra docker images for 3.1 and 4.0 with data mounted on an external drive.  two of the containers 
(one of each version) did not automatically start Cassandra.  My process was then:start and stop Cassandra 4.0 to create the default data filesstart the Cassandra 4.0 container that does not automatically 
run Cassandra and execute the new downgrade functionality.start the Cassandra 3.1 container and dump the logs.  If the system started then I knew that I at least had a proof of concept.  So far no-go.On 
Tue, Feb 21, 2023 at 8:57 AM Branimir Lambov  wrote:It appears to me that the first thing we need to start this feature off is a definition of a suite of tests together 
with a set of rules to keep the suite up to date with new features as they are introduced. The moment that suite is in place, we can start having some confidence that we can enforce 

Re: Google Season of Documentation proposal

[C. Scott Andreas]

Thanks and congratulations Lorina!

— Scott

> On Feb 16, 2023, at 4:29 PM, Lorina Poland  wrote:
> 
> Good news! The Open Collective application was accepted! Step one is done.
> 
> Lorina
> 
>> On 2023/02/13 22:23:35 Lorina Poland wrote:
>> Hi all -
>> 
>> I have submitted an application to the Open Collective, so that we would
>> have a funding mechanism to pay 1-2 technical writers if we are successful
>> with our GSoD proposal.
>> 
>> I have the GSoD proposal ready, and am only waiting for the first date for
>> submission, Feb 15, 2023. Here is a link to the proposal:
>> https://docs.google.com/document/d/1611cuNDcC0S_xwfHbRca1AGqgqDr606a2DCznKabAMg/edit?usp=sharing
>> 
>> If you have comments or questions, please let me know. I'll be waiting on:
>> 
>>   - Open Collective to accept the application
>>   - Google to open for submissions for GSoD
>> 
>> If successful, we'll need a blog post for cassandra.apache.com to announce
>> to technical writers that they should apply.
>> 
>> Thanks,
>> Lorina
>> 

Re: [DISCUSS] Merging incremental feature work

[C. Scott Andreas]

Supportive of this as well.

I see testability of trunk against JDK17 as more important than continuous 
preservation of support for scripted UDFs *during* that development.

Will be tempted to cherry-pick this and begin kicking the tires as soon as it’s 
ready.  

- Scott

> On Feb 5, 2023, at 6:14 PM, Mick Semb Wever  wrote:
> 
> 
>  
>> To my understanding this wasn't the original desire and consensus with 
>> JDK17, folk requested that it be introduced complete, though I cannot 
>> actually find the reference to that.  I was about to raise a thread asking 
>> for us to instead take an incremental approach, to help us move faster and 
>> safer, but am doing it here, thanks for raising the thread Josh.   As others 
>> point out, we can't paint ourselves into the wrong corner with JDK17, though 
>> we can't drop JDK8 support until we're out of the (right) corner.
> 
> 
> I forgot to mention something.
> 
> Taking an incremental approach here also includes dropping support for 
> scripted UDFs first, and later on adding hooks for UDFs so users can re-add 
> the functionality.  (This could have been (but idk,) the "complete" desire 
> expressed.)
> 
> Implementing the hooks for UDFs is a current blocker and slowing down the 
> introduction of jdk17.  We would like to remove the blocker by first dropping 
> the already deprecated UDFs first.  I am for this approach because everyone 
> having to develop and test against jdk8, when they know 5.0 won't, is more 
> the headache here.
> 
> 

Re: Welcome Patrick McFadin as Cassandra Committer

[C. Scott Andreas]

Congratulations, Patrick!On Feb 2, 2023, at 9:46 PM, Berenguer Blasi 
 wrote:Welcome!On 3/2/23 4:09, Vinay Chella 
wrote:Well deserved one, Congratulations, Patrick. On Fri, Feb 3, 2023 at 4:01
   AM Josh McKenzie 
   wrote:Congrats Patrick! Well deserved.On Thu, Feb 2, 2023, at 5:25 
PM, Molly Monroy wrote:Congrats, Patrick... much deserved!On Thu, Feb 2, 2023 
at 1:59 PM Derek
   Chen-Becker 
   wrote:Congrats!On Thu, Feb 2, 2023 at 10:58 AM
   Benjamin Lerer 
   wrote:The PMC members are pleased to announce
   that Patrick McFadin has acceptedthe 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--+---+|
   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  
|+---+-- 
Thanks,Vinay Chella

Re: Implicitly enabling ALLOW FILTERING on virtual tables

[C. Scott Andreas]

There are some ideas that development community members have kicked around that may falsify the assumption that "virtual tables are 
tiny and will fit in memory."One example is CASSANDRA-14629: Abstract Virtual Table for very large result 
setshttps://issues.apache.org/jira/browse/CASSANDRA-14629Chris's proposal here is to enable query results from virtual tables to be 
streamed to the client rather than being fully materialized. There are some neat possibilities suggested in this ticket, such as debug 
functionality to dump the contents of a raw SSTable via the CQL interface, or the contents of the database's internal caches. One could 
also imagine a feature like this providing functionality similar to a foreign data wrapper in other databases.I don't think the 
assumption that "virtual tables will always be small and always fit in memory" is a safe one.I don't think we should implicitly 
add "ALLOW FILTERING" to all queries against virtual tables because of this, in addition to concern with departing from 
standard CQL semantics for a type of tables deemed special.– ScottOn Feb 3, 2023, at 6:52 AM, Maxim Muzafarov  
wrote:Hello Stefan,Regarding the decision to implicitly enable ALLOW FILTERING forvirtual tables, which also makes sense to me, it may be 
necessary toconsider changing the clustering columns in the virtual table metadatato regular columns as well. The reasons are the same as 
mentionedearlier: the virtual tables hold their data in memory, thus we do notbenefit from the advantages of ordered data (e.g. the 
ClientsTable andits ClusteringColumn(PORT)).Changing the clustering column to a regular column may simplify thevirtual table data model, 
but I'm afraid it may affect users who relyon the table metadata.On Fri, 3 Feb 2023 at 12:32, Andrés de la Peña 
 wrote:I think removing the need for ALLOW FILTERING on virtual tables makes sense and would be quite useful 
for operators.That guard exists for performance issues that shouldn't occur on virtual tables. We also have a flag in case some future 
virtual table implementation has limitations regarding filtering, although it seems it's not the case with any of the existing virtual 
tables.It is not like we would promote bad habits because virtual tables are meant to be queried by operators / administrators only.It 
might even be quite the opposite, since in the current situation users might get used to routinely use ALLOW FILTERING for querying their 
virtual tables.It has been mentioned on the #cassandra-dev Slack thread where this started (1) that it's kind of an API inconsistency to 
allow querying by non-primary keys on virtual tables without ALLOW FILTERING, whereas it's required for regular tables. I think that a 
simply doc update saying that virtual tables, which are not regular tables, support filtering would be enough. Virtual tables are well 
identified by both the keyspace they belong to and doc, so users shouldn't have trouble knowing whether a table is virtual. It would be 
similar to the current exception for ALLOW FILTERING, where one needs to use it unless the table has an index for the queried column.(1) 
https://the-asf.slack.com/archives/CK23JSY2K/p1675352759267329On Fri, 3 Feb 2023 at 09:09, Miklosovic, Stefan 
 wrote:Hi list,the content of virtual tables is held in memory (and / or is fetched every time upon 
request). While doing queries against such table for a column outside of primary key, normally, users are required to specify ALLOW 
FILTERING. This makes total sense for "ordinary tables" for applications to have performant and effective queries but it kinds 
of loses the applicability for virtual tables when it literally holds just handful of entries in memory and it just does not matter, does 
it?What do you think about implicitly allowing filtering for virtual tables so we save ourselves from these pesky errors when we want to 
query arbitrary column and we need to satisfy CQL spec just to do that?It is not like we would promote bad habits because virtual tables 
are meant to be queried by operators / administrators only.We can also explicitly document this behavior.Among other options, we may try 
to implement secondary indices on virtual tables but I am not completely sure this is what we want because its complexity etc. Is it even 
necessary to put such complex logic in place just to be able to select any column on few entries in memory?I put together a draft here 
(1). It would be ever possible to implicitly allow filtering on virtual tables only and it would be implementator's responsibility to 
decide that, per table.For all virtual tables we currently have, I would enable this everywhere. I do not think there is any virtual 
table where we would not want to enable it or where people HAVE TO specify that.(1) https://github.com/apache/cassandra/pull/2131

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[C. Scott Andreas]

Josh and all PMC members, thank you for your work on this!Supportive of the changes 
and grateful to have scaffolding in place to accommodate current/incoming 
subprojects.– ScottOn Jan 26, 2023, at 1:21 PM, Josh McKenzie 
 wrote:The Cassandra PMC is pleased to announce that 
we're evolving our governance procedures to better foster subprojects under the 
Cassandra Ecosystem's umbrella. Astute observers among you may have noticed that the 
Cassandra Sidecar is already a subproject of Apache Cassandra as of CEP-1 
(https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224) and 
Cassandra-14395 (https://issues.apache.org/jira/browse/CASSANDRASC-24), however up 
until now we haven't had any structure to accommodate raising committers on specific 
subprojects or clarity on the addition or governance of future subprojects.

Further, with the CEP for the driver donation in motion 
(https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit#heading=h.xhizycgqxoyo),
 the need for a structured and sustainable way to expand the Cassandra 
Ecosystem is pressing.

We'll document these changes in the confluence wiki as well as the sidecar as 
our first formal subproject after any discussion on this email thread. The new 
governance process is as follows:
-

Subproject Governance
1. The Apache Cassandra PMC is responsible for governing the broad Cassandra 
Ecosystem.
2. The PMC will vote on inclusion of new interested subprojects using the 
existing procedural change vote process documented in the confluence wiki 
(Super majority voting: 66% of votes must be in favor to pass. Requires 50% 
participation of roll call).
3. New committers for these subprojects will be nominated and raised, both at inclusion as a subproject and over time. Nominations can be brought to priv...@cassandra.apache.org. Typically we're looking for a mix of commitment and contribution to the community and project, be it through code, documentation, presentations, or other significant engagement with the project. 
4. While the commit-bit is ecosystem wide, code modification rights and voting rights (technical contribution, binding -1, CEP's) are granted per subproject

4a. Individuals are trusted to exercise prudence and only commit or claim 
binding votes on approved subprojects. Repeated violations of this social 
contract will result in losing committer status.
4b. Members of the PMC have commit and voting rights on all subprojects.
5. For each subproject, the PMC will determine a trio of PMC members that will 
be responsible for all PMC specific functions (release votes, driving CVE 
response, marketing, branding, policing marks, etc) on the subproject.
-

Curious to see what thoughts we have as a community!

Thanks!

~Josh

Re: Cassandra Summit update for 2023-01-24

[C. Scott Andreas]

Hugely excited to this – thanks to the Program Committee and to the Linux Foundation 
for organizing!It's been a long few years away from conferences and I can't wait to 
see all of you.Beyond learning about what everyone is doing with Apache Cassandra, 
I'm looking forward to the hallway chats and discussion among smaller 
forums.Discussions at ApacheCon in 2019 helped hash out a plan to stabilize and ship 
4.0, and ApacheCon in 2022 led to a number of brainstorming sessions on how much 
better we can make Cassandra as features like distributed transactions, transactional 
metadata, storage-attached indexes, the BTI SSTable format, and more fall into 
place.If you or your company use Cassandra, the project's contributors would love to 
learn more about how - and how we can make it better. This conference is an awesome 
opportunity to catch up with contributors face to face. Always happy to discuss on 
the list and via Slack too, but glad this year allows us to resume events in 
person.Hope to see you there!– ScottOn Jan 24, 2023, at 4:54 PM, Patrick McFadin 
 wrote:Hello Cassandra Community!Quick take:- Register 
before 1/28 to get discount pricing. 
https://events.linuxfoundation.org/cassandra-summit/register/- Use code CS23DS20 to 
get 20% off- Make sure and sign up for training the day on March 12- Tell everyone 
you’re going on social media and use #CassandraSummit in your postsLonger version:If 
you have been watching what’s happening with the Cassandra Summit and thinking about 
going, I’m here to convince you that now is the time to register. The early 
registration discount ends this Saturday, January 28th. It might be helpful to 
clarify some misconceptions I keep hearing. Every other Cassandra Summit (except 
Cassandra Summit Tokyo) has been an event planned and run by DataStax. To create a 
more neutral ground that reflects our community better, Linux Foundation Events has 
taken on the considerable task of running Cassandra Summit in 2023. We are very 
grateful they took a chance on our community, and we will be better for it.When 
DataStax ran the event, we could deeply discount tickets because we treated it as a 
marketing expense. I’ve been DMed and Slacked quite a few times for free passes. 
Since this is a Linux Foundation event, unfortunately, there are no complimentary 
passes, as this is a key part of recouping their costs. You can get a 20% discount by 
using this code: CS23DS20Why is this important to mention? Our community needs an 
independent Cassandra Summit, and right now, it needs your support in attending the 
event. Let’s show the Linux Foundation that Cassandra Summit is something we value as 
a community. I know budgets are tight, and it’s hard to get approval. If you are 
able, make the case and register today. Next year when there are thousands of 
attendees at Cassandra Summit, you can tell everyone what they missed in 2023. If 
making the trip isn’t something you can do, a virtual pass is only $30 with the 
discount code and is also a great way to show support.The other important thing you 
can help with? Getting out the word about Cassandra Summit. Tell your colleagues and 
co-workers that this is a hot tip and you are hooking them up. If you are going, tell 
everyone you’ve registered and use the hashtag #CassandraSummit. Point out sessions 
you are interested in and share the love. If you can convince a couple of people to 
go, you’ve made a difference. If you need a little more motivation, just look at this 
schedule! 
https://events.linuxfoundation.org/cassandra-summit/program/schedule/Thanks, and I 
hope to see you there!Patrick

CircleCI Security Incident

[C. Scott Andreas]

FYI for visibility among our development community -

CircleCI reports they have experienced a security incident and are asking all 
users to immediately rotate any secrets stored in CircleCI (environment 
variables, object storage credentials, etc). They’re also recommending 
monitoring any internal systems for unauthorized access from December 21.

Details: https://circleci.com/blog/january-4-2023-security-alert/

— Scott

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

[C. Scott Andreas]

+1nbOn Dec 19, 2022, at 1:27 PM, Josh McKenzie  wrote:+1On Mon, Dec 19, 2022, at 11:54 AM, SAURABH VERMA wrote:+1On Mon, Dec 19, 2022 at 9:36 PM Benjamin Lerer  wrote:+1Le lun. 19 déc. 2022 
à 16:31, Andrés de la Peña  a écrit :+1On Mon, 19 Dec 2022 at 15:11, Aleksey Yeshchenko  wrote:+1On 19 Dec 2022, at 13:42, Ekaterina Dimitrova  wrote:+1On Mon, 
19 Dec 2022 at 8:30, J. D. Jordan  wrote:+1 nb> On Dec 19, 2022, at 7:07 AM, Brandon Williams  wrote:> > +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-- Thanks & Regards,Saurabh Verma, India

Re: Should we change 4.1 to G1 and offheap_objects ?

[C. Scott Andreas]

Jon, thanks for flagging that I didn't get a reply to your question on the thread.My main point in this thread is that I don't 
think post-beta is an appropriate time for a major prop change like this in the release cycle. Ideally at this point in the 
release cycle, major contributors and large users of Cassandra are running the build at minimum in pre-production environments, 
and hopefully in production environments too. Prop changes reset much of what's been learned by exercising the beta shortly 
before RC.Adding some detail on your question re: G1 – which mostly boils down to some experience to the contrary. I don't have 
data from past tests easily accessible to me, so I'm writing from memory and deductive reasoning here.The problem of garbage 
collection is minimizing a function of "memory overhead required to safely operate, program pause time, and CPU time 
burnt." ParNew+CMS are throughput-oriented collectors that commonly have higher throughput, lower CPU usage, and higher 
pause times than newer collectors like G1 and Shenandoah. This is a poor tradeoff for most applications.Cassandra is unique 
here: internode requests speculate, masking latency within cluster that can be incurred by the pause phase of a collection. The 
Java Driver is also great at speculating, masking latency of a coordinator that may be pausing for a collection as well. While 
ParNew+CMS are an objectively poor choice for many systems, Cassandra's architecture as a majority-quorum database that can 
speculate both at the client and coordinator level avoids the worst of those pitfalls.In cases where I and my colleagues have 
evaluated other collectors like G1 and Shenandoah, we've found lower pause times, ~unchanged or slightly higher client latency, 
and lower throughput. G1 testing may predate me, so I'll offer a more recent Shenandoah example. In a ~12-instance cluster that 
runs hot - averaging about 80% CPU - enabling Shenandoah resulted in about 5-10% lower request throughput after a couple days 
and a roughly equal increase in latency. While its micro-pause behavior was nice relative to ParNew's ~100-200ms pauses, it 
didn't make much of a difference due to internode and client speculation around it.Again, my point in this thread is that I 
wouldn't alter defaults on the eve of an RC in a release cycle. We do know this will need to change soon. CMS is gone in JDK17, 
so consider this email an elegy :). As part of JDK17 readiness, our collector defaults must change. If someone is interested in 
picking up the work, I think now would be a great time to perform that measurement and propose new defaults for the project 
based on it - and I don't even have an objection to those landing in a patchlevel release if the measurements look really 
good.But I wouldn't change the defaults on the eve of RC.– ScottOn Nov 17, 2022, at 7:26 AM, Joseph Lynch 
 wrote:I'm surprised we released 4.0 without changing the default to G1 giventhat many Cassandra 
deployments have changed the project's defaultbecause it is incorrect. I know that 7486 broke a user 7 years ago,but I think we 
have had a ton of testing since then in the communityto build our confidence. Not to mention that Java 9+ (released 2017)made G1 
the default and Java 14 (2020) removes CMS entirely.I have personally done targeted AB testing of G1GC vs CMS in acontrolled 
fashion using NDBench and our team had enough confidence in~2019 to roll it to Netflix's entire fleet of O(1k) clusters 
andO(10k) instances running Java 8. We found it vastly superior to CMS inpractically every way (no more 10s+ compacting STW 
phases after heapfragmentation, better tail latency at a coordinator/replica level,better average throughput, etc ...), and only 
identified a single veryminor p99 regression on one cluster (~5%) which we didn't considersevere enough to roll back.Right now 
our project defaults are hurting 99 users to help 1; letthat one user change the defaults? 4.1 seems like a great place to 
fixthe bug, absent being able to do that let's at least fix it in trunk?-JoeyOn Thu, Nov 17, 2022 at 8:27 AM Jon Haddad 
 wrote:I noticed nobody answered my actual question - what would it take for you to be 
comfortable?It seems that the need to do a release is now more important than the best interests of the new user's experience - 
despite having plenty of *production* experience showing that what we ship isn't even remotely close to usable.I tried to offer 
a compromise, and it's not cool with me that it was ignored by everyone objecting.JonOn 2022/11/17 08:34:53 Mick Semb Wever 
wrote:> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1>> We can revisit it for 4.1.x>> We have a lot of 
voices here adamantly positive for it, and those of us> that have done the performance testing over the years know why. But 
being> called to prove it is totally valid, if you have data to any such tests> please add them to the ticket 18027>

Re: Should we change 4.1 to G1 and offheap_objects ?

[C. Scott Andreas]

We have precedent for changing defaults that have near-universal positive 
impact in patchlevel releases, yep.

disk_access_mode: auto -> mmap_index_only comes to mind.

- Scott

> On Nov 16, 2022, at 6:49 PM, Derek Chen-Becker  wrote:
> 
> I'm fine with not including G1 in 4.1, but would we consider inclusion
> for 4.1.X down the road once validation has been done?
> 
> Derek
> 
> 
>> On Wed, Nov 16, 2022 at 4:39 PM David Capwell  wrote:
>> 
>> Getting poked in Slack to be more explicit in this thread…
>> 
>> Switching to G1 on trunk, +1
>> Switching to G1 on 4.1, -1.  4.1 is about to be released and this isn’t a 
>> bug fix but a perf improvement ticket and as such should go through 
>> validation that the perf improvements are seen, there is not enough time 
>> left for that added performance work burden so strongly feel it should be 
>> pushed to 4.2/5.0 where it has plenty of time to be validated against.  The 
>> ticket even asks to avoid validating the claims; saying 'Hoping we can skip 
>> due diligence on this ticket because the data is "in the past” already”'.  
>> Others have attempted both shenandoah and ZGC and found mixed results, so 
>> nothing leads me to believe that won’t be true here either.
>> 
 On Nov 16, 2022, at 9:15 AM, J. D. Jordan  
 wrote:
>>> 
>>> Heap -
>>> +1 for G1 in trunk
>>> +0 for G1 in 4.1 - I think it’s worthwhile and fairly well tested but I 
>>> understand pushback against changing this so late in the game.
>>> 
>>> Memtable -
>>> -1 for off heap in 4.1. I think this needs more testing and isn’t something 
>>> to change at the last minute.
>>> +1 for running performance/fuzz tests against the alternate memtable 
>>> choices in trunk and switching if they don’t show regressions.
>>> 
 On Nov 16, 2022, at 10:48 AM, Josh McKenzie  wrote:
 
 
 To clarify: -0 here on G1 as default for 4.1 as well; I'd like us to 
 prioritize digging into G1's behavior on small heaps vs. CMS w/our default 
 tuning sooner rather than later. With that info I'd likely be a strong +1 
 on the shift.
 
 -1 on switching to offheap_objects for 4.1 RC; again, think this is just a 
 small step away from being a +1 w/some more rigor around seeing the 
 current state of the technology's intersections.
 
 On Wed, Nov 16, 2022, at 7:47 AM, Aleksey Yeshchenko wrote:
> All right. I’ll clarify then.
> 
> -0 on switching the default to G1 *this late* just before RC1.
> -1 on switching the default offheap_objects *for 4.1 RC1*, but all for it 
> in principle, for 4.2, after we run some more test and resolve the 
> concerns raised by Jeff.
> 
> Let’s please try to avoid this kind of super late defaults switch going 
> forward?
> 
> —
> AY
> 
>> On 16 Nov 2022, at 03:27, Derek Chen-Becker  
>> wrote:
>> 
>> For the record, I'm +100 on G1. Take it with whatever sized grain of
>> salt you think appropriate for a relative newcomer to the list, but
>> I've spent my last 7-8 years dealing with the intersection of
>> high-throughput, low latency systems and their interaction with GC and
>> in my personal experience G1 outperforms CMS in all cases and with
>> significantly less work (zero work, in many cases). The only things
>> I've seen perform better *with a similar heap footprint* are GenShen
>> (currently experimental) and Rust (beyond the scope of this topic).
>> 
>> Derek
>> 
>> On Tue, Nov 15, 2022 at 4:51 PM Jon Haddad  
>> wrote:
>>> 
>>> I'm curious what it would take for folks to be OK with merging this 
>>> into 4.1?  How much additional time would you want to feel comfortable?
>>> 
>>> I should probably have been a little more vigorous in my +1 of Mick's 
>>> PR.  For a little background - I worked on several hundred clusters 
>>> while at TLP, mostly dealing with stability and performance issues.  A 
>>> lot of them stemmed partially or wholly from the GC settings we ship in 
>>> the project. Par New with CMS and small new gen results in a lot of 
>>> premature promotion leading to high pause times into the hundreds of ms 
>>> which pushes p99 latency through the roof.
>>> 
>>> I'm a big +1 in favor of G1 because it's not just better for most 
>>> people but it's better for _every_ new Cassandra user.  The first 
>>> experience that people have with the project is important, and our 
>>> current GC settings are quite bad - so bad they lead to problems with 
>>> stability in production.  The G1 settings are mostly hands off, result 
>>> in shorter pause times and are a big improvement over the status quo.
>>> 
>>> Most folks don't do GC tuning, they use what we supply, and what we 
>>> currently supply leads to a poor initial experience with the database.  
>>> I think we owe the community our best effort even if it means pushing 
>>> 

Re: Should we change 4.1 to G1 and offheap_objects ?

[C. Scott Andreas]

I share David and Aleksey’s views on this.

We shouldn’t make major defaults changes right before RC. Might be worth adding 
a release note recommending users try them, and that they may become default in 
a future release though.

— Scott

> On Nov 16, 2022, at 3:38 PM, David Capwell  wrote:
> 
> Getting poked in Slack to be more explicit in this thread… 
> 
> Switching to G1 on trunk, +1
> Switching to G1 on 4.1, -1.  4.1 is about to be released and this isn’t a bug 
> fix but a perf improvement ticket and as such should go through validation 
> that the perf improvements are seen, there is not enough time left for that 
> added performance work burden so strongly feel it should be pushed to 4.2/5.0 
> where it has plenty of time to be validated against.  The ticket even asks to 
> avoid validating the claims; saying 'Hoping we can skip due diligence on this 
> ticket because the data is "in the past” already”'.  Others have attempted 
> both shenandoah and ZGC and found mixed results, so nothing leads me to 
> believe that won’t be true here either.
> 
>> On Nov 16, 2022, at 9:15 AM, J. D. Jordan  wrote:
>> 
>> Heap -
>> +1 for G1 in trunk
>> +0 for G1 in 4.1 - I think it’s worthwhile and fairly well tested but I 
>> understand pushback against changing this so late in the game.
>> 
>> Memtable -
>> -1 for off heap in 4.1. I think this needs more testing and isn’t something 
>> to change at the last minute.
>> +1 for running performance/fuzz tests against the alternate memtable choices 
>> in trunk and switching if they don’t show regressions.
>> 
 On Nov 16, 2022, at 10:48 AM, Josh McKenzie  wrote:
>>> 
>>> 
>>> To clarify: -0 here on G1 as default for 4.1 as well; I'd like us to 
>>> prioritize digging into G1's behavior on small heaps vs. CMS w/our default 
>>> tuning sooner rather than later. With that info I'd likely be a strong +1 
>>> on the shift.
>>> 
>>> -1 on switching to offheap_objects for 4.1 RC; again, think this is just a 
>>> small step away from being a +1 w/some more rigor around seeing the current 
>>> state of the technology's intersections.
>>> 
>>> On Wed, Nov 16, 2022, at 7:47 AM, Aleksey Yeshchenko wrote:
 All right. I’ll clarify then.
 
 -0 on switching the default to G1 *this late* just before RC1.
 -1 on switching the default offheap_objects *for 4.1 RC1*, but all for it 
 in principle, for 4.2, after we run some more test and resolve the 
 concerns raised by Jeff.
 
 Let’s please try to avoid this kind of super late defaults switch going 
 forward?
 
 —
 AY
 
> On 16 Nov 2022, at 03:27, Derek Chen-Becker  wrote:
> 
> For the record, I'm +100 on G1. Take it with whatever sized grain of
> salt you think appropriate for a relative newcomer to the list, but
> I've spent my last 7-8 years dealing with the intersection of
> high-throughput, low latency systems and their interaction with GC and
> in my personal experience G1 outperforms CMS in all cases and with
> significantly less work (zero work, in many cases). The only things
> I've seen perform better *with a similar heap footprint* are GenShen
> (currently experimental) and Rust (beyond the scope of this topic).
> 
> Derek
> 
> On Tue, Nov 15, 2022 at 4:51 PM Jon Haddad  
> wrote:
>> 
>> I'm curious what it would take for folks to be OK with merging this into 
>> 4.1?  How much additional time would you want to feel comfortable?
>> 
>> I should probably have been a little more vigorous in my +1 of Mick's 
>> PR.  For a little background - I worked on several hundred clusters 
>> while at TLP, mostly dealing with stability and performance issues.  A 
>> lot of them stemmed partially or wholly from the GC settings we ship in 
>> the project. Par New with CMS and small new gen results in a lot of 
>> premature promotion leading to high pause times into the hundreds of ms 
>> which pushes p99 latency through the roof.
>> 
>> I'm a big +1 in favor of G1 because it's not just better for most people 
>> but it's better for _every_ new Cassandra user.  The first experience 
>> that people have with the project is important, and our current GC 
>> settings are quite bad - so bad they lead to problems with stability in 
>> production.  The G1 settings are mostly hands off, result in shorter 
>> pause times and are a big improvement over the status quo.
>> 
>> Most folks don't do GC tuning, they use what we supply, and what we 
>> currently supply leads to a poor initial experience with the database.  
>> I think we owe the community our best effort even if it means pushing 
>> the release back little bit.
>> 
>> Just for some additional context, we're (Netflix) running 25K nodes on 
>> G1 across a variety of hardware in AWS with wildly varying workloads, 
>> and I haven't seen G1 be the root cause of a problem 

Re: CASSANDRA-14227 removing the 2038 limit

[C. Scott Andreas]

A 2-3% increase in storage volume is roughly equivalent to giving up the gain from LZ4 -> LZ4HC, or a one to two-level bump in Zstandard compression levels. This regression could be very expensive for storage-bound use cases.From the perspective of storage overhead, the unsigned int approach sounds preferable.On Nov 13, 2022, at 10:13 PM, Berenguer Blasi  wrote:
  

  
  
Hi all,

We have done some more research on c14227. The current patch for
  CASSANDRA-14227 solves the TTL limit issue by switching TTL to
  long instead of int. This approach does not have a negative impact
  on memtable memory usage, as C* controles the memory used by the
  Memtable, but based on our testing it increases the bytes flushed
  by 4 to 7% and the byte on disk by 2 to 3%.

As a mitigation to this problem it is possible to encode localDeletionTime as a vint. It
  results in a 1% improvement but might cause additional
  computations during compaction or some other operations.

Benedict's proposal to keep on using ints for TTL but as a delta
  to nowInSecond would work for memtables but not for work in the
  SSTable where nowInSecond does not exist. By consequence we would
  still suffer from the impact on byte flushed and bytes on disk.

Another approach that was suggested is the use of unsigned
  integer. Java 8 has an unsigned integer API that would allow us to
  use unsigned int for TTLs. Based on computation unsigned ints
  would give us a maximum time of 136 years since the Unix Epoch and
  therefore a maximum expiration timestamp in 2106. We would have to
  keep TTL at 20y instead of 68y to give us enough breathing room
  though, otherwise in 2035 we'd hit the same problem again.
Happy to hear opinions.
On 18/10/22 10:56, Berenguer Blasi
  wrote:


  
  Hi,
  apologies for the late reply as I have been OOO. I have done
some profiling and results look virtually identical on trunk and
14227. I have attached some screenshots to the ticket https://issues.apache.org/jira/browse/CASSANDRA-14227.
Unless my eyes are fooling me everything in the jfrs look the
same.
  Regards
  
  On 30/9/22 9:44, Berenguer Blasi
wrote:
  
  

Hi Benedict,
thanks for the reply! Yes some profiling is probably needed,
  then we can see if going down the delta encoding big refactor
  rabbit hole is worth it?

Let's see what other concerns people bring up.
Thx.

On 29/9/22 11:12, Benedict Elliott
  Smith wrote:


  
  My only slight concern with this approach is
the additional memory pressure. Since 64yrs should be plenty
at any moment in time, I wonder if it wouldn’t be better to
represent these times as deltas from the nowInSec being used
to process the query. So, long math would only be used to
normalise the times to this nowInSec (from whatever is
stored in the sstable) within a method, and ints would be
stored in memtables and any objects used for processing.


This
  might admittedly be more work, but I don’t believe it
  should be too challenging - we can introduce a method
  deletionTime(int nowInSec) that returns a long value by
  adding nowInSec to the deletionTime, and make the
  underlying value private, refactoring call sites?

  
On 29 Sep 2022, at 09:37, Berenguer Blasi 
  wrote:


  Hi all,

I have taken a stab in a PR you can find attached in
the ticket. Mainly:

- I have moved deletion times, gc and nowInSec
timestamps to long. That should get us past the 2038
limit.

- TTL is maxed now to 68y. Think CQL API
compatibility and a sort of a 'free' guardrail.

- A new NONE overflow policy is the default but
everything is backwards compatible by keeping the
previous ones in place. Think upgrade scenarios or
apps relying on the previous behavior.

- The new limit is around year 292,471,208,677 which
sounds ok given the Sun will start collapsing in 3
to 5 billion years :-)

- Please feel free to drop by the ticket and take a
look at the PR even if it's cursory

Thx in advance.
  

Re: [VOTE] Release Apache Cassandra 4.0.7

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:06 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 4.0.7 for release.
>> 
>> sha1: 277fa4fca4a80eb327be6559f993c91e42dd4009
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.7-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1279/org/apache/cassandra/cassandra-all/4.0.7/
>> 
>> 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.7/
>> 
>> 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.7-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.7-tentative

Re: [VOTE] Release Apache Cassandra 3.11.14

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:05 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 3.11.14 for release.
>> 
>> sha1: 9d3327ef1321fe1bf4e7fc73ed6111da7c994553
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.14-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1278/org/apache/cassandra/cassandra-all/3.11.14/
>> 
>> 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.14/
>> 
>> 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.14-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.14-tentative

Re: [VOTE] Release Apache Cassandra 3.0.28

[C. Scott Andreas]

+1nb

— Scott

> On Oct 21, 2022, at 4:04 AM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Wed, Oct 19, 2022 at 4:41 AM Mick Semb Wever  wrote:
>> 
>> 
>> Proposing the test build of Cassandra 3.0.28 for release.
>> 
>> sha1: 96c5332ee15f45ca5410caaa787cc88d6947b3c9
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.28-tentative
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachecassandra-1277/org/apache/cassandra/cassandra-all/3.0.28/
>> 
>> 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.28/
>> 
>> 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.0.28-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.28-tentative

Re: Cassandra Token ownership split-brain (3.0.14)

[C. Scott Andreas]

Hi Jaydeep,Thanks for reaching out and for bumping this thread.This is probably not the answer you’re after, but mentioning as it may address the issue.C* 3.0.14 was released over five years ago, with many hundreds of important bug fixes landing since July 2017. These include fixes for issues that have affected gossip in the past which may be related to this issue. Note that 3.0.14 also is susceptible to several critical data loss bugs including C-14513 and C-14515.I’d strongly recommend upgrading to Cassandra 3.0.27 as a starting point. If this doesn’t resolve your issue, members of the community may be in a better position to help triage a bug report against a current release of the database.- ScottOn Sep 6, 2022, at 5:13 PM, Jaydeep Chovatia  wrote:If anyone has seen this issue and knows a fix, it would be a great help! Thanks in advance.JaydeepOn Fri, Sep 2, 2022 at 1:56 PM Jaydeep Chovatia  wrote:Hi,We are running a production Cassandra version (3.0.14) with 256 tokens v-node configuration. Occasionally, we see that different nodes show different ownership for the same key. Only a node restart corrects; otherwise, it continues to behave in a split-brain.Say, for example, NodeAnodetool getendpoints ks1 table1 10- n1- n2- n3NodeBnodetool getendpoints ks1 table1 10- n1- n2- n5If I restart NodeB, then it shows the correct ownership {n1,n2,n3}. The majority of the nodes in the ring show correct ownership {n1,n2,n3}, only a few show this issue, and restarting them solves the problem.To me, it seems I think Cassandra's Gossip cache and StorageService cache (TokenMetadata) are having some sort of cache coherence.Anyone has observed this behavior? Any help would be highly appreciated.Jaydeep

Re: [VOTE] Release Apache Cassandra 4.0.6

[C. Scott Andreas]

+1nbOn Aug 22, 2022, at 8:55 AM, Mick Semb Wever  wrote: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.+1Checked- signing correct- 
checksums are correct- source artefact builds- binary artefact runs- debian package 
runs- redhat package runs 

Re: [DISCUSS] Remove Dead Pull Requests

[C. Scott Andreas]

Claude, can you say more about the goal or purpose that closing tickets 
advances?

There are quite a lot of tickets with patches attached that the project has 
either not been able to act on at the time; or which the original contributor 
started but was unable to complete. We’ve picked up many of these after a 
couple years and carried them to completion. Byte-comparable types come to 
mind. There are many, many more.

Closing these tickets would be a very terminal action. If the goal is to 
distinguish what’s active from tickets that have gone quiet, adding a “dormant” 
label might work.

- Scott

> On Aug 10, 2022, at 1:00 AM, Claude Warren, Jr via dev 
>  wrote:
> 
> 
> At the moment we have 222 open pull requests.  Some dating back 4 years.  For 
> some the repository from which they were pulled from has been deleted.  For 
> many there are branch conflicts.
> 
> Now, I am new here so please excuse any misstatements and attribute to 
> ignorance not malice any offence.
> 
> I would like to propose the  following:
> 
> We accept simple typo corrections without a ticket.
> Add a "Propose Close" label
> We "Propose Close" any pull request for which the originating repository has 
> been deleted.
> We "Propose Close" any ticket, other than simple typo corrections, that has 
> been labeled missing-ticket for more than 30 days.
> We Close any pull request that has been in the "Propose Close" state for more 
> than 30 days.
> I don't have access to make any of these changes.  If granted access I would 
> be willing to manage the process.
> 
> Claude
> 

Re: [DISCUSS] Improve Commitlog write path

[C. Scott Andreas]

Amit, welcome and thank you for contributing the results from your test and opening this discussion.I don’t think anyone is arguing that the database shouldn’t take advantage of available hardware.A few things important to keep in mind when considering a patch like this:- Where the actual bottleneck in the database will be for increased write throughput. As Bowen and Benedict mentioned, the amount of work performed by the commitlog versus the accrued cost of integrating flushed SSTables into the LSM tree is dramatically weighed toward compaction. A multi-day benchmark that allows the database to accrue and incorporate a sizable amount of data is much more likely to produce measurements that approximate what users of Cassandra may experience in production use.- Making something multi-threaded doesn’t reduce the amount of work done; it redistributes it. In a saturated system, this means resources are allocated in an environment of trade offs. Allocating additional resources to the front door will reduce the resources available to compaction, live serving, etc. in environments where cores are not limitless and free. This is why the holistic view of performance others are speaking to is important.- How such a change alters the balance of the database’s threading model, and where the bottleneck moved to. Users who overrun the commitlog’s capability today are likely to be even more negatively impacted by compaction overhead of backpressure is lost at the front door. The meta-point to consider is “how does this change affect the performance characteristics of a live database?”- We also need to balance complexity and correctness in the implementation. If the patch is straightforward, has a well-defined locking scheme, and ideally a suite of randomized tests, that can help mitigate concerns related to this.It sounds like several would welcome such a patch for review. Just want to signpost that the gains and tradeoffs aren’t always clear cut, especially in cases where the improvement is a rebalancing of the database’s threading model rather than reducing the amount of work performed.The second item you mentioned - a direct IO path for commitlog writes - sounds like an interesting potential addition.One thing that may be useful to post along with your patch is a result from an extended tlp-stress run that includes both the live write path as well as the deferred compaction of data written.- ScottOn Jul 22, 2022, at 9:14 AM, Pawar, Amit  wrote:







[AMD Official Use Only - General]
 
Hi Benedict,
 
The whole point is Cassandra as a software should take advantage of hardware wherever possible. So reducing Commitlog bottleneck may help some workloads and not all. I am already working on trunk now and will share the patch. If changes
 looks good and not very complex then please give your feedback. Your input might help to reduce the complexity of change and possibly patch can be accepted.
 
Thanks,
Amit
 


From: Benedict 

Sent: Friday, July 22, 2022 3:56 PM
To: dev@cassandra.apache.org
Cc: Bowen Song ; Raghavendra, Prakash 
Subject: Re: [DISCUSS] Improve Commitlog write path


 
[CAUTION: External Email] 


Hi Amit,


 


I am inclined to agree with Bowen Song, in that benchmarks from an initially empty cluster tend to lean more heavily on memtable and commit log bottlenecks than a real-world long running cluster does, as the algorithmic
 complexity of LSMTs begin to bite much later while the cost of the commit log and memtable stay fairly constant. The more data you have, the less commit log and memtable performance directly matter, and memtable size becomes much more important along
 with compaction efficiency.


 


That said, reducing bottlenecks is still a good thing if the additional complexity is not severe - and this is still an unfortunately common way that
 we benchmark changes today, anyway.

 


 


On 22 Jul 2022, at 11:20, Pawar, Amit  wrote:




 

[Public]
 
Thank you Bowen for your reply. Took some time to respond due to testing issue.
 
I tested again multi-threaded feature with number of records from 260 million to 2 billion and still improvement is seen around 80% of Ramdisk score. It is still possible that compaction can become new bottleneck
 and could be new opportunity to fix it. I am newbie here and possible that I failed to understand your suggestion completely.  At-least with this testing multi-threading benefit is reflecting in score.

 
Do you think multi-threading is good to have now ? else please suggest if I need to test further.
 
Thanks,
Amit
 


From: Bowen Song via dev 

Sent: Wednesday, July 20, 2022 4:13 PM
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Improve Commitlog write path


 
[CAUTION: External Email] 

From my past experience, the bottleneck for insert heavy workload is likely to be compaction, not commit log. You initially may see commit log as the bottleneck when the table size is relatively small, but as the 

Re: Welcome Jacek Lewandowski as Cassandra committer

[C. Scott Andreas]

Congratulations, Jacek!On Jul 6, 2022, at 7:38 AM, Mick Semb Wever  
wrote:Congrats Jacek! On Wed, 6 Jul 2022 at 15:00, Ekaterina Dimitrova  
wrote:Well deserved, congrats!  On Wed, 6 Jul 2022 at 8:56, Brandon Williams  
wrote:Congrats!On Wed, Jul 6, 2022, 7:00 AM Benjamin Lerer  wrote:The PMC 
members are pleased to announce that  Jacek Lewandowski


has accepted the invitation to become committer.  Thanks a lot, Jacek,  for 
everything you have done!Congratulations and welcomeThe Apache Cassandra PMC 
members 

Re: [VOTE] Release Apache Cassandra 4.1-alpha1

[C. Scott Andreas]

+1nb

> On May 26, 2022, at 10:21 PM, Berenguer Blasi  
> wrote:
> 
> 
> +1 nb
> 
> On 26/5/22 16:25, Ekaterina Dimitrova wrote:
>> +1 (nb)
>> 
>> On Tue, 24 May 2022 at 11:37, Andrés de la Peña  wrote:
>>> +1 nb
>>> 
>>> On Tue, 24 May 2022 at 16:10, Benjamin Lerer  wrote:
 +1
 
 Le mar. 24 mai 2022 à 16:19, Josh McKenzie  a écrit :
> +1
> 
> On Tue, May 24, 2022, at 10:13 AM, Brandon Williams wrote:
>> +1
>> 
>> On Tue, May 24, 2022 at 3:39 AM Mick Semb Wever  wrote:
>> >
>> > Proposing the test build of Cassandra 4.1-alpha1 for release.
>> >
>> > sha1: 6f05be447073925a7f3620ddbbd572aa9fcd10ed
>> > Git: 
>> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1-alpha1-tentative
>> > Maven Artifacts:
>> > https://repository.apache.org/content/repositories/orgapachecassandra-1273/org/apache/cassandra/cassandra-all/4.1-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/4.1-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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.1-alpha1-tentative
>> > [2]: NEWS.txt: 
>> > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1-alpha1-tentative
>> 

Re: Appetite for a 4.1-alpha1 ?

[C. Scott Andreas]

Yep, supportive of anything that has the potential to increase the number of users evaluating a pre-release build. Alpha sounds great.On May 18, 
2022, at 9:29 AM, David Capwell  wrote:Works for meOn May 18, 2022, at 7:36 AM, Josh McKenzie  
wrote:+1 from me on the grounds that I expect users to be more inclined to test an alpha build of 4.1 rather than finding and pulling down a 
nightly. Expectations of stability differ.On Wed, May 18, 2022, at 10:18 AM, Stefan Miklosovic wrote:Hi Mick,I do not mind having alpha1 out. It 
will help me with setting up allbuild pipelines for our plugins / tools / libraries as now I can notbuild it as snapshot is not released anywhere 
nor I can depend on itin Maven projects, for example.So yeah, +1 from me.RegardsOn Wed, 18 May 2022 at 11:40, Mick Semb Wever 
 wrote:>> Our release lifecycle docs¹ imply that we can release alphas despite> flaky test failures, which means we 
can cut and vote on a 4.1-alpha1> release today. This is also on the presumption that point (2) on our> Cassandra CI Process docs² does not 
apply to pre-beta releases.>> Is there an appetite for this?> Any objections?> Any tickets about to land folk want us to wait 
on?>> regards,> Mick>>> 1) https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle>> 2) 
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+CI+Process

Re: [VOTE] Release Apache Cassandra 3.11.13

[C. Scott Andreas]

+1nb

> On May 9, 2022, at 5:24 PM, Mick Semb Wever  wrote:
> 
> 
>> 
>> > 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
> 
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - redhat package runs 

Re: [VOTE] Release Apache Cassandra 4.0.4

[C. Scott Andreas]

+1nb

> On May 5, 2022, at 9:49 AM, Brandon Williams  wrote:
> 
> +1
> 
> Also passed dependency-check
> 
> Kind Regards,
> Brandon
> 
>> On Wed, May 4, 2022 at 9:33 AM Mick Semb Wever  wrote:
>> 
>> Proposing the test build of Cassandra 4.0.4 for release.
>> 
>> sha1: d4dbc932bf415e0ca17c43289147e7733c67d6ab
>> Git: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1266/org/apache/cassandra/cassandra-all/4.0.4/
>> 
>> 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.4/
>> 
>> 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.4-tentative
>> [2]: NEWS.txt: 
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative

Re: [VOTE] Release Apache Cassandra 3.0.27

[C. Scott Andreas]

+1, with special attention to CASSANDRA-14752 - didn’t realize we hadn’t 
released a build with a resolution for this yet.

> On May 9, 2022, at 5:23 PM, Mick Semb Wever  wrote:
> 
> 
>> 
>> > 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
> 
> Checked
> - signing correct
> - checksums are correct
> - source artefact builds
> - binary artefact runs
> - debian package runs
> - redhat package runs
>  

Re: [VOTE] Release dtest-api 0.0.13

[C. Scott Andreas]

+1nbOn Mar 31, 2022, at 10:21 AM, Dinesh Joshi  wrote:+1On Mar 31, 2022, 
at 10:04 AM, David Capwell  wrote:+1On Mar 31, 2022, at 9:53 AM, Alex 
Petrov  wrote:Proposing the test build of in-jvm dtest API 0.0.13 for 
release.Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.13Candidate
 
SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/05f4990e91583c2860356804c6945686968c05b5
 tagged with 
0.0.13Artifacts:https://repository.apache.org/content/repositories/orgapachecassandra-1260/org/apache/cassandra/dtest-api/0.0.13/Key
 signature: A4C465FEA0C552561A392A61E91335D77E3E87CBChanges since last release: * 
CASSANDRA-17332: Renamed isAllowVnodes and disallowVNodes to allow more control over when vnode 
or single token are supported (#32) * CASSANDRA-17332: Add support for vnodes in jvm-dtestThe 
vote will be open for 24 hours. Everyone who has tested the buildis invited to vote. Votes by PMC 
members are considered binding. Avote passes if there are at least three binding +1s.

Re: [DISSCUSS] Cassandra and Java 17

[C. Scott Andreas]

Ekaterina, thank you very much for sharing this!

I admit, it’s much more involved than I expected to be.

The —add-opens and —add-exports flags seem suitable for development and perhaps 
experimental support, but we’ll probably want to make changes to remove as many 
as we can before considering JDK17 suitable for general use.

Updating dependencies will be good for general hygiene, but it would also be 
important for us to scan changelogs for the intervening versions of each we’re 
upgrading to flag any unexpected behavior changes that may impact Cassandra or 
which the community might want to know about.

Thank you for working to get Cassandra launching on JDK17. Excited for what’s 
ahead.

— Scott

> On Mar 23, 2022, at 7:58 AM, Ekaterina Dimitrova  
> wrote:
> 
> 
> Hi everyone,
> 
> Looking into our way to Java 17, I wanted to share with the community 
> findings/thoughts and align on course of action.
> 
> We already deprecated scripted UDFs so we can remove them when the time to 
> switch from Java8&11 to Java 11&17 comes. I removed the ant script tasks and 
> created custom ant tasks to workaround the need of Nashorn. Ant is also 
> upgraded now on trunk.
> 
> With this Cassandra trunk compiles with warnings about the Security manager 
> being deprecated and other security deprecation warnings(I mention it for 
> awareness here).
> I pushed to my personal docker hub account a version of our testing image 
> that has Java 17 installed and I worked on the build file, shell scripts and 
> config to push testing with Java 17 to CircleCI.
> 
> To just start Cassandra out of the box on Java 17 we also need as a least 
> minimum to add the following, further to what we already open in Java 11:
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED
> --add-opens java.base/java.util.concurrent=ALL-UNNAMED
> --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED
> --add-opens java.base/java.nio=ALL-UNNAMED
> --add-opens java.base/java.lang=ALL-UNNAMED
> 
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports java.base/java.io=ALL-UNNAMED
> --add-exports java.base/java.util.concurrent=ALL-UNNAMED
> --add-exports java.base/java.util=ALL-UNNAMED
> --add-exports java.base/java.util.concurrent.atomic=ALL-UNNAMED
> --add-exports java.base/java.nio=ALL-UNNAMED
> --add-exports java.base/java.lang=ALL-UNNAMED
> 
> This is a quick run of jdeps -jdkinternals --multi-release 17 
> apache-cassandra-4.1-SNAPSHOT.jar.: 
>apache-cassandra-4.1-SNAPSHOT.jar -> java.rmi
>apache-cassandra-4.1-SNAPSHOT.jar -> jdk.unsupported
>org.apache.cassandra.io.util.Memory-> sun.misc.Unsafe  
>   JDK internal API (jdk.unsupported)
>org.apache.cassandra.utils.FastByteOperations$UnsafeOperations -> 
> sun.misc.UnsafeJDK internal API 
> (jdk.unsupported)
>org.apache.cassandra.utils.FastByteOperations$UnsafeOperations$1 -> 
> sun.misc.UnsafeJDK internal API 
> (jdk.unsupported)
>org.apache.cassandra.utils.JMXServerUtils$JmxRegistry -> 
> sun.rmi.registry.RegistryImpl  JDK internal API (java.rmi)
>org.apache.cassandra.utils.memory.MemoryUtil   -> sun.misc.Unsafe  
>   JDK internal API (jdk.unsupported)
> 
> Warning: JDK internal APIs are unsupported and private to JDK implementation 
> that are
> subject to be removed or changed incompatibly and could break your 
> application.
> Please modify your code to eliminate dependence on any JDK internal APIs.
> For the most recent update on JDK internal API replacements, please check: 
> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
> 
> Also a quick workaround I applied for test purposes in order to be able to 
> run the in-jvm tests can be seen here[4], and I assume something like that is 
> also needed for the simulator and other places which I went ahead and changed 
> in order just to unblock the preliminary testing so we can get the full 
> picture. To be revised later.
> This was the issue we were hitting:
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
>   at 
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$11(Instance.java:691)
>   at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
>   at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
>   at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:833)
> 

Re: [VOTE] CEP-7: Storage Attached Index

[C. Scott Andreas]

+1nbOn Feb 17, 2022, at 2:37 PM, J. D. Jordan  wrote:+1 nbOn Feb 
17, 2022, at 4:25 PM, Brandon Williams  wrote:+1On Thu, Feb 17, 2022 at 
4:23 PM Caleb Rackliffe wrote:Hi everyone,I'd like to call a vote 
to approve CEP-7.Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+IndexDiscussion: 
https://lists.apache.org/thread/hh67k3t86m7299qkt61gmzb4h96bl90wThe 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.Thanks!Caleb

Re: [VOTE] CEP-19: Trie memtable implementation

[C. Scott Andreas]

+1nb

> On Feb 16, 2022, at 5:59 AM, Jeremy Hanna  wrote:
> 
> +1 nb.  Thanks for all of the great work on this Branimir.  Excited to see 
> this moving forward.
> 
>> On Feb 16, 2022, at 7:56 AM, J. D. Jordan  wrote:
>> 
>> +1 nb
>> 
 On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
 
>>> 
>>> +1
>>> 
 On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
 +1nb
 
 On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
 +1
 
 On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov  wrote:
 >
 > Hi everyone,
 >
 > I'd like to propose CEP-19 for approval.
 >
 > Proposal: 
 > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
 > Discussion: 
 > https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
 >
 > 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: [VOTE] release cassandra-harry 0.0.1

[C. Scott Andreas]

+1nb

> On Feb 8, 2022, at 4:18 AM, Brandon Williams  wrote:
> 
> +1
> 
>> On Mon, Feb 7, 2022 at 8:44 AM Alex Petrov  wrote:
>> 
>> Proposing the test build of cassandra-harry 0.0.1 for release, to start 
>> using it in Cassandra tree.
>> 
>> Repository:
>> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1
>> 
>> Candidate SHA:
>> https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e2894266
>> tagged with 0.0.1
>> 
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1257/org/apache/cassandra/
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> This is a first release of harry-core, but you can read more about its 
>> integration with Cassandra in CASSANDRA-16262:
>> 
>> 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 3.11.12

[C. Scott Andreas]

Hi Dorian,I see that the following download URLs appear to work fine for me and result in the 
tarballs being downloaded as expected.– 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-src.tar.gz– 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gzAs 
Alex mentioned, to help the community debug and ensure a high quality release - in a JIRA ticket, 
could you please share specific steps to reproduce the issues you're encountering as well as any 
error messages you receive?We would like to resolve these concerns as quickly as 
possible.Thanks,– ScottOn Feb 7, 2022, at 1:11 PM, Dorian ROSSE  
wrote:-1 I don't success to download it I fall on index.htmlDe : Mick Semb Wever 
 Envoyé : lundi 7 février 2022 15:14 À : dev 
 Objet : [VOTE] Release Apache Cassandra 3.11.12  Proposing the 
test build of Cassandra 3.11.12 for release.  sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faaGit: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative 
Maven Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
  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.12/  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.12-tentative
 [2]: NEWS.txt:  
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [DISCUSS] CEP-19: Trie memtable implementation

[C. Scott Andreas]

Branimir, thank you for sharing these results. 

The numbers are exciting - particularly the UCS test in which compaction keeps 
up, and your note mentioning 30% larger L0 flushes due to the more compact 
memory representation.

Great work.

— Scott

> On Feb 7, 2022, at 8:39 AM, Branimir Lambov  wrote:
> 
> 
> Added some performance results to the ticket: 
> https://issues.apache.org/jira/browse/CASSANDRA-17240
> 
> Regards,
> Branimir
> 
>> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi  wrote:
>> This is excellent. Thanks for opening up this CEP. It would be great to get 
>> some stats around GC allocation rate / memory pressure, read & write 
>> latencies, etc. compared to existing implementation.
>> 
>> Dinesh
>> 
>>> On Jan 18, 2022, at 2:13 AM, Branimir Lambov  wrote:
>>> 
>>> The memtable pluggability API (CEP-11) is per-table to enable memtable 
>>> selection that suits specific workflows. It also makes full sense to permit 
>>> per-node configuration, both to be able to modify the configuration to suit 
>>> heterogeneous deployments better, as well as to test changes for 
>>> improvements such as this one.
>>> Recognizing this, the patch comes with a modification to the API that 
>>> defines memtable templates in cassandra.yaml (i.e. per node) and allows the 
>>> schema to select a template (in addition to being able to specify the full 
>>> memtable configuration). One could use this e.g. by adding:
>>> memtable_templates:
>>> trie:
>>> class: TrieMemtable
>>> shards: 16
>>> skiplist:
>>> class: SkipListMemtable
>>> memtable:
>>> template: skiplist
>>> (which defines two templates and specifies the default memtable 
>>> implementation to use) to cassandra.yaml and specifying  WITH memtable = 
>>> {'template' : 'trie'} in the table schema.
>>> 
>>> I intend to commit this modification with the memtable API 
>>> (CASSANDRA-17034/CEP-11).
>>> 
>>> Performance comparisons will be published soon.
>>> 
>>> Regards,
>>> Branimir
>>> 
 On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa  wrote:
 Sounds like a great addition
 
 Can you share some of the details around gc and latency improvements 
 you’ve observed with the list? 
 
 Any specific reason the confirmation is through schema vs yaml? Presumably 
 it’s so a user can test per table, but this changes every host in a 
 cluster, so the impact of a bug/regression is much higher. 
 
 
>> On Jan 10, 2022, at 1:30 AM, Branimir Lambov  wrote:
>> 
> 
> We would like to contribute our TrieMemtable to Cassandra. 
> 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> 
> This is a new memtable solution aimed to replace the legacy 
> implementation, developed with the following objectives:
> - lowering the on-heap complexity and the ability to store memtable 
> indexing structures off-heap,
> - leveraging byte order and a trie structure to lower the memory 
> footprint and improve mutation and lookup performance.
> 
> The new memtable relies on CASSANDRA-6936 to translate to and from 
> byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to 
> plug into Cassandra. The memtable is built on multiple shards of custom 
> in-memory single-writer multiple-reader tries, whose implementation uses 
> a combination of state-of-the-art and novel features for greater 
> efficiency.
> 
> The CEP's JIRA ticket 
> (https://issues.apache.org/jira/browse/CASSANDRA-17240) contains the 
> initial version of the implementation. In its current form it achieves 
> much better garbage collection latency, significantly bigger data sizes 
> between flushes for the same memory allocation, as well as drastically 
> increased write throughput, and we expect the memory and garbage 
> collection improvements to go much further with upcoming improvements to 
> the solution.
> 
> I am interested in hearing your thoughts on the proposal.
> 
> Regards,
> Branimir
> 
>> 

Re: [VOTE] Release Apache Cassandra 3.0.26

[C. Scott Andreas]

+1nbOn Feb 7, 2022, at 6:14 AM, Mick Semb Wever  
wrote:Proposing the test build of Cassandra 3.0.26 for release.sha1: 
b18adcba1a808cf77576905dc2ceccd7783bdb18Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentativeMaven
 Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/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.26/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.0.26-tentative[2]:
 NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[C. Scott Andreas]

+1nbOn Feb 7, 2022, at 6:15 AM, Mick Semb Wever  
wrote:Proposing the test build of Cassandra 4.0.2 for release.sha1: 
25012d2fec1984cc9c1a352f214eb912ca4f10f5Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentativeMaven
 Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.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.0.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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative[2]:
 NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Re: UDF future

[C. Scott Andreas]

I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an 
interface for those who would like to supply a UDF implementation; and to 
extract/remove our current implementation.

JDK17 support seems like a much higher priority than in-tree JS UDFs.

— Scott

> On Jan 18, 2022, at 8:30 AM, Ekaterina Dimitrova  
> wrote:
> 
> Hi everyone,
> 
> With the work to add Java 17 support for Cassandra, a new question around the 
> future of UDF was raised. The scripted UDF was using Nashorn which is no 
> longer packaged with the JDK. There are options to add new dependencies to 
> Graal JS for example but it seems people are not sure that it is worth it. 
> Please check the discussion on CASSANDRA-16895. 
> 
> The following suggestion was made by Marcus and supported by other PMC 
> members - "I think we should deprecate scripted UDFs now and drop them from 
> the next major, but possibly provide hooks for people to write their own UDF 
> "engines" and break out the current javascript implementation in to its own 
> repository (but not ship it with Cassandra)."
> 
> As a result we decided to engage with our users and created a Twitter survey. 
> Results below:
> We would love to understand how you use ApacheCassandra UDFs and UDAs.
> 32 people responded as follows:
> We do not use them - 75%
> We only use Java UDFs - 22%
> We only use JS UDFs - 0%
> We use Java and JS UDFs - 3%
> We also received feedback on LinkedIN on the topic - 
> https://www.linkedin.com/feed/update/urn:li:activity:6886728406742970369?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6886793921020608512%29=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6887421509485248512%29
> 
> Thoughts?
> 
> Best regards,
> Ekaterina

Re: [VOTE] Formalizing our CI process

[C. Scott Andreas]

+1nb, with and without the amendment.Reason for mentioning without: I see the ability to cut a 
release to address an urgent security or data loss issue as one of the strongest arguments for 
maintaining green CI as a resting state so we are ready in the event of an emergency.Test results 
that we can trust help us ship urgent fixes safely. If I were a user and had an urgent need to 
ramp a new build (e.g., if Apache Cassandra were affected by log4j), I would be very concerned 
about a fleet-wide deploy of a distributed database release with failing tests.But in both cases, 
+1nb. :)– ScottOn Jan 12, 2022, at 11:22 AM, David Capwell  wrote:+1On 
Jan 12, 2022, at 8:39 AM, Joseph Lynch  wrote:On Wed, Jan 12, 2022 
at 3:25 AM Berenguer Blasi wrote:jenkins CI was at 2/3 flakies 
consistently post 4.0 release.That is really impressive and I absolutely don't mean to downplay 
thatachievement.Then things broke and we've been working hard to get back to the 2/3 flakies. 
Mostcurrent failures imo are timeuuid C17133 or early termination of processC17140 related afaik. 
So getting back to the 2/3 'impossible' flakiesshould be doable and a reasonable target (famous 
last words...). My 2cts.I really appreciate all the work folks have been doing to get theproject 
to green, and I support the parts of the proposal that try toformalize methods to try to keep us 
there. I am only objecting to #2in the proposal where we have a non-negotiable gate on tests 
before arelease.-Joey

Re: [DISCUSSION] Next release roadmap

[C. Scott Andreas]

luence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index> > >   * Add support for OR predicates in the CQL where clause> > >   * Allow to aggregate by time intervals (CASSANDRA-11871) and> allow> > > UDFs> > > in GROUP BY clause> > >   * Ability to read the TTL and WRITE TIME of an element in a> > > collection> > > (CASSANDRA-8877)> > >   * Multi-Partition LWTs> > >   * Materialized views hardening: Addressing the different> > Materialized> > > Views issues (see CASSANDRA-15921 and [1] for some of the work> > > involved)> > >> > > *Security improvements:*> > >> > >   * SSTables encryption (CASSANDRA-9633)> > >   * Add support for Dynamic Data Masking (CEP pending)> > >   * Allow the creation of roles that have the ability to assign> > > arbitrary> > > privileges, or scoped privileges without also granting thoseroles> > > access> > > to database objects.> > >   * Filter rows from system and system_schema based on users> > > permissions> > > (CASSANDRA-15871)> > >> > > *Performance improvements:*> > >> > >   * Trie-based index format (CEP pending)> > >   * Trie-based memtables (CEP pending)> > >   * Paxos improvements: Paxos / LWT implementation that would> enable> > > the> > > database to serve serial writes with two round-trips and serial> reads> > > with> > > one round-trip in the uncontended case> > >> > > *Safety/Usability improvements:*> > >> > >   * Guardrails. The CEP can be found at> > >> > >> >>https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+Guardrails> > >   * Add ability to track state in repair (CASSANDRA-15399)> > >   * Repair coordinator improvements (CASSANDRA-15399)> > >   * Make incremental backup configurable per keyspace and table> > > (CASSANDRA-15402)> > >   * Add ability to blacklist a CQL partition so all requests are> > > ignored> > > (CASSANDRA-12106)> > >   * Add default and required keyspace replication options> > > (CASSANDRA-14557)> > >   * Transactional Cluster Metadata: Use of transactions to> propagate> > > cluster metadata> > >   * Downgrade-ability: Ability to downgrade to downgrade in the> event> > > that> > > a serious issue has been identified> > >> > > *Pluggability improvements:*> > >> > >   * Pluggable schema manager (CEP pending)> > >   * Pluggable filesystem (CEP pending)> > >   * Pluggable authenticator for CQLSH (CASSANDRA-16456). A CEP> draft> > > can be> > > found at> > 
>> > >> >>https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit> > >   * Memtable API (CEP pending). The goal being to allow> improvements> > > such> > > as CASSANDRA-13981 to be easily plugged into Cassandra> > >> > > *Memtable pluggable implementation:*> > >> > >   * Enable Cassandra for Persistent Memory (CASSANDRA-13981)> > >> > > *Other tools:*> > >> > >   * CQL compatibility test suite (CEP pending)> > >> > > Le jeu. 22 avr. 2021 à 16:11, Benjamin Lerer a> > > écrit :> > >> > > > Finally, I think it's important we work to maintain trunk in a> > > shippable> > > >> state.> > > >> > > >> > > > I am +100 on this. Bringing Cassandra to such a state was ahuge> > > effort> > > > and keeping it that way will help us to ensure the quality ofthe> > > > releases.> > > >> > > > Le jeu. 15 avr. 2021 à 17:30, Scott Andreas <> sc...@paradoxica.net>> > a> > > > écrit :> > > >> > > >> Thanks for starting this discussion, Benjamin!> > > >>> > > >> I share others’ enthusiasm on this thread for improvements to> > > secondary> > > >> indexes, trie-based partition indexes, guardrails, and> encryption> > > at rest.> > > >>> > > >> Here are some other post-4.0 areas for investment that havebeen> > on> > > my> > > >> mind:> > > >>> > > >&

Re: [DISCUSS] Disabling MIME-part filtering on this mailing list

[C. Scott Andreas]

+1, this would be great to have fixed. Thanks for talking with Infra about 
this, Bowen.

> On Dec 4, 2021, at 9:16 AM, Bowen Song  wrote:
> 
> Hello,
> 
> 
> Currently this mailing list has MIME-part filtering turned on, which will 
> results in "From:" address munging (appending ".INVALID" to the sender's 
> email address) for domains enforcing strict DMARC rules, such as apple.com, 
> zoho.com and all Yahoo.** domains. This behaviour may cause some emails being 
> treated as spam by the recipients' email service providers, because the 
> result "From:" address, such as "some...@yahoo.com.INVALID" is not valid and 
> cannot be verified.
> 
> I have created a Jira ticket INFRA-22548 
>  asking to change this, 
> but the Infra team said dropping certain MIME part types is to prevent spam 
> and harmful attachments, and would require a consensus from the project 
> before they can make the change. Therefore I'm sending this email asking for 
> your opinions on this.
> 
> To be clear, turning off the MIME-part filtering will not turn off the 
> anti-spam and anti-virus feature on the mailing list, all emails sent to the 
> list will still need to pass the checks before being forwarded to 
> subscribers. Morden (since 90s?) anti-spam and anti-virus software will scan 
> the MIME parts too, in addition to the plain-text and/or HTML email body. 
> Your email service provider is also almost certainly going to have their own 
> anti-spam and anti-virus software, in addition to the one on the mailing 
> list. The difference is whether the mailing list proactively removing MIME 
> parts not in the predefined whitelist.
> 
> To help you understand the change, here's the difference between the two 
> behaviours:
> 
> 
> With the MIME-part filtering enabled (current behaviour)
> 
> * the mailing list will remove certain MIME-part types, such as executable 
> file attachments, before forwarding it
> 
> * the mailing list will append ".INVALID" to some senders' email address
> 
> * the emails from the "*@*.INVALID" sender address are more likely to end up 
> in recipients' spam folder
> 
> * it's harder for people to directly reply to someone who's email address has 
> been modified in this way
> 
> * recipients running their own email server without anti-spam and/or 
> anti-virus software on it have some extra protections
> 
> 
> With MIME-part filtering disabled
> 
> * the mailing list forward all non-spam and non-infected emails as it is 
> without changing them
> 
> * the mailing list will not change senders' email address
> 
> * the emails from this mailing list are less likely to end up in recipients' 
> spam folder
> 
> * it's easier for people to directly reply to anyone in this mailing list
> 
> * recipients running their own email server without anti-spam and/or 
> anti-virus software on it may be exposed to some threats
> 
> 
> What's your opinion on this? Do you support or oppose disabling the MIME-part 
> filtering on the Cassandra-dev mailing list?
> 
> 
> p.s.: as you can see, my email address has the ".INVALID" appended to it by 
> this mailing list.
> 
> 
> Regards,
> 
> Bowen

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

Re: [DISCUSS] CEP-3: Guardrails

[C. Scott Andreas]

Re: "I think you all know my feels on JMX." –Super fair - I'd meant to speak in terms of desired outcome ("the feature should be dynamically 
configurable at runtime") rather than implementation ("this should be via JMX"). On Nov 1, 2021, at 1:24 PM, David Capwell 
 wrote:If anyone wants to bite off making 
https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java 
 support 
mutability then we get vtable support.  I am cool with JMX and/or vtable, to me its just more important to allow dynamic setting of these configs.On Nov 1, 
2021, at 10:36 AM, bened...@apache.org wrote:having them only configured via yaml seems like a bad outcome+1I would like to see us move towards configuration 
being driven through virtual tables where possible, so that the whole cluster can be managed from a single interface. Not sure if this is the right place to 
bite this off, but perhaps?From: Jeff Jirsa Date: Monday, 1 November 2021 at 16:47To: Cassandra DEV 
Subject: Re: [DISCUSS] CEP-3: GuardrailsWithout bike-shedding too much, guardrails would be great, building theminto a more 
general purpose framework that limits various dangerous thingswould be fantastic. The CEP says that the guardrails should be distinctfrom the capability 
restrictions (https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see whythat needs to be the case. A system-level guardrail and a 
personal-levelguardrail are both restrictions, they just have different scopes, soimplement the restriction framework first, and allow the scopes to beexpanded 
as needed?Naming wise, I don't know that I'd actually surface these as "guardrails",but more as general "limits", and having them only 
configured via yamlseems like a bad outcomehttps://issues.apache.org/jira/browse/CASSANDRA-8303On Mon, Nov 1, 2021 at 9:31 AM Andrés de la Peña 
wrote:Hi everyone,I'd like to start a discussion about Guardrails 
proposal:https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+GuardrailsGuardrails are an easy way to enforce system-wide soft and hard 
limits toprevent anti-patterns of bad usage and in the long run make it not possibleto severely degrade the performance of a node/cluster through user 
actionssuch as having too many secondary indexes, too large partitions, almostfull disks, etc.Thanks,

Re: [DISCUSS] CEP-3: Guardrails

[C. Scott Andreas]

Thank you for starting discussion on this CEP, Andrés!Can the "Scope" section of the doc be filled out? It currently reads "TBD," but 
having a better understanding of the scope of work would help focus discussion: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+GuardrailsRe: 
configuration via yaml, it will be important that these guardrails can be modified via JMX as well - e.g., in the case of a user running up against a limit 
and needing a path to being unblocked that doesn't require a yaml change and rolling restart.As David mentions, raising the visibility of the soft limit 
warnings will help users avoid being caught off-guard. Enabling the logging of wire protocol warnings received in CQL responses in the drivers by default 
would help if related JIRA tickets in those projects can be considered.On Nov 1, 2021, at 10:05 AM, David Capwell  
wrote:Under "Migrating existing cassandra.yaml warn/fail thresholds”, I recently added a few things which are basically guardrails, so should be 
included in this set; they are configured by track_warnings (coordinator_read_size, local_read_size, and row_index_size).  With track_warnings I setup the 
plumbing to have read queries trigger warnings (or abort the query) to the client exists (under "Event logging" you mention "and also to the 
client connection when applicable”) and isn’t limited to the coordinator participating in the query (previous limitation for tombstone warnings).  One thing 
I found which was problematic for track_warnings was that altering clients is annoying as java and python both ignore the error message we send (see 
https://github.com/datastax/java-driver/blob/3.11.0/driver-core/src/main/java/com/datastax/driver/core/Responses.java#L73-L131). We log client warnings (if 
enabled) but ignore any detailed error message received from the server; it would be good to talk about client integrations and how users are informed of 
issues in more detail.On Nov 1, 2021, at 9:46 AM, Jeff Jirsa  wrote:Without bike-shedding too much, guardrails would be great, 
building theminto a more general purpose framework that limits various dangerous thingswould be fantastic. The CEP says that the guardrails should be 
distinctfrom the capability restrictions (https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see whythat needs to be the case. A 
system-level guardrail and a personal-levelguardrail are both restrictions, they just have different scopes, soimplement the restriction framework first, and 
allow the scopes to beexpanded as needed?Naming wise, I don't know that I'd actually surface these as "guardrails",but more as general 
"limits", and having them only configured via yamlseems like a bad outcomehttps://issues.apache.org/jira/browse/CASSANDRA-8303On Mon, Nov 1, 2021 
at 9:31 AM Andrés de la Peña wrote:Hi everyone,I'd like to start a discussion about Guardrails 
proposal:https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+GuardrailsGuardrails are an easy way to enforce system-wide soft and 
hard limits toprevent anti-patterns of bad usage and in the long run make it not possibleto severely degrade the performance of a node/cluster through user 
actionssuch as having too many secondary indexes, too large partitions, almostfull disks, 
etc.Thanks,-To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.orgFor additional 
commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.11

[C. Scott Andreas]

+1nb

> On Oct 29, 2021, at 6:17 AM, bened...@apache.org wrote:
> 
> +1
> 
> From: Mick Semb Wever 
> Date: Friday, 29 October 2021 at 13:45
> To: dev@cassandra.apache.org 
> Subject: [VOTE] Release dtest-api 0.0.11
> Proposing the test build of in-jvm dtest API 0.0.11 for release.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.11
> 
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/cbe7e89dc166cf4f2f94a11c7b3e867494f62ac017050
> 
> tagged with 0.0.11
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1250/org/apache/cassandra/dtest-api/0.0.11/
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Changes since last release:
>  * CASSANDRA-17064: Option to start nodes with blank gossip state
>  * CASSANDRA-17050: Fix Upgrade tests throwing
> UnsupportedOperationException on initialise
> 
> 
> 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.

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

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

[C. Scott Andreas]

1. +1nb
2. +1nb
3. +1nb

It’s been encouraging to follow discussion advancing potential enhancements to 
this proposal on the other threads.

I disagree that it is a good outcome for the project and the Apache Cassandra 
user community to veto significant progress in this area on grounds that the 
CEP does not contain a design for a feature that is a non-goal of the initial 
scope proposed by the CEP, and which is also not precluded by the CEP.

- Scott

> On Oct 14, 2021, at 11:27 AM, Aleksey Yeschenko  wrote:
> 
> +1 on all points
> 
>> On 14 Oct 2021, at 17:31, bened...@apache.org wrote:
>> Hi everyone,
>> I would like to start a vote on this CEP, split into three sub-decisions, as 
>> discussion has been circular for some time.
>> 1. Do you support adopting this CEP?
>> 2. Do you support the transaction semantics proposed by the CEP for 
>> Cassandra?
>> 3. Do you support an incremental approach to developing transactions in 
>> Cassandra, leaving scope for future development?
>> The first vote is a consensus vote of all committers, the second and third 
>> however are about project direction and therefore are simple majority votes 
>> of the PMC.
>> Recall that all -1 votes must be accompanied by an explanation. If you 
>> reject the CEP only on grounds (2) or (3) you should not veto the proposal. 
>> If a majority reject grounds (2) or (3) then transaction developments will 
>> halt for the time being.
>> This vote will be open for 72 hours.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org

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

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

[C. Scott Andreas]

Hi Jonathan,Following up on my message yesterday as it looks like our replies may 
have crossed en route.Thanks for bumping your message from earlier in our discussion. 
I believe we have addressed most of these questions on the thread, in addition to 
offering a presentation on this and related work at ApacheCon, a discussion hosted 
following that presentation at ApacheCon, and in ASF Slack. Contributors have further 
offered an opportuntity to discuss specific questions via videoconference if it helps 
to speak live. I'd be happy to do so as well.Since your original message, discussion 
has covered a lot of ground on the related databases you've mentioned:– Henrik has 
shared expertise related to MongoDB and its implementation.– You've shared an 
overview of Calvin.– Alex Miller has helped us review the work relative to other 
Paxos algorithms and identified a few great enhancements to incorporate.– The paper 
discusses related approaches in FoundationDB, CockroachDB, and Yugabyte.– Subsequent 
discussion has contrasted the implementation to DynamoDB, Google Cloud BigTable, and 
Google Cloud Spanner (noting specifically that the protocol achieves Spanner's 1x 
round-trip without requiring specialized hardware).In my reply yesterday, I've 
attempted to crystallize what becomes possible via CQL: one-shot multi-partition 
transactions in the first implementation and a 4x latency reduction on writes / 2x 
latency reduction on reads relative to today; along with the ability to build upon 
this work to enable interactive transactions in the future.I believe we've exercised 
the questions you've raised and am grateful for the ground we've covered. If you have 
further questions that are difficult to exercise via email, please let me know if 
you'd like to arrange a call (open-invite); we'd be happy to discuss live as 
well.With the proposal hitting the one-month mark, the contributors are interested in 
gauging the developer community's response to the proposal. We warrant our ability to 
focus durably on the project; execute this development on ASF JIRA in collaboration 
with other contributors; engage with members of the developer and user community on 
feedback, enhancements, and bugs; and intend deliver it to completion at a standard 
of readiness suitable for production transactional systems of record.Thanks,– ScottOn 
Oct 6, 2021, at 8:25 AM, C. Scott Andreas  wrote:Hi 
folks,Thanks for discussion on this proposal, and also to Benedict who’s been 
fielding questions on the list!I’d like to restate the goals and problem statement 
captured by this proposal and frame context.Today, lightweight transactions limit 
users to transacting over a single partition. This unit of atomicity has a very low 
upper limit in terms of the amount of data that can be CAS’d over; and doing so leads 
many to design contorted data models to cram different types of data into one 
partition for the purposes of being able to CAS over it. We propose that Cassandra 
can and should be extended to remove this limit, enabling users to issue one-shot 
transactions that CAS over multiple keys – including CAS batches, which may modify 
multiple keys.To enable this, the CEP authors have designed a novel, leaderless 
paxos-based protocol unique to Cassandra, offered a proof of its correctness, a 
whitepaper outlining it in detail, along with a prototype implementation to incubate 
development, and integrated it with Maelstrom from jepsen.io to validate 
linearizability as more specific test infrastructure is developed. This rigor is 
remarkable, and I’m thrilled to see such a degree of investment in the area.Even 
users who do not require the capability to transact across partition boundaries will 
benefit. The protocol reduces message/WAN round-trips by 4x on writes (4 → 1) and 2x 
on reads (2 → 1) in the common case against today’s baseline. These latency 
improvements coupled with the enhanced flexibility of what can be transacted over in 
Cassandra enable new classes of applications to use the database.In particular, 1xRTT 
read/write transactions across partitions enable Cassandra to be thought of not just 
as a strongly consistent database, but even a transactional database - a mode many 
may even prefer to use by default. Given this capability, Apache Cassandra has an 
opportunity to become one of – or perhaps the only – database in the industry that 
can store multiple petabytes of data in a single database; replicate it across many 
regions; and allow users to transact over any subset of it. These are capabilities 
that can be met by no other system I’m aware of on the market. Dynamo’s transactions 
are single-DC. Google Cloud BigTable does not support transactions. Spanner, Aurora, 
CloudSQL, and RDS have far lower scalability limits or require specialized hardware, 
etc.This is an incredible opportunity for Apache Cassandra - to surpass the 
scalability and transactional capability of some of the most advanced systems in our

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

[C. Scott Andreas]

Adding a few notes from my perspective as well – Re: the UX question, thanks for asking this.I agree that offering a set of example queries and use cases may help make the specific use cases more understandable; perhaps we can prepare these as examples to be included in the CEP.I do think that all potential UX directions begin with the specification of the protocol that will underly them, as what can be expressed by it may be a superset of what's immediately exposed by CQL. But at minimum it's great to have a sense of the queries one might be able to issue to focus a reading of the whitepaper.Re: "Can we not start using it as an external dependency, and later re-evaluate if it's necessary to bring it into the project or even incubate it as another Apache 
project"I think it would be valuable to the project for the work to be incubated in a separate repository as part of the Apache Cassandra project itself, much like the in-JVM dtest API and Harry. This pattern worked well for those projects as they incubated as it allowed them to evolve outside the primary codebase, but subject to the same project governance, set of PMC members, committers, and so on. Like those libraries, it also makes sense as the Cassandra project is the first (and at this time) only known intended consumer of the library, though there may be more in the future.If the proposal is accepted, the time horizon envisioned for this work's completion is ~9 months to a standard of production readiness. The contributors see value in the work 
being donated to and governed by the contribution practices of the Foundation. Doing so ensures that it is being developed openly and with full opportunity for review and contribution of others, while also solidifying contribution of the IP to the project.Spinning up a separate ASF incubation project is an interesting idea, but I feel that doing so would introduce a far greater overhead in process and governance, and that the most suitable governance and set of committers/PMC members are those of the Apache Cassandra project itself.On Sep 14, 2021, at 3:53 PM, "bened...@apache.org"  wrote:Hi Paulo,First and foremost, I believe this proposal in its current form focuses on the protocol details (HOW?) but lacks the bigger 
picture on how this is going to be exposed to the user (WHAT)?In my opinion this CEP embodies a coherent distinct and complex piece of work, that requires specialist expertise. You have after all just suggested a month to read only the existing proposal UX is a whole other kind of discussion, that can be quite opinionated, and requires different expertise. It is in my opinion helpful to break out work that is not tightly coupled, as well as work that requires different expertise. As you point out, multi-key UX features are largely independent of any underlying implementation, likely can be done in parallel, and even with different contributors.Can we not start using it as an external dependencyI would love to understand your rationale, as this is a surprising 
suggestion to me. This is just like any other subsystem, but we would be managing it as a separate library primarily for modularity reasons. The reality is that this option should anyway be considered unavailable. This is a proposed contribution to the Cassandra project, which we can either accept or reject.Isn't this a good chance to make the serialization protocol pluggablewith clearly defined integration pointsIt has recently been demonstrated to be possible to build a system that can safely switch between different consensus protocols. However, this was very sophisticated work that would require its own CEP, one that we would be unable to resource. Even if we could this would be insufficient. This goal has never been achieved for a multi-shard transaction 
protocol to my knowledge, and multi-shard transaction protocols are much more divergent in implementation detail than consensus protocols.so we could easily switch implementations with different guarantees… (ie. Apache Ratis)As far as I know, there are no other strict serializable protocols available to plug in today. Apache Ratis appears to be a straightforward Raft implementation, and therefore it is a linearizable consensus protocol. It is not multi-shard transaction protocol at all, let alone strict serializable. It could be used in place of Paxos, but not Accord.From: Paulo Motta Date: Tuesday, 14 September 2021 at 22:55To: Cassandra DEV Subject: Re: [DISCUSS] CEP-15: General Purpose 
TransactionsI can start with some preliminary comments while I get more familiarizedwith the proposal:- First and foremost, I believe this proposal in its current form focuseson the protocol details (HOW?) but lacks the bigger picture on how this isgoing to be exposed to the user (WHAT)? Is exposing linearizabletransactions to the user not a goal of this proposal? If not, I think theproposal is missing the UX (ie. what CQL commands are going to be addedetc) on how these transactions are 

Re: [VOTE] Release dtest-api 0.0.9

[C. Scott Andreas]

+1nb

> 
> On Sep 9, 2021, at 2:03 PM, David Capwell  wrote:
> 
> +1
> 
>> On Sep 9, 2021, at 1:52 PM, Mick Semb Wever  wrote:
>> 
>> +1
>> 
>>> On Thu, 2 Sept 2021 at 13:20, Mick Semb Wever  wrote:
>>> 
>>> Proposing the test build of in-jvm dtest API 0.0.9 for release.
>>> 
>>> Repository: 
>>> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.9
>>> 
>>> Candidate SHA: 
>>> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/aa25319c3e0f506d19383db31d2974a7f5c58ab8
>>> tagged with 0.0.9
>>> 
>>> Artifacts: 
>>> https://repository.apache.org/content/repositories/orgapachecassandra-1248/org/apache/cassandra/dtest-api/0.0.9/
>>> 
>>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>>> 
>>> 
>>> Changes since last release:
>>> * CASSANDRA-16803
>>> jvm-dtest-upgrade failing
>>> MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck,
>>> ClassNotFoundException: com.vdurmont.semver4j.Semver
>>> 
>>> 
>>> 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.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: [VOTE] Release Apache Cassandra 4.0.1

[C. Scott Andreas]

+1nb

> On Sep 1, 2021, at 6:54 AM, Jeff Jirsa  wrote:
> 
> +1
> 
> 
>> On Wed, Sep 1, 2021 at 4:54 AM Sam Tunnicliffe  wrote:
>> 
>> Proposing the test build of Cassandra 4.0.1 for release.
>> 
>> sha1: 6709111ed007a54b3e42884853f89cabd38e4316
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1247/org/apache/cassandra/cassandra-all/4.0.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.0.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.0.1-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.1-tentative
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 

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

Re: [VOTE] CEP-14: Paxos Improvements

[Scott Andreas]

+1

> On Aug 27, 2021, at 12:58 PM, Mick Semb Wever  wrote:
> 
> 
>> 
>> 
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements
>> Discussion:
>> https://lists.apache.org/thread.html/r1af3da2d875ef93479e3874072ee651f406b96c915759c7968d3266e%40%3Cdev.cassandra.apache.org%3E
>> 
>> 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.
>> 
> 
> 
> +1

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

Re: [DISCUSS] Java support roadmap

[Scott Andreas]

+1 for moving Java 11 support out of experimental for 4.0 at minimum, and no 
concern with doing so for 3.0/3.11 if someone were to propose.

I and contributors I work with have deployed 4.0 + JDK11 in production, have 
found no issues, and would treat any issues that arise as ones we’re able to 
jump on and contribute development + review resources to resolve in the project.

No JDK11-specific bugs to report, though users should of course test their 
ancillary tooling for compatibility. As an example, a change in the File API in 
Java 10 altered the precision of filesystem timestamps as returned by the API, 
so users upgrading from 8 to 11 who have a dependency on timestamp identity may 
want to examine it.

That JDK change was: https://bugs.openjdk.java.net/browse/JDK-8177809

— Scott

---
Mobile

On Aug 26, 2021, at 7:35 AM, Ekaterina Dimitrova  wrote:

Hi everyone,
I had a few people asking me recently about the Java 11 support.
I came across this thread we had last year -
https://lists.apache.org/thread.html/r38f6beaa22e247cb38212f476f5f79efdc6587f83af0397406c06d7c%40%3Cdev.cassandra.apache.org%3E
.
I think we have all tests running in both Java 8 and Java 11 for trunk and
cassandra-4.0 in both Jenkins and CircleCI.
Does anyone know about any Java 11 specific bugs discovered? I personally
haven't heard of any in the past year. What is the plan of the community
for moving Java 11 support out of experimental?
Also, Java 17 LTS GA is planned for Sepember 2021 and I can try to test it
with trunk.
Any thoughts?
Last but not least, do we know  anyone running Java 11 in production?
This thread was really opened as a stage to share our thoughts and
hopefully come up with a plan as a community.

Looking forward to seeing what people think here.

Thank you,
Ekaterina

Re: Potential issues during 4.0 upgrade

[Scott Andreas]

Thank you for raising this, Sam!

Agreed this is a bug that warrants releasing 4.0.1 and notifying user@.

To elaborate on impact, this issue can produce a state in rolling 3.x -> 4.0 
upgrades in which 4.0 nodes fail to serialize gossip state during the shadow 
round once the size of this state exceeds 128kb. This prevents new instances 
from coming up. Once in this state, it is also not possible for new instances 
to start up and join the ring. If existing 4.0 instances restart, they will 
also be unable to gossip and remain down.

It's a pretty serious situation without an obvious way out aside from deploying 
this patch. We should get a new release out quickly.

– Scott


From: Sam Tunnicliffe 
Sent: Monday, August 23, 2021 11:27 AM
To: dev@cassandra.apache.org
Subject: Potential issues during 4.0 upgrade

Hi all,

I just opened a JIRA which is relevant to those running large clusters (around 
the 400 node range) and who have plans to upgrade to 4.0 upgrades soon.

https://issues.apache.org/jira/browse/CASSANDRA-16877 


The issue is that in large clusters, the size of gossip messages sent when a 
node (re)starts may exceed the hard limit of the urgent message channel. This 
causes an error on the sender and ultimately the message is dropped. This in 
turn can cause startup failures and/or partial loss of availability.

Fortunately, the fix is quite simple and I’ve submitted a patch that I and 
other contributors have been running since discovering this issue and can 
confirm resolves the problem. It would be great to get it reviewed and merged 
ASAP and then cut a 4.0.1 release. In the meantime, it may be wise to suggest 
that operators of large clusters hold off on any planned 4.0 upgrades.

Thanks,
Sam


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

Re: [DISCUSS] CEP 14: Paxos Improvements

[Scott Andreas]

Benedict, thank you for sharing this CEP!

Adding some notes on why I support this proposal:

- Reducing common-case round trips from 4x to 2x on writes and 2x to 1x on 
reads is a huge improvement. This latency reduction may be sufficient to allow 
many users of Cassandra who operate in a single datacenter, availability zone, 
or region to migrate to a multi-region topology.

- The Cluster Simulation work described in CEP-10 provides a toolchain for 
probabilistically-exhaustive validation and simulation of transactional 
correctness, allowing assertion of linearizability in the presence of 
adversarial thread scheduling and message ordering over an unbounded number of 
simulated clusters and transactions.

- Some use cases may see a superlinear increase in LWT performance due to a 
reduction in contention afforded by fewer message round-trips. E.g., halving 
latency shortens the interval during which competing transactions may conflict, 
reducing contention and improving throughput beyond a level that would be 
afforded by the latency reduction alone.

- Better safety among range movements: Electorate verification during range 
movements provides a stronger assertion of linearizability via assurance of the 
set of instances voting on a transaction.

– Scott


From: bened...@apache.org 
Sent: Wednesday, August 18, 2021 2:31 PM
To: dev@cassandra.apache.org
Subject: [DISCUSS] CEP 14: Paxos Improvements

RE: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements

I’m proposing this CEP for approval by the project. The goal is to both improve 
the performance of LWTs and to ensure their correctness across a range of 
scenario like range movements. This work builds upon the Simulator CEP that has 
been recently adopted, and patches will follow in the coming weeks.

If you have any concerns or questions please raise them here for discussion.

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

Re: Welcome Adam Holmberg as Cassandra committer

[Scott Andreas]

Congratulations, Adam! 


From: Joseph Lynch 
Sent: Tuesday, August 17, 2021 7:44 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Adam Holmberg as Cassandra committer

Congratulations Adam!

On Tue, Aug 17, 2021 at 10:25 AM Jordan West  wrote:
>
> Congrats Adam!
>
> On Tue, Aug 17, 2021 at 5:51 AM Paulo Motta 
> wrote:
>
> > Congratulations and well deserved Adam!
> >
> > Em ter., 17 de ago. de 2021 às 03:58, Sumanth Pasupuleti <
> > sumanth.pasupuleti...@gmail.com> escreveu:
> >
> > > Congratulations Adam!!
> > >
> > > On Mon, Aug 16, 2021 at 10:32 PM Berenguer Blasi <
> > berenguerbl...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Well done Adam, congrats!
> > > >
> > > > On 16/8/21 18:27, Andrés de la Peña wrote:
> > > > > Congrats Adam, well deserved!
> > > > >
> > > > > On Mon, 16 Aug 2021 at 17:14, Patrick McFadin 
> > > > wrote:
> > > > >
> > > > >> Great to see you on the committer list Adam!
> > > > >>
> > > > >> On Mon, Aug 16, 2021 at 7:06 AM Jonathan Ellis 
> > > > wrote:
> > > > >>
> > > > >>> Well deserved.  Congratulations!
> > > > >>>
> > > > >>> On Mon, Aug 16, 2021 at 5:57 AM Benjamin Lerer 
> > > > >> wrote:
> > > >   The PMC members are pleased to announce that Adam Holmberg has
> > > > >> accepted
> > > >  the invitation to become committer.
> > > > 
> > > >  Thanks a lot, Adam, for everything you have done for the project
> > all
> > > > >>> these
> > > >  years.
> > > > 
> > > >  Congratulations and welcome
> > > > 
> > > >  The Apache Cassandra PMC members
> > > > 
> > > > >>>
> > > > >>> --
> > > > >>> Jonathan Ellis
> > > > >>> co-founder, http://www.datastax.com
> > > > >>> @spyced
> > > > >>>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >

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

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

[Scott Andreas]

+1 nb


From: Sam Tunnicliffe 
Sent: Tuesday, July 27, 2021 12:54 AM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations

+1

> On 26 Jul 2021, at 11:51, bened...@apache.org wrote:
>
> Proposing the CEP-10 (Cluster and Code Simulations) for adoption
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10%3A+Cluster+and+Code+Simulations
> Discussion: 
> https://lists.apache.org/thread.html/rc908165994b15a29ef9c17b0b1205b2abc5bd38228b5a0117e442104%40%3Cdev.cassandra.apache.org%3E
>
> The vote will be open for 72 hours.
> Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s and no binding vetoes.


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


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

Re: [VOTE] Release Apache Cassandra 3.11.11

[Scott Andreas]

+1nb

> On Jul 25, 2021, at 12:06 PM, Brandon Williams  wrote:
> 
> I am proposing the test build of Cassandra 3.11.11 for release.
> 
> sha1: 4cafe2288e56e1135d65e76adbcd6c2de9306d6b
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.11-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1246/org/apache/cassandra/cassandra-all/3.11.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/3.11.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://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.11-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.11-tentative
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

Re: [VOTE] Release Apache Cassandra 3.0.25

[Scott Andreas]

+1nb, primarily for CASSANDRA-16735.

> On Jul 25, 2021, at 10:40 AM, Brandon Williams  wrote:
> 
> I am proposing the test build of Cassandra 3.0.25 for release.
> 
> sha1: 06235e93e16d1f483a3b03ba02f8fb29e33305fa
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.25-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1245/org/apache/cassandra/cassandra-all/3.0.25/
> 
> 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.25/
> 
> 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.0.25-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.25-tentative
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

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

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

[Scott Andreas]

+1nb.

Thank you for sharing a Circle run, Sumanth!


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

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

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

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

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Scott Andreas]

+1 nb


From: Andrés de la Peña 
Sent: Monday, June 28, 2021 1:04 PM
To: dev@cassandra.apache.org
Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc2

+1 (nb)

On Mon, 28 Jun 2021 at 21:01, Jon Meredith  wrote:

> +1 (nb)
>
> On Mon, Jun 28, 2021 at 9:47 AM Yifan Cai  wrote:
> >
> > +1
> >
> >
> > - Yifan
> >
> > > On Jun 28, 2021, at 8:40 AM, Ekaterina Dimitrova <
> e.dimitr...@gmail.com> wrote:
> > >
> > > +1 Thanks everyone!
> > >
> > >> On Mon, 28 Jun 2021 at 11:39, Aleksey Yeschenko 
> wrote:
> > >>
> > >> +1
> > >>
> >  On 28 Jun 2021, at 14:05, Gary Dusbabek 
> wrote:
> > >>>
> > >>> +1; yay!
> > >>>
> >  On Sun, Jun 27, 2021 at 11:02 AM Mick Semb Wever 
> wrote:
> > >>>
> >  Proposing the test build of Cassandra 4.0-rc2 for release.
> > 
> >  sha1: 4c98576533e1d7663baf447e8877788096489165
> >  Git:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc2-tentative
> >  Maven Artifacts:
> > 
> > 
> > >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1237/org/apache/cassandra/cassandra-all/4.0-rc2/
> > 
> >  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-rc2/
> > 
> >  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-rc2-tentative
> >  [2]: NEWS.txt:
> > 
> > 
> > >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc2-tentative
> >  [3]: The maven artifacts were accidentally prematurely made public.
> Docs
> >  have been updated to prevent this happening again.
> > 
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Are we ready for 4.0.0 (GA) ?

[Scott Andreas]

A second RC is appropriate given the revert of CASSANDRA-15899 necessitated by 
the discovery of CASSANDRA-16735: Adding columns via ALTER TABLE can generate 
corrupt sstables.

Ekaterina and Benedict's statement regarding the true positive rate of flaky 
tests also shows the value of resolving these, and that it would be good to pay 
this down as far as we can reasonably do so without unnecessarily withholding 
the release.

I do think it's possible that an RC2 build is a candidate for nomination as our 
GA release. I don't think the RC2 phase needs to be drawn-out, but believe it 
would build confidence for the project to have positive feedback from a release 
containing the fix for C-16735. If work paying down the remaining flaky tests 
surfaces a similar true positive rate, a third build might be warranted, and it 
would be to the benefit of our users - but I don't think we're far off.

I hope others are working to deploy the beta/RC builds and integrate + deploy 
changes from trunk into the releases they're deploying, as heavy contributors 
doing so provides us the best opportunity to catch these issues before our 
users do.

We're getting close.


From: bened...@apache.org 
Sent: Monday, June 14, 2021 3:03 PM
To: dev@cassandra.apache.org
Subject: Re: Are we ready for 4.0.0 (GA) ?

A rate of 4/30 is a rate of 13% true bugs, which worries me with respect to our 
promise of shipping a bug-free GA.  In past releases we have ensured no flaky 
tests, I think.

That said, I’ve not had the time to contribute to the fixing of flaky tests, so 
I’ll leave the decision to those who have, or otherwise have a strong opinion.


From: Ekaterina Dimitrova 
Date: Monday, 14 June 2021 at 20:51
To: dev@cassandra.apache.org 
Subject: Re: Are we ready for 4.0.0 (GA) ?
To give some context around the flaky tests, I pulled a quick report for the 
fixed ones during the past two months. It is attached for your reference.

To summarize, in two months 30 tickets for flaky tests were closed and only 4 
of them were Cassandra bugs(marked in red in the report), the rest of them were 
test fixes.

I think Butler and running in a loop any new tests before adding them to our 
test suite will help a lot. Also, Mick did a lot of work to stabilize Jenkins. 
Timeouts and resource issues are less common than before, that is  a win! Thank 
you Mick!

Best regards,
Ekaterina


On Mon, 14 Jun 2021 at 13:08, Adam Holmberg 
mailto:adam.holmb...@datastax.com>> wrote:
To the point of "long-term observability over flakies":

I will mention here that we intend to deploy a tool called Butler that we
have developed and used internally for a while. It compliments Jenkins to
present different views of test results, allowing developers to better
ascertain those tests that are flaky vs failing vs new regressions. We
already have a server provisioned for public hosting. The application
requires a bit of work to generalize for this project. We've been putting
it on while focused on getting 4.0 over the line, but should be getting to
it soon after.

On Mon, Jun 14, 2021 at 11:33 AM Mick Semb Wever 
mailto:m...@apache.org>> wrote:

> Are we ready to cut 4.0.0 (GA) once the following tickets land?
>
>  CASSANDRA-16733 – Allow operators to disable 'ALTER ... DROP COMPACT
> STORAGE' statements"
>  CASSANDRA-16669 – Password obfuscation for DCL audit log statements
>  CASSANDRA-16735 – Adding columns via ALTER TABLE can generate corrupt
> sstables
>
>
> A bit more background.
>
> 1. On our 4.0 GA board there's a few other tickets, which have priority but
> are not blockers for a GA release.
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355=1661
>
>  CASSANDRA-16715 – WEBSITE - June 2021 updates
>  CASSANDRA-12519 – dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
>  CASSANDRA-16681 – org.apache.cassandra.utils.memory.LongBufferPoolTest -
> tests are flaky
>  CASSANDRA-16689 – Flaky LeaveAndBootstrapTest
>
>
> 2. We also said we would get 5 green CI runs in a row. Progress on that
> front
> has been slow and risks delaying GA and our user base. It has had priority
> and there's been lots of momentum which is persisting: lots of flaky fixes
> committed; and the following are being discussed to keep pushing it in the
> right direction…
>  - Long-term observability over flakies
>  - Jenkins agent observability (infra stability)
>
> The past weeks has seen good progress on stability of ci-cassandra.a.o with
> the introduction of cpu docker limits imposed, and better monitoring of the
> agents so we can ensure we get the saturation and load we want. Dockerising
> the cqlshlib tests is also in progress.
>
> The alternative to a 4.0.0 GA release is a 4.0-rc2 release.
> Should the next release be: 4.0.0 (GA) or 4.0-rc2 ?
>


--
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Re: Welcome Dinesh Joshi as Cassandra PMC member

[Scott Andreas]

Congratulations, Dinesh!


From: Lorina Poland 
Sent: Wednesday, June 2, 2021 9:27 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Dinesh Joshi as Cassandra PMC member

Congratulations, Dinesh!

Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Wed, Jun 2, 2021 at 9:22 AM Vinay Chella 
wrote:

> Congratulations Dinesh.
>
> On Wed, Jun 2, 2021 at 9:18 AM Brandon Williams  wrote:
>
> > Congrats, Dinesh!
> >
> > On Wed, Jun 2, 2021 at 11:16 AM Benjamin Lerer 
> wrote:
> > >
> > >  The PMC's members are pleased to announce that Dinesh Joshi has
> accepted
> > > the invitation to become a PMC member.
> > >
> > > Thanks a lot, Dinesh, for everything you have done for the project all
> > > these years.
> > >
> > > Congratulations and welcome
> > >
> > > The Apache Cassandra PMC members
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Regards,
> Vinay Chella
> Engineering Manager, Data Abstractions Platform Team
>
> pronouns: he/him
>

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

Re: Welcome Caleb Rackliffe as Cassandra committer

[Scott Andreas]

Congratulations, Caleb!

— Scott

> On May 14, 2021, at 10:29 AM, Andrés de la Peña  
> wrote:
> 
> Congrats Caleb, well deserved! :)
> 
>> On Fri, 14 May 2021 at 17:53, Paulo Motta  wrote:
>> 
>> Awesome, congratulations Caleb!! :)
>> 
>> Em sex., 14 de mai. de 2021 às 13:16, Patrick McFadin 
>> escreveu:
>> 
>>> YES! Love seeing this. A very much deserved congratulations Caleb!
>>> 
>>> Patrick
>>> 
>>> On Fri, May 14, 2021 at 9:12 AM David Capwell >> 
>>> wrote:
>>> 
 Congrats!
 
> On May 14, 2021, at 8:52 AM, Charles Cao 
>> wrote:
> 
> Congrats Caleb! Well deserved :)
> 
> ~Charles
> 
>> On May 14, 2021, at 07:30, Yifan Cai  wrote:
>> 
>> Congrats Caleb!
>> 
>>> On May 14, 2021, at 6:56 AM, Joshua McKenzie >> 
 wrote:
>>> 
>>> Congrats Caleb!
>>> 
> On Fri, May 14, 2021 at 9:10 AM Brandon Williams <
>> dri...@gmail.com
 
 wrote:
 
 Congrats Caleb! Well deserved.
 
> On Fri, May 14, 2021, 8:03 AM Mick Semb Wever 
 wrote:
> 
> The PMC members are pleased to announce that Caleb Rackliffe has
> accepted the invitation to become committer.
> 
> Thanks heaps Caleb for helping make Cassandra awesome!
> 
> Congratulations and welcome,
> The Apache Cassandra PMC members
> 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> 
>> 

Re: Welcome Stefan Miklosovic as Cassandra committer

[Scott Andreas]

Congratulations, Štefan!


From: David Capwell 
Sent: Monday, May 3, 2021 10:53 AM
To: dev@cassandra.apache.org
Subject: Re: Welcome Stefan Miklosovic as Cassandra committer

Congrats!

> On May 3, 2021, at 9:47 AM, Ekaterina Dimitrova  wrote:
>
> Congrat Stefan! Well done!!
>
> On Mon, 3 May 2021 at 11:49, J. D. Jordan  wrote:
>
>> Well deserved!  Congrats Stefan.
>>
>>> On May 3, 2021, at 10:46 AM, Sumanth Pasupuleti <
>> sumanth.pasupuleti...@gmail.com> wrote:
>>>
>>> Congratulations Stefan!!
>>>
 On Mon, May 3, 2021 at 8:41 AM Brandon Williams 
>> wrote:

 Congratulations, Stefan!

> On Mon, May 3, 2021 at 10:38 AM Benjamin Lerer 
>> wrote:
>
> The PMC's members are pleased to announce that Stefan Miklosovic has
> accepted the invitation to become committer last Wednesday.
>
> Thanks a lot, Stefan,  for all your contributions!
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

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


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


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

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

[Scott Andreas]

Looks like we’ve crossed the 72-hour mark.

Shall we tally? 

> On Apr 23, 2021, at 4:43 AM, Paulo Motta  wrote:
> +1
> 
>> On Fri, 23 Apr 2021 at 06:35 Aleksey Yeshchenko 
>> wrote:
>> +1
 On 23 Apr 2021, at 08:51, Sam Tunnicliffe  wrote:
>>> +1
 On 23 Apr 2021, at 04:19, Jasonstack Zhao Yang <
>> jasonstack.z...@gmail.com> wrote:
 +1
 On Fri, 23 Apr 2021 at 08:16, Nate McCall  wrote:
> +1
> On Thu, Apr 22, 2021 at 6:59 AM Mick Semb Wever 
>> wrote:
>> Proposing the test build of Cassandra 4.0-rc1 for release.
>> sha1: 3282f5ecf187ecbb56b8d73ab9a9110c010898b0
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1235/org/apache/cassandra/cassandra-all/4.0-rc1/
>> 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-rc1/
>> 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-rc1-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org