Re: [DISCUSS] Adding support for BETWEEN operator

[Jeff Jirsa]

You can remove the shadowed values at compaction time, but you can’t ever fully 
propagate the range update to point updates, so you’d be propagating all of the 
range-update structures throughout everything forever. It’s JUST like a range 
tombstone - you don’t know what it’s shadowing (and can’t, in many cases, 
because the width of the range is uncountable for some types). 

Setting aside whether or not this construct is worth adding (I suspect a lot of 
binding votes would say it’s not), the thread focuses on BETWEEN operator, and 
there’s no reason we should pollute the conversation of “add a missing SQL 
operator that basically maps to existing functionality” with creation of a 
brand new form of update that definitely doesn’t map to any existing concepts. 





> On May 14, 2024, at 10:05 AM, Jon Haddad  wrote:
> 
> Personally, I don't think that something being scary at first glance is a 
> good reason not to explore an idea.  The scenario you've described here is 
> tricky but I'm not expecting it to be any worse than say, SAI, which (the 
> last I checked) has O(N) complexity on returning result sets with regard to 
> rows returned.  We've also merged in Vector search which has O(N) overhead 
> with the number of SSTables.  We're still fundamentally looking at, in most 
> cases, a limited number of SSTables and some merging of values.
> 
> Write updates are essentially a timestamped mask, potentially overlapping, 
> and I suspect potentially resolvable during compaction by propagating the 
> values.  They could be eliminated or narrowed based on how they've propagated 
> by using the timestamp metadata on the SSTable.
> 
> It would be a lot more constructive to apply our brains towards solving an 
> interesting problem than pointing out all its potential flaws based on gut 
> feelings.  We haven't even moved this past an idea.  
> 
> I think it would solve a massive problem for a lot of people and is 100% 
> worth considering.  Thanks Patrick and David for raising this.
> 
> Jon
> 
> 
> 
> On Tue, May 14, 2024 at 9:48 AM Bowen Song via dev  > wrote:
>> Ranged update sounds like a disaster for compaction and read performance.
>> 
>> Imagine compacting or reading some SSTables in which a large number of 
>> overlapping but non-identical ranges were updated with different values. It 
>> gives me a headache by just thinking about it.
>> 
>> Ranged delete is much simpler, because the "value" is the same tombstone 
>> marker, and it also is guaranteed to expire and disappear eventually, so the 
>> performance impact of dealing with them at read and compaction time doesn't 
>> suffer in the long term.
>> 
>> 
>> On 14/05/2024 16:59, Benjamin Lerer wrote:
>>> It should be like range tombstones ... in much worse ;-). A tombstone is a 
>>> simple marker (deleted). An update can be far more complex.  
>>> 
>>> Le mar. 14 mai 2024 à 15:52, Jon Haddad >> > a écrit :
 Is there a technical limitation that would prevent a range write that 
 functions the same way as a range tombstone, other than probably needing a 
 version bump of the storage format?
 
 
 On Tue, May 14, 2024 at 12:03 AM Benjamin Lerer >>> > wrote:
> Range restrictions (>, >=, =<, < and BETWEEN) do not work on UPDATEs. 
> They do work on DELETE because under the hood C* they get translated into 
> range tombstones.
> 
> Le mar. 14 mai 2024 à 02:44, David Capwell  > a écrit :
>> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this 
>> work.
>> 
>>> On May 13, 2024, at 7:40 AM, Patrick McFadin >> > wrote:
>>> 
>>> This is a great feature addition to CQL! I get asked about it from time 
>>> to time but then people figure out a workaround. It will be great to 
>>> just have it available. 
>>> 
>>> And right on Simon! I think the only project I had as a high school 
>>> senior was figuring out how many parties I could go to and still 
>>> maintain a passing grade. Thanks for your work here. 
>>> 
>>> Patrick 
>>> 
>>> On Mon, May 13, 2024 at 1:35 AM Benjamin Lerer >> > wrote:
 Hi everybody,
 
 Just raising awareness that Simon is working on adding support for the 
 BETWEEN operator in WHERE clauses (SELECT and DELETE) in 
 CASSANDRA-19604. We plan to add support for it in conditions in a 
 separate patch.
 
 The patch is available.
 
 As a side note, Simon chose to do his highschool senior project 
 contributing to Apache Cassandra. This patch is his first contribution 
 for his senior project (his second feature contribution to Apache 
 Cassandra).
 
 
>> 

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

[Jeff Jirsa]

Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going forward? On Apr 25, 2024, at 5:55 PM, Jon Haddad  wrote:Yeah, I agree with your concerns.  I very firmly prefer a separate subproject.  I've got zero interest in moving from a modern Gradle project to an ant based one.  It would be a lot of work for not much benefit.If we wanted to replace cassandra-stress, I'd say bring in the release artifact as part of the build process instead of tying it all together, but I'm OK if we keep it separate as well.JonOn Thu, Apr 25, 2024 at 2:43 PM Brandon Williams  wrote:I want to begin by saying I am generally +1 on this because I have
become a fan of easy-cass-stress after using it, but I am curious if
this is intended to be a subproject, or replace cassandra-stress?  If
the latter, we are going to have to reconcile the build systems
somehow.  I don't really want to drag ECS back to ant, but I also
don't want two different build systems in-tree.

Kind Regards,
Brandon

On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad  wrote:
>
> I've been asked by quite a few people, both in person and in JIRA [1] about contributing easy-cass-stress [2] to the project.  I've been happy to maintain the project myself over the years but given its widespread use I think it makes sense to make it more widely available and under the project's umbrella.
>
> My goal with the project was always to provide something that's easy to use.  Up and running in a couple minutes, using the parameters to shape the workload rather than defining everything through configuration.  I was happy to make this tradeoff since Cassandra doesn't have very many types of queries and it's worked well for me over the years.
>
> Obviously I would continue working on this project, and I hope this would encourage others to contribute.  I've heard a lot of good ideas that other teams have implemented in their folks.  I'd love to see those ideas make it into the project, and it sounds like it would be a lot easier for teams to get approval to contribute if it was under the project umbrella.
>
> Would love to hear your thoughts.
>
> Thanks,
> Jon
>
> [1] https://issues.apache.org/jira/browse/CASSANDRA-18661
> [2] https://github.com/rustyrazorblade/easy-cass-stress

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

[Jeff Jirsa]

I think Jordan and German had an interesting insight, or at least their comment made me think about this slightly differently, and I’m going to repeat it so it’s not lost in the discussion about zerocopy / sendfile.The CEP treats this as “move a live instance from one machine to another”. I know why the author wants to do this.If you think of it instead as “change backup/restore mechanism to be able to safely restore from a running instance”, you may end up with a cleaner abstraction that’s easier to think about (and may also be easier to generalize in clouds where you have other tools available ). I’m not familiar enough with the sidecar to know the state of orchestration for backup/restore, but “ensure the original source node isn’t running” , “migrate the config”, “choose and copy a snapshot” , maybe “forcibly exclude the original instance from the cluster” are all things the restore code is going to need to do anyway, and if restore doesn’t do that today, it seems like we can solve it once. Backup probably needs to be generalized to support many sources, too. Object storage is obvious (s3 download). Block storage is obvious (snapshot and reattach). Reading sstables from another sidecar seems reasonable, too.It accomplishes the original goal, in largely the same fashion, it just makes the logic reusable for other purposes? On Apr 19, 2024, at 5:52 PM, Dinesh Joshi  wrote:On Thu, Apr 18, 2024 at 12:46 PM Ariel Weisberg  wrote:If there is a faster/better way to replace a node why not  have Cassandra support that natively without the sidecar so people who aren’t running the sidecar can benefit? I am not the author of the CEP so take whatever I say with a pinch of salt. Scott and Jordan have pointed out some benefits of doing this in the Sidecar vs Cassandra. Today Cassandra is able to do fast node replacements. However, this CEP is addressing an important corner case when Cassandra is unable to start up due to old / ailing hardware. Can we fix it in Cassandra so it doesn't die on old hardware? Sure. However, you would still need operator intervention to start it up in some special mode both on the old and new node so the new node can peer with the old node, copy over its data and join the ring. This would still require some orchestration outside the database. The Sidecar can do that orchestration for the operator. The point I'm making here is that the CEP addresses a real issue. The way it is currently built can improve over time with improvements in Cassandra.Dinesh

Re: Which cassandra client for Python should we use (in the context of Python 3.12) ?

[Jeff Jirsa]

On 2024/02/21 09:26:53 Jarek Potiuk wrote:
> Hello dear Cassandra community,
> 
> I am a fellow PMC member of Apache Airflow and recently we started to look
> at the Cassandra provider of ours in the context of Python 3.12 migration
> and the integration raised my interest.
> 
> TL;DR; I am quite confused, which client should we use to be future-proof
> and I would appreciate the advice of the community on it, also I would like
> to understand why there is no community-managed client, as seems that with
> the current approach, any Python project (including ASF ones are pretty
> much forced to use 3rd-party managed way to use Cassandra, which I find
> rather strange.
> 
> Context:
> 
> So far in Apache Airflow we were using
> https://github.com/datastax/python-driver/ to connect to Cassandra, but
> when we worked on Python 3.12 compatibility.  While looking at it, I
> discovered something strange
> 

Mid-donated to the foundation: 

CEP: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation

[Private@]: https://lists.apache.org/thread/gor4b5l1hc4yokmcmpnhkfvg52w7rpp0

Status in board report: 
https://apache.org/foundation/records/minutes/2023/board_minutes_2023_08_16.txt

The Scylla version is a fork WITH ADDITIONS that work with implementation 
details of Scylladb not present in Apache Cassandra.

Preference use "Datastax" driver under donation if at all possible, and get it 
fixed as rapidly as is practical, but given that Scylla has already fixed the 
issue in theirs and it's an apache licensed fork of the same code, if you have 
to ship something to remain functional, that seems like a reasonable fallback.

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

[Jeff Jirsa]

1) If there’s an “old compatible default” and “latest recommended settings”, 
when does the value in “old compatible default” get updated? Never? 
2) If there are test failures with the new values, it seems REALLY IMPORTANT to 
make sure those test failures are discovered + fixed IN THE FUTURE TOO. If 
pushing new yaml into a different file makes us less likely to catch the 
failures in the future, it seems like we’re hurting ourselves. Branimir 
mentions this, but how do we ensure that we don’t let this pattern disguise 
future bugs? 





> On Feb 13, 2024, at 8:41 AM, Branimir Lambov  wrote:
> 
> Hi All,
> 
> CASSANDRA-18753 introduces a second set of defaults (in a separate 
> "cassandra_latest.yaml") that enable new features of Cassandra. The objective 
> is two-fold: to be able to test the database in this configuration, and to 
> point potential users that are evaluating the technology to an optimized set 
> of defaults that give a clearer picture of the expected performance of the 
> database for a new user. The objective is to get this configuration into 5.0 
> to have the extra bit of confidence that we are not releasing (and 
> recommending) options that have not gone through thorough CI.
> 
> The implementation has already gone through review, but I'd like to get 
> people's opinion on two things:
> - There are currently a number of test failures when the new options are 
> selected, some of which appear to be genuine problems. Is the community okay 
> with committing the patch before all of these are addressed? This should 
> prevent the introduction of new failures and make sure we don't release 
> before clearing the existing ones.
> - I'd like to get an opinion on what's suitable wording and documentation for 
> the new defaults set. Currently, the patch proposes adding the following text 
> to the yaml (see https://github.com/apache/cassandra/pull/2896/files):
> # NOTE:
> #   This file is provided in two versions:
> # - cassandra.yaml: Contains configuration defaults for a "compatible"
> #   configuration that operates using settings that are 
> backwards-compatible
> #   and interoperable with machines running older versions of Cassandra.
> #   This version is provided to facilitate pain-free upgrades for existing
> #   users of Cassandra running in production who want to gradually and
> #   carefully introduce new features.
> # - cassandra_latest.yaml: Contains configuration defaults that enable
> #   the latest features of Cassandra, including improved functionality as
> #   well as higher performance. This version is provided for new users of
> #   Cassandra who want to get the most out of their cluster, and for users
> #   evaluating the technology.
> #   To use this version, simply copy this file over cassandra.yaml, or 
> specify
> #   it using the -Dcassandra.config system property, e.g. by running
> # cassandra 
> -Dcassandra.config=file:/$CASSANDRA_HOME/conf/cassandra_latest.yaml
> # /NOTE
> Does this sound sensible? Should we add a pointer to this defaults set 
> elsewhere in the documentation?
> 
> Regards,
> Branimir

Re: [Discuss] Introducing Flexible Authentication in Cassandra via Feature Flag

[Jeff Jirsa]

Auth is one of those things that needs to be a bit more concrete In the scenario you describe, you already have an option to deploy the auth in piece partially during the rollout (pause halfway through) in the cluster and look for asymmetric connections, and the option to drop in a new Authenticator jar in the class path that does the flexible auth you describe I fear that the extra flexibility this allows for 1% of operations exposes people to long term problemsHave you considered just implementing the feature flag you describe using the existing plugin infrastructure ?On Feb 12, 2024, at 9:47 PM, Gaurav Agarwal  wrote:Dear Dinesh and Abe,Thank you for reviewing the document on enabling Cassandra authentication. I apologize that I didn't initially include the following failure scenarios where this feature could be particularly beneficial (I've included them now):Below are the failure scenarios:Incorrect credentials: If a client accidentally uses the wrong username/password combination during the rollout, While restarting the server to enable authentication, it will refuse connections with incorrect credentials. This can temporarily interrupt the service until correct credentials are sent.Missed service auth updates: In a large-scale system, a service "X" might miss the credential update during rollout. After some server nodes restart, service "X" might finally realize it needs correct credentials, but it's too late. Nodes are already expecting authorized requests, and this mismatch causes "X" to stop working on auth enabled and restarted nodes.Infrequent traffic:  Suppose one of the services only interacts with the server once a week. Suppose it starts sending requests with incorrect credentials after authentication is enabled. Since the entire cluster is now running on authentication, the service's outdated credentials cause it to be denied access, resulting in a service-wide outage.The overall aim of the proposed feature flag would allow clients to connect momentarily without authentication during the rollout, mitigating these risks and ensuring a smoother transition.Thanks in advance for your continued review of the proposal. On Mon, Feb 12, 2024 at 2:24 PM Abe Ratnofsky  wrote:Hey Guarav,Thanks for your proposal.> disruptive, full-cluster restart, posing significant risks in live environmentsFor configuration that isn't hot-reloadable, like providing a new IAuthenticator implementation, a rolling restart is required. But rolling restarts are zero-downtime and safe in production, as long as you pace them accordingly.In general, changing authenticators is a risky thing because it requires coordination with clients. To mitigate this risk and support clients while they transition between authenticators, I like the approach taken by MutualTlsWithPasswordFallbackAuthenticator:https://github.com/apache/cassandra/blob/bec6bfde1f3b6a782f123f9f9ff18072a97e379f/src/java/org/apache/cassandra/auth/MutualTlsWithPasswordFallbackAuthenticator.java#L34If client certificates are available, then use those, otherwise use the existing PasswordAuthenticator that clients are already using. The existing IAuthenticator interface supports this transitional behavior well.Your proposal to include a new configuration for auth_enforcement_flag doesn't clearly cover how to transition from one authenticator to another. It says:> Soft: Operates in a monitoring mode without enforcing authenticationMost users use authentication today, so auth_enforcement_flag=Soft would allow unauthenticated clients to connect to the database.--AbeOn Feb 12, 2024, at 2:44 PM, Gaurav Agarwal  wrote:Dear Cassandra Community,I'm excited to share a proposal for a new feature that I believe would significantly enhance the platform's security and operational flexibility: a flexible authentication mechanism implemented through a feature flag .Currently, enforcing authentication in Cassandra requires a disruptive, full-cluster restart, posing significant risks in live environments. My proposal, the auth_enforcement_flag, addresses this challenge by offering three modes:Hard: Enforces strict authentication with detailed logging.Soft: Monitors connection attempts (valid and invalid) without enforcing authentication.None: Maintains the current Cassandra behavior.This flag enables:Minimized downtime: Seamless authentication rollout without service interruptions.Enhanced security: Detailed logs for improved threat detection and troubleshooting.Gradual adoption: Phased implementation with real-world feedback integration.I believe this feature provides substantial benefits for both users and administrators. Please see the detailed proposal here: Introducing flexible authentication mechanismI warmly invite the community to review this proposal and share your valuable feedback. I'm eager to discuss its potential impact and collaborate on making Cassandra even better.Thank you for your time and consideration.Sincerely,Gaurav 

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

[Jeff Jirsa]

The problem with generalizing things is if you’re behind on compaction, reads get expensive, so you pause compaction completely, you’re SOL and you’ll eventually have to throttle traffic to recoverThe SEDA model is bad at back pressure and deferred cost makes it non-obvious which resource to slow to ensure stabilityJust start by exposing it instead of pretending we can outsmart the very complex system On Jan 18, 2024, at 4:56 PM, Jon Haddad  wrote:I am definitely +1 on the ability to rate limit operations to tables and keyspaces, and if we can do it at a granular level per user I'm +1 to that as well.  I think this would need to be exposed to the operator regardless of any automatic rate limiter.Thinking about the bigger picture for a minute, I think there's a few things we could throttle dynamically on the server before limiting the client requests.  I've long wanted to see a dynamic rate limiter with compaction and any streaming operation - using resources when they're available but slowing down to allow an influx of requests.  Being able to throttle background operations to free up resources to ensure the DB stays online and healthy would be a big win.> The major challenge with latency based rate limiters is that the latency is subjective from one workload to another. You're absolutely right.  This goes to my other suggestion that client-side rate limiting would be a higher priority (on my list at least) as it is perfectly suited for multiple varying workloads.  Of course, if you're not interested in working on the drivers and only on C* itself, this is a moot point.  You're free to work on whatever you want - I just think there's a ton more value in the drivers being able to throttle requests to deal than server side.> And if these two are +ve then consider the server under pressure. And once it is under the pressure, then shed the traffic from less aggressive to more aggressive, etc. The idea is to prevent Cassandra server from melting (by considering the above two signals to begin with and add any more based on the learnings)Yes, I agree using dropped metrics (errors) is useful, as well as queue length.  I can't remember offhand all the details of the request queue and how load shedding works there, I need to go back and look.  If we don't already have load shedding based on queue depth that seems like an easy thing to do immediately, and is a high quality signal.  Maybe someone can remind me if we have that already?My issue with using CPU to rate limit clients is that I think it's a very low quality signal, and I suspect it'll trigger a ton of false positives.  For example, there's a big difference from performance being impacted by repair vs large reads vs backing up a snapshot to an object store, but they have similar effects on the CPU - high I/O, high CPU usage, both sustained over time.  Imo it would be a pretty bad decision to throttle clients when we should be throttling repair instead, and we should only do so if it's actually causing an issue for the client, something CPU usage can't tell us, only the response time and error rates can.  In the case of a backup, throttling might make sense, or might not, it really depends on the environment and if backups are happening concurrently.  If a backup's configured with nice +19 (as it should be), I'd consider throttling user requests to be a false positive, potentially one that does more harm than good to the cluster, since the OS should be deprioritizing the backup for us rather than us deprioritizing C*.  In my ideal world, if C* detected problematic response times (possibly violating a per-table, target latency time) or query timeouts, it would start by throttling back compactions, repairs, and streaming to ensure client requests can be serviced.  I think we'd need to define the latency targets in order for this to work optimally, b/c you might not want to wait for query timeouts before you throttle.  I think there's a lot of value in dynamically adaptive compaction, repair, and streaming since it would prioritize user requests, but again, if you're not willing to work on that, it's your call.  Anyways - I like the idea of putting more safeguards in the database itself, we're fundamentally in agreement there.  I see a ton of value in having flexible rate limiters, whether it be per-table, keyspace, or user+table combination.  I'd also like to ensure the feature doesn't cause more disruptions than it solves, which I think would be the case from using CPU usage as a signal. JonOn Wed, Jan 17, 2024 at 10:26 AM Jaydeep Chovatia  wrote:Jon,The major challenge with latency based rate limiters is that the latency is subjective from one workload to another. As a result, in the proposal I have described, the idea is to make decision on the following combinations:System parameters (such as CPU usage, etc.)Cassandra thread pools health (are they dropping requests, etc.)And if these two are +ve then consider the server under 

Re: Future direction for the row cache and OHC implementation

[Jeff Jirsa]

> On Dec 14, 2023, at 1:51 PM, Dinesh Joshi  wrote:
> 
> 
>> 
>> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg  wrote:
>> 
>> 1. Fork OHC and start publishing under a new package name and continue to 
>> use it
> 
> Who would fork it? Where would you fork it? My first instinct is that this 
> would not be viable path forward.
> 
>> 2. Replace OHC with a different cache implementation like Caffeine which 
>> would move it on heap
> 
> Doesn’t seem optimal but given the advent of newer garbage collectors, we 
> might be able to run Cassandra with larger heap sizes and moving this to heap 
> may be a non-issue. Someone needs to try it out and measure  the performance 
> impact with Zgc or Shenandoah.
> 
>> 3. Deprecate the row cache entirely in either 5.0 or 5.1 and remove it in a 
>> later release
> 
> In my experience, Row cache has historically helped in narrow workloads where 
> you have really hot rows but in other workloads it can hurt performance. So 
> keeping it around may be fine as long as people can disable it.

Especially well with tiny partitions . Once you start slicing / paging the 
benefit usually disappears 


> 
> Moving it on-heap using Caffeine maybe the easiest option here.

That’s what I’d do.


> 
> 
> Dinesh

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

[Jeff Jirsa]

I'm also torn on the CEP as presented. I think some of it is my negative
emotional response to the examples - e.g. I've literally never seen a real
use case where unfolding constants matters, and I'm trying to convince
myself to read past that.

I also cant tell what exactly you mean when you say "In order to ensure
that the execution plans on each node are the same, the cardinality
estimator should provide the same global statistics on every node as well
as some notification mechanism that can be used to trigger
re-optimization." In my experience, you'll see variable cost on each host,
where a machine that went offline temporarily got a spike in sstables from
repair and has a compaction backlog, causing a higher cost per read on that
host due to extra sstables/duplicate rows/merges. Is the cost based
optimizer in your model going to understand the different cost per replica
and also use that in choosing the appropriate replicas to query?

Finally: ALLOW FILTERING should not be deprecated. It doesn't matter if the
CBO may be able to help improve queries that have filtering. That guard
exists because most people who are new to cassandra don't understand the
difference and it prevents far more self-inflicted failures than anyone can
count. Please do not remove this. You will instantly create a world where
most new users to the database tip over as soon as their adoption picks up.



On Thu, Dec 14, 2023 at 7:49 AM Chris Lohfink  wrote:

> I don't wanna be a blocker for this CEP or anything but did want to put my
> 2 cents in. This CEP is horrifying to me.
>
> I have seen thousands of clusters across multiple companies and helped
> them get working successfully. A vast majority of that involved blocking
> the use of MVs, GROUP BY, secondary indexes, and even just simple _range
> queries_. The "unncessary restrictions of cql" are not only necessary IMHO,
> more restrictions are necessary to be successful at scale. The idea of just
> opening up CQL to general purpose relational queries and lines like 
> "supporting
> queries with joins in an efficient way" ... I would really like us to
> make secondary indexes be a viable option before we start opening up
> floodgates on stuff like this.
>
> Chris
>
> On Thu, Dec 14, 2023 at 9:37 AM Benedict  wrote:
>
>> > So yes, this physical plan is the structure that you have in mind but
>> the idea of sharing it is not part of the CEP.
>>
>>
>> I think it should be. This should form a major part of the API on which
>> any CBO is built.
>>
>>
>> > It seems that there is a difference between the goal of your proposal
>> and the one of the CEP. The goal of the CEP is first to ensure optimal
>> performance. It is ok to change the execution plan for one that delivers
>> better performance. What we want to minimize is having a node performing
>> queries in an inefficient way for a long period of time.
>>
>>
>> You have made a goal of the CEP synchronising summary statistics across
>> the whole cluster in order to achieve some degree of uniformity of query
>> plan. So this is explicitly a goal of the CEP, and synchronising summary
>> statistics is a hard problem and won’t provide strong guarantees.
>>
>>
>> > The client side proposal targets consistency for a given query on a
>> given driver instance. In practice, it would be possible to have 2 similar
>> queries with 2 different execution plans on the same driver
>>
>>
>> This would only be possible if the driver permitted it. A driver could
>> (and should) enforce that it only permits one query plan per query.
>>
>>
>> The opposite is true for your proposal: some queries may begin degrading
>> because they touch specific replicas that optimise the query differently,
>> and this will be hard to debug.
>>
>>
>> On 14 Dec 2023, at 15:30, Benjamin Lerer  wrote:
>>
>> 
>> The binding of the parser output to the schema (what is today the
>> Raw.prepare call) will create the logical plan, expressed as a tree of
>> relational operators. Simplification and normalization will happen on that
>> tree to produce a new equivalent logical plan. That logical plan will be
>> used as input to the optimizer. The output will be a physical plan
>> producing the output specified by the logical plan. A tree of physical
>> operators specifying how the operations should be performed.
>>
>> That physical plan will be stored as part of the statements
>> (SelectStatement, ModificationStatement, ...) in the prepared statement
>> cache. Upon execution, variables will be bound and the
>> RangeCommands/Mutations will be created based on the physical plan.
>>
>> The string representation of a physical plan will effectively represent
>> the output of an EXPLAIN statement but outside of that the physical plan
>> will stay encapsulated within the statement classes.
>> Hints will be parameters provided to the optimizer to enforce some
>> specific choices. Like always using an Index Scan instead of a Table Scan,
>> ignoring the cost comparison.
>>
>> So yes, this 

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Jeff Jirsa]

-0 to cutting a beta we know has a very obvious correctness flaw with a fix
already understood



On Tue, Nov 28, 2023 at 10:40 AM Patrick McFadin  wrote:

> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need people looking
> today because they will find new bugs and the signal is lost on alpha. It's
> too yolo for most people.
>
> On Tue, Nov 28, 2023 at 10:36 AM Benjamin Lerer  wrote:
>
>> -1 based on the problems raised by Caleb.
>>
>> I would be fine with releasing that version as an alpha as Jeremiah
>> proposed.
>>
>> 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.
>>
>>
>> Some people at Datastax are working on such testing. It will take a bit
>> of time before we get the final results though.
>>
>> Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
>> écrit :
>>
>>> That said. This is clearly better than and with many fixes from the
>>> alpha. Would people be more comfortable if this cut was released as another
>>> alpha and we do beta1 once the known fixes land?
>>>
>>> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
>>> wrote:
>>>
>>> 
>>> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
>>> would think we should re-cut beta1 at the end of the week.
>>>
>>> On Nov 28, 2023, at 12:06 PM, Patrick McFadin 
>>> wrote:
>>>
>>> 
>>> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
>>> especially if there are declared known issues. We need people outside of
>>> this tight group using it and finding issues. I know how this rolls. Very
>>> few people touch a Alpha release. Beta is when the engine starts and we
>>> need to get it started asap. Otherwise we are telling ourselves we have the
>>> perfect testing apparatus and don't need more users testing. I don't think
>>> that is the case.
>>>
>>> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking
>>> about Cassandra 5 in the keynotes. In that time, our call to action is
>>> going to be to test the beta.
>>>
>>> Patrick
>>>
>>> On Tue, Nov 28, 2023 at 9:41 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.
>


 +1

 Checked
 - signing correct
 - checksums are correct
 - source artefact builds (JDK 11+17)
 - binary artefact runs (JDK 11+17)
 - debian package runs (JDK 11+17)
 - debian repo runs (JDK 11+17)
 - redhat* package runs (JDK11+17)
 - redhat* repo runs (JDK 11+17)


 With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
 fixes to be available soon in 5.0-beta2.

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

[Jeff Jirsa]

Why ship a ghost release we dont really expect people to use. Why not just
move the date so all the PR content highlighting TCM+Accord isnt a mess?

I get it, nobody wants to move dates. Isn't that the least-bad option?

On Mon, Oct 23, 2023 at 11:28 AM Aleksey Yeshchenko 
wrote:

> I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path
> instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 in
> one hop.
>
> Nobody likes going through these upgrades. So I personally expect 5.0 to
> be a largely ghost release if we go this route, adopted by few, just a
> permanent burden on the merge path to trunk.
>
> Not to say that there isn’t valuable stuff in 5.0 without TCM and Accord -
> there most certainly is - but with the expectation that 5.1 will follow up
> reasonably shortly after with all that *and* two highly anticipated
> features on top, I just don’t see the point. It will be another 2.2 release.
>
>
> On 23 Oct 2023, at 17:43, Josh McKenzie  wrote:
>
> We discussed that at length in various other mailing threads Jeff - kind
> of settled on "we're committing to cutting a major (semver MAJOR or MINOR)
> every 12 months but want to remain flexible for exceptions when
> appropriate".
>
> And then we discussed our timeline for 5.0 this year and settled on the
> "let's try and get it out this calendar year so it's 12 months after 4.1,
> but we'll grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and support drop is predicated
> on the 5.0 release, not any specific features or anything.
>
> On Mon, Oct 23, 2023, at 12:29 PM, Jeff Jirsa wrote:
>
>
>
> On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:
>
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
>
> I think this presumes that 5.0 GA is date driven instead of feature driven.
>
> I'm sure there's a conversation elsewhere, but why isn't this date movable?
>
>
>

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

[Jeff Jirsa]

On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever  wrote:

>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>

I think this presumes that 5.0 GA is date driven instead of feature driven.

I'm sure there's a conversation elsewhere, but why isn't this date movable?

Re: [VOTE] Accept java-driver

[Jeff Jirsa]

+1


On Mon, Oct 2, 2023 at 9: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] CEP-36: A Configurable ChannelProxy to alias external storage locations

[Jeff Jirsa]

Claude if you’re still at POC phase does it make sense for you to perhaps help validate / qualify the work that Henrik seems willing to rebase rather than reinventing the wheel? On Sep 26, 2023, at 11:23 PM, Claude Warren, Jr via dev  wrote:I spent a little (very little) time building an S3 implementation using an Apache licensed S3 filesystem package.  I have not yet tested it but if anyone is interested it is at https://github.com/Aiven-Labs/S3-Cassandra-ChannelProxyIn looking at some of the code I think the Cassandra File class needs to be modified to ask the ChannelProxy for the default file system for the file in question.  This should resolve some of the issues my original demo has with some files being created in the data tree.  It may also handle many of the cases for offline tools as well.On Tue, Sep 26, 2023 at 7:33 PM Miklosovic, Stefan  wrote:Would it be possible to make Jimfs integration production-ready then? I see we are using it in the tests already.

It might be one of the reference implementations of this CEP. If there is a type of workload / type of nodes with plenty of RAM but no disk, some kind of compute nodes, it would just hold it all in memory and we might "flush" it to a cloud-based storage if rendered to be not necessary anymore (whatever that means).

We could then completely bypass the memtables as fetching data from an SSTable from memory would be basically roughly same?

On the other hand, that might be achieved by creating a ramdisk so I am not sure what exactly we would gain here. However, if it was eventually storing these SSTables in a cloud storage, we might "compact" "TWCS tables" automatically after so-and-so period by moving them there.


From: Jake Luciani 
Sent: Tuesday, September 26, 2023 19:03
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

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




We (DataStax) have a FileSystemProvider for Astra we can provide.
Works with S3/GCS/Azure.

I'll ask someone on our end to make it accessible.

This would work by having a bucket prefix per node. But there are lots
of details needed to support things like out of bound compaction
(mentioned in CEP).

Jake

On Tue, Sep 26, 2023 at 12:56 PM Benedict  wrote:
>
> I agree with Ariel, the more suitable insertion point is probably the JDK level FileSystemProvider and FileSystem abstraction.
>
> It might also be that we can reuse existing work here in some cases?
>
> On 26 Sep 2023, at 17:49, Ariel Weisberg  wrote:
>
> 
> Hi,
>
> Support for multiple storage backends including remote storage backends is a pretty high value piece of functionality. I am happy to see there is interest in that.
>
> I think that `ChannelProxyFactory` as an integration point is going to quickly turn into a dead end as we get into really using multiple storage backends. We need to be able to list files and really the full range of filesystem interactions that Java supports should work with any backend to make development, testing, and using existing code straightforward.
>
> It's a little more work to get C* to creates paths for alternate backends where appropriate, but that works is probably necessary even with `ChanelProxyFactory` and munging UNIX paths (vs supporting multiple Fileystems). There will probably also be backend specific behaviors that show up above the `ChannelProxy` layer that will depend on the backend.
>
> Ideally there would be some config to specify several backend filesystems and their individual configuration that can be used, as well as configuration and support for a "backend file router" for file creation (and opening) that can be used to route files to the backend most appropriate.
>
> Regards,
> Ariel
>
> On Mon, Sep 25, 2023, at 2:48 AM, Claude Warren, Jr via dev wrote:
>
> I have just filed CEP-36 [1] to allow for keyspace/table storage outside of the standard storage space.
>
> There are two desires  driving this change:
>
> The ability to temporarily move some keyspaces/tables to storage outside the normal directory tree to other disk so that compaction can occur in situations where there is not enough disk space for compaction and the processing to the moved data can not be suspended.
> The ability to store infrequently used data on slower cheaper storage layers.
>
> I have a working POC implementation [2] though there are some issues still to be solved and much logging to be reduced.
>
> I look forward to productive discussions,
> Claude
>
> [1] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
>
>
>


--

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

[Jeff Jirsa]

- I think this is a great step forward.
- Being able to move sstables around between tiers of storage is a feature
Cassandra desperately needs, especially if one of those tiers is some sort
of object storage
- This looks like it's a foundational piece that enables that. Perhaps by a
team that's already implemented this end to end?
- Rather than building this piece by piece, I think it'd be awesome if
someone drew up an end-to-end plan to implement tiered storage, so we can
make sure we're discussing the whole final state, and not an implementation
detail of one part of the final state?






On Sun, Sep 24, 2023 at 11:49 PM Claude Warren, Jr via dev <
dev@cassandra.apache.org> wrote:

> I have just filed CEP-36 [1] to allow for keyspace/table storage outside
> of the standard storage space.
>
> There are two desires  driving this change:
>
>1. The ability to temporarily move some keyspaces/tables to storage
>outside the normal directory tree to other disk so that compaction can
>occur in situations where there is not enough disk space for compaction and
>the processing to the moved data can not be suspended.
>2. The ability to store infrequently used data on slower cheaper
>storage layers.
>
> I have a working POC implementation [2] though there are some issues still
> to be solved and much logging to be reduced.
>
> I look forward to productive discussions,
> Claude
>
> [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-36%3A+A+Configurable+ChannelProxy+to+alias+external+storage+locations
> [2] https://github.com/Claudenw/cassandra/tree/channel_proxy_factory
>
>
>

Re: [DISCUSS] Add JVector as a dependency for CEP-30

[Jeff Jirsa]

To do that, the cassandra PMC can open a legal JIRA and ask for a (durable,
concrete) opinion.


On Fri, Sep 22, 2023 at 5:59 AM Benedict  wrote:

>
>1. my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
>copyright
>
> I highly doubt liability works like that in all jurisdictions, even if it
> might in some. I can even think of some historic cases related to Linux
> where patent trolls went after users of Linux, though I’m not sure where
> that got to and I don’t remember all the details.
>
> But anyway, none of us are lawyers and we shouldn’t be depending on this
> kind of analysis. At minimum we should invite legal to proffer an opinion
> on whether dependencies are a valid loophole to the policy.
>
>
> On 22 Sep 2023, at 13:48, J. D. Jordan  wrote:
>
> 
> This Gen AI generated code use thread should probably be its own mailing
> list DISCUSS thread?  It applies to all source code we take in, and accept
> copyright assignment of, not to jars we depend on and not only to vector
> related code contributions.
>
> On Sep 22, 2023, at 7:29 AM, Josh McKenzie  wrote:
>
> 
> So if we're going to chat about GenAI on this thread here, 2 things:
>
>1. A dependency we pull in != a code contribution (I am not a lawyer
>but my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
>copyright and it's not sticky). Easier to transition to a different dep if
>there's something API compatible or similar.
>2. With code contributions we take in, we take on some exposure in
>terms of copyright and infringement. git revert can be painful.
>
> For this thread, here's an excerpt from the ASF policy:
>
> a recommended practice when using generative AI tooling is to use tools
> with features that identify any included content that is similar to parts
> of the tool’s training data, as well as the license of that content.
>
> Given the above, code generated in whole or in part using AI can be
> contributed if the contributor ensures that:
>
>1. The terms and conditions of the generative AI tool do not place any
>restrictions on use of the output that would be inconsistent with the Open
>Source Definition (e.g., ChatGPT’s terms are inconsistent).
>2. At least one of the following conditions is met:
>1. The output is not copyrightable subject matter (and would not be
>   even if produced by a human)
>   2. No third party materials are included in the output
>   3. Any third party materials that are included in the output are
>   being used with permission (e.g., under a compatible open source 
> license)
>   of the third party copyright holders and in compliance with the 
> applicable
>   license terms
>   3. A contributor obtain reasonable certainty that conditions 2.2 or
>2.3 are met if the AI tool itself provides sufficient information about
>materials that may have been copied, or from code scanning results
>1. E.g. AWS CodeWhisperer recently added a feature that provides
>   notice and attribution
>
> When providing contributions authored using generative AI tooling, a
> recommended practice is for contributors to indicate the tooling used to
> create the contribution. This should be included as a token in the source
> control commit message, for example including the phrase “Generated-by
>
>
> I think the real challenge right now is ensuring that the output from an
> LLM doesn't include a string of tokens that's identical to something in its
> input training dataset if it's trained on non-permissively licensed inputs.
> That plus the risk of, at least in the US, the courts landing on the side
> of saying that not only is the output of generative AI not copyrightable,
> but that there's legal liability on either the users of the tools or the
> creators of the models for some kind of copyright infringement. That can be
> sticky; if we take PR's that end up with that liability exposure, we end up
> in a place where either the foundation could be legally exposed and/or we'd
> need to revert some pretty invasive code / changes.
>
> For example, Microsoft and OpenAI have publicly committed to paying legal
> fees for people sued for copyright infringement for using their tools:
> https://www.verdict.co.uk/microsoft-to-pay-legal-fees-for-customers-sued-while-using-its-ai-products/?cf-view
> .
> Pretty interesting, and not a step a provider would take in an environment
> where things were legally clear and settled.
>
> So while the usage of these things is apparently incredibly pervasive
> right now, "everybody is doing it" is a 

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

[Jeff Jirsa]

You can open a legal JIRA to confirm, but based on my understanding (and
re-confirming reading https://www.apache.org/legal/resolved.html#category-a
):

- The restriction is on what can be in A PROJECT. tests are part of the
project, and not distinguished from the compiled product (especially since
the PROJECT ships SOURCE to build the product, if the SOURCE to build
requires the test, the test is clearly non-optional)
- GPL is cat X https://www.apache.org/legal/resolved.html#category-x

Cat X mixes "project" and "product" a few times, but again, the product is
still the source distribution, which would include the test, which means
it's excluded.

"Apache projects may not distribute Category X licensed components, in
source or binary form" doesnt seem ambiguous to me, but if someone wants to
ask ASF legal if I'm wrong, that's totally ok.



On Wed, Sep 13, 2023 at 9:25 AM Ekaterina Dimitrova 
wrote:

> Jeff, isn’t this ok as long as it is used only in tests? If we are not
> sure we can open a Jira to legal?
>
> On Wed, 13 Sep 2023 at 12:23, Jeff Jirsa  wrote:
>
>> Just to be clear - this repo?
>> https://github.com/haifengl/smile/blob/master/LICENSE
>>
>> That shows GPL + Commercial?
>>
>>
>>
>> On Wed, Sep 13, 2023 at 9:10 AM Brandon Williams 
>> wrote:
>>
>>> I don't see any problem with this, +1.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>>
>>> On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson 
>>> wrote:
>>>
>>>> CEP-30: [Approximate Nearest Neighbor(ANN) Vector Search via
>>>> Storage-Attached Indexes] uses the smile-nlp library
>>>> (com.github.haifengl.smile-nlp) in its testing to allow the creation of
>>>> word2vec embeddings for valid input into the HNSW graph index.
>>>>
>>>> The reason for this library is that we found that using random vectors
>>>> in testing produced very inconsistent results. Using the smile-nlp word2vec
>>>> implementation with the glove.3k.50d library produces repeatable results.
>>>>
>>>> Does anyone have any objections to the use of this library as a test
>>>> only dependency?
>>>> --
>>>> [image: DataStax Logo Square] <https://www.datastax.com/> *Mike
>>>> Adamson*
>>>> Engineering
>>>>
>>>> +1 650 389 6000 <16503896000> | datastax.com
>>>> <https://www.datastax.com/>
>>>> Find DataStax Online: [image: LinkedIn Logo]
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax=DwMFaQ=adz96Xi0w1RHqtPMowiL2g=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q=>
>>>>[image: Facebook Logo]
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax=DwMFaQ=adz96Xi0w1RHqtPMowiL2g=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU=>
>>>>[image: Twitter Logo] <https://twitter.com/DataStax>   [image: RSS
>>>> Feed] <https://www.datastax.com/blog/rss.xml>   [image: Github Logo]
>>>> <https://github.com/datastax>
>>>>
>>>>

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

[Jeff Jirsa]

Just to be clear - this repo?
https://github.com/haifengl/smile/blob/master/LICENSE

That shows GPL + Commercial?



On Wed, Sep 13, 2023 at 9:10 AM Brandon Williams  wrote:

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

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[Jeff Jirsa]

Given the disclaimer, can you just confirm why we'd cut an alpha now -
we're trying to lock protocols and give other people an integration target,
presumably?


On Fri, Aug 25, 2023 at 8:14 AM Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER, this alpha release does not contain the expected 5.0
> features: Vector Search (CEP-30), Transactional Cluster Metadata
> (CEP-21) and Accord Transactions (CEP-15).  These features will land
> in a later alpha release.
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
> Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
> Maven 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: Removal of CloudstackSnitch

[Jeff Jirsa]

+1


On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie  wrote:

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

Re: Improved DeletionTime serialization to reduce disk size

[Jeff Jirsa]

On Thu, Jun 22, 2023 at 11:23 PM Berenguer Blasi 
wrote:

> Hi all,
>
> Given we're already introducing a new sstable format (OA) in 5.0 I would
> like to try to get this in before the freeze. The point being that
> sstables with lots of small partitions would benefit from a smaller DT
> at partition level. My tests show a 3%-4% size reduction on disk.
>


3-4% reduction on disk ... for what exactly?

It seems exceptionally uncommon to have 3% of your data SIZE be tombstones.

Is this enhancement driven by a pathological data model that's like "mostly
tiny records OR tombstones" ?

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

[Jeff Jirsa]

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

[Jeff Jirsa]

+1


On Tue, Jun 13, 2023 at 7:15 AM Jeremy Hanna 
wrote:

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

Re: [DISCUSSION] Adding sonar report analysis to the Cassandra project

[Jeff Jirsa]

On Mon, Jun 12, 2023 at 10:18 AM Mick Semb Wever  wrote:

>
>
> On Mon, 12 Jun 2023 at 15:02, Maxim Muzafarov  wrote:
>
>> Hello everyone,
>>
>> I would like to make the source code of the Cassandra project more
>> visible to people outside of the Cassandra Community and highlight the
>> typical known issues in new contributions in the GitHub pull-request
>> interface as well. This makes it easier for those who are unfamiliar
>> with the accepted code style and just want to be part of a large and
>> friendly community to add new contributions.
>>
>> The ASF provides [1] the SonarClound facilities for the open source
>> project, which are free to use, and we can also easily add the process
>> of building and uploading reports to the build using GitHub actions
>> with almost no maintenance costs for us. Of course, as a
>> recommendation quality tool, it doesn't reject any changes/pull
>> requests, so nothing will change from that perspective.
>>
>> I've prepared everything we need to do this here (we also need to
>> modify the default Sonar Way profile to suit our needs, which I can't
>> do as I don't have sufficient privileges):
>> https://issues.apache.org/jira/browse/CASSANDRA-18390
>>
>> I look forward to hearing your thoughts on this.
>>
>
>
> Looks good.  Agree with the use of GHA, but it's worth noting that this
> cannot be a pre-commit gate – as PRs are not required.  And if it came as
> part of pre-commit CI, how would the feedback then work (as it's the jira
> ticket that is our point-of-contact pre-commit) ?
>
> I say go for it.  Especially with the post-commit trends it will be
> valuable for us to see it before further adoption and adjustment.
>

I'd also say the same - Go for it, at worst people can ignore it, at best
someone sees the data and decides to take action.

If we eventually try to define a POLICY based on the feedback, I suspect
it'll be a longer  conversation, but I don't see any harm in setting it up.

Re: [DISCUSS] Limiting query results by size (CASSANDRA-11745)

[Jeff Jirsa]

On Mon, Jun 12, 2023 at 9:50 AM Benjamin Lerer  wrote:

> If you have rows that vary significantly in their size, your latencies
>> could end up being pretty unpredictable using a LIMIT BY . Being
>> able to specify a limit by bytes at the driver / API level would allow app
>> devs to get more deterministic results out of their interaction w/the DB if
>> they're looking to respond back to a client within a certain time frame and
>> / or determine next steps in the app (continue paging, stop, etc) based on
>> how long it took to get results back.
>
>
> Are you talking about the page size or the LIMIT. Once the LIMIT is
> reached there is no "continue paging". LIMIT is also at the CQL level not
> at the driver level.
> I can totally understand the need for a page size in bytes not for a LIMIT.
>

Would only ever EXPECT to see a page size in bytes, never a LIMIT
specifying bytes.

I know the C-11745 ticket says LIMIT, too, but that feels very odd to me.

Re: [DISCUSS] The future of CREATE INDEX

[Jeff Jirsa]

Changes like this always scare me, but the benefits probably outweigh the
risks. Probably obviously to whoever implements but please make sure if
this happens is super visible in both NEWS and simultaneously updates the
to-string / to-cql representation of the schema in cqlsh / drivers /
snapshots

On Wed, May 10, 2023 at 8:27 PM Patrick McFadin  wrote:

> Having pulled a lot of developers out of the 2i fire, I would love it if
> defaults got a bit more sane. Adding USING...WITH... on CREATE INDEX
> seems like the right move for most developers that don't read docs and
> assume behavior.
>
> As much as I hate that 2i would be the configured default, I get it. New
> feature and this is the right thing for users. Would there be any way to
> switch 2i to SAI for the same index declaration? That would make for a nice
> upgrade for users moving to 5 without having to re-create indexes.
>
> Patrick
>
> On Wed, May 10, 2023 at 9:28 AM David Capwell  wrote:
>
>> Having to revert to CREATE CUSTOM INDEX sounds pretty awful, so I'd
>> prefer allowing USING...WITH... for CREATE INDEX
>>
>>
>> I have 0 issues with a new syntax to make this more clear
>>
>> just deprecating CREATE CUSTOM INDEX (at least after 5.0), but that's
>> more or less what my original proposal was above (modulo the configurable
>> default).
>>
>>
>> I have 0 issues deprecating and producing a ClientWarning recommending
>> the new syntax, but I would be against removing this syntax later on… it
>> should be low effort to keep, so breaking a user would not be desirable for
>> me.
>>
>> change only the fact that CREATE INDEX retains a configurable default
>>
>>
>> This option allows users to control this behavior, and allows us to
>> change the default over time.  For 5.0 I am strongly against SAI being the
>> default (new features disabled by default), but I wouldn’t have issues in
>> later versions changing the default once its been out for awhile.
>>
>> I’m not convinced by the changing defaults argument here. The
>> characteristics of the two index types are very different, and users with
>> scripts that make indexes today shouldn’t have their behaviour change.
>>
>>
>> In my mind this is no different from defaulting to BTI in a follow up
>> release, but if this concern is that the legacy index leaked details such
>> as index tables, so changing the default would have side effects in the
>> public domain that users might not expect, then I get it… are there other
>> concerns?
>>
>> On May 10, 2023, at 9:03 AM, Caleb Rackliffe 
>> wrote:
>>
>> tl;dr If you take my original proposal and change only the fact that CREATE
>> INDEX retains a configurable default, I think we get to the same place?
>>
>> (Then it's just a matter of what we do in 5.0 vs. after 5.0...)
>>
>> On Wed, May 10, 2023 at 11:00 AM Caleb Rackliffe <
>> calebrackli...@gmail.com> wrote:
>>
>>> I see a broad desire here to have a configurable (YAML) default
>>> implementation for CREATE INDEX. I'm not strongly opposed to that, as
>>> the concept of a default index implementation is pretty standard for most
>>> DBMS (see Postgres, etc.). However, keep in mind that if we do that, we
>>> still need to either revert to CREATE CUSTOM INDEX or add the
>>> USING...WITH... extensions to CREATE INDEX to override the default or
>>> specify parameters, which will be in play once SAI supports basic text
>>> tokenization/filtering. Having to revert to CREATE CUSTOM INDEX sounds
>>> pretty awful, so I'd prefer allowing USING...WITH... for CREATE INDEX
>>> and just deprecating CREATE CUSTOM INDEX (at least after 5.0), but
>>> that's more or less what my original proposal was above (modulo the
>>> configurable default).
>>>
>>> Thoughts?
>>>
>>> On Wed, May 10, 2023 at 2:59 AM Benedict  wrote:
>>>
 I’m not convinced by the changing defaults argument here. The
 characteristics of the two index types are very different, and users with
 scripts that make indexes today shouldn’t have their behaviour change.

 We could introduce new syntax that properly appreciates there’s no
 default index, perhaps CREATE LOCAL [type] INDEX? To also make clear that
 these indexes involve a partition key or scatter gather

 On 10 May 2023, at 06:26, guo Maxwell  wrote:

 
 +1 , as we must Improve the image of your own default indexing ability.

 and As for *CREATE CUSTOM INDEX *, should we just left as it is and we
 can disable the ability for create SAI through  *CREATE CUSTOM INDEX*  in
 some version after 5.0?

 for as I know there may be users using this as a plugin-index
 interface, like https://github.com/Stratio/cassandra-lucene-index
 (though these project may be inactive， But if someone wants to do something
 similar in the future, we don't have to stop).



 Jonathan Ellis  于2023年5月10日周三 10:01写道：

> +1 for this, especially in the long term.  CREATE INDEX should do the
> right thing for most people 

Re: [DISCUSS] New data type for vector search

[Jeff Jirsa]

On Thu, Apr 27, 2023 at 7:39 AM Jonathan Ellis  wrote:

> It's been a while, so I may be missing something, but do we already have
> fixed-size lists?  If not, I don't see why we'd try to make this fit into a
> List-shaped problem.
>

We do not. The proposal got closed as wont-fix
https://issues.apache.org/jira/browse/CASSANDRA-9110

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

[Jeff Jirsa]

KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated

DATABASE may be ambiguous, but it's ambiguity shared across the industry.

Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be unique to us in the world, and therefore unintuitive for new users.



On Tue, Apr 4, 2023 at 9:36 AM Josh McKenzie  wrote:

> I think there's competing dynamics here.
>
> 1) KEYSPACE isn't that great of a name; it's not a space in which keys are
> necessarily unique, and you can't address things just by key w/out their
> respective tables
> 2) DATABASE isn't that great of a name either due to the aforementioned
> ambiguity.
>
> Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better
> satisfy point 1 and 2 above but subjectively I kind of recoil at both
> equally. So there's that.
>
> On Tue, Apr 4, 2023, at 12:30 PM, Abe Ratnofsky wrote:
>
> I agree with Bowen - I find Keyspace easier to communicate with. There are
> plenty of situations where the use of "database" is ambiguous (like "Could
> you help me connect to database x?"), but Keyspace refers to a single
> thing. I think more software is moving towards calling these things
> "namespaces" (like Kubernetes), and while "Keyspaces" is not a term used in
> this way elsewhere, I still find it leads to clearer communication.
>
> --
> Abe
>
>
> On Apr 4, 2023, at 9:24 AM, Andrés de la Peña 
> wrote:
>
> I think supporting DATABASE is a great idea.
>
> It's better aligned with SQL databases, and can save new users one of the
> first troubles they find.
>
> Probably anyone starting to use Cassandra for the first time is going to
> face the what is a keyspace? question in the first minutes. Saving that to
> users with a more common name would be a victory for usability IMO.
>
> On Tue, 4 Apr 2023 at 16:48, Mike Adamson  wrote:
>
> Hi,
>
> I'd like to propose that we add DATABASE to the CQL grammar as an
> alternative to KEYSPACE.
>
> Background: While TABLE was introduced as an alternative for COLUMNFAMILY
> in the grammar we have kept KEYSPACE for the container name for a group of
> tables. Nearly all traditional SQL databases use DATABASE as the container
> name for a group of tables so it would make sense for Cassandra to adopt
> this naming as well.
>
> KEYSPACE would be kept in the grammar but we would update some logging and
> documentation to encourage use of the new name.
>
> Mike Adamson
>
> --
> [image: DataStax Logo Square] 
> *Mike Adamson*
> Engineering
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online:
> [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>
>

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

[Jeff Jirsa]

On Tue, Mar 28, 2023 at 7:30 AM Jeremiah D Jordan 
wrote:

> - Resources isolation. Having the said service running within the same JVM
> may negatively impact Cassandra storage's performance. It could be more
> beneficial to have them in Sidecar, which offers strong resource isolation
> guarantees.
>
>
> How does having this in a side car change the impact on “storage
> performance”?  The side car reading sstables will have the same impact on
> storage IO as the main process reading sstables.
>

This is true.


>  Given the sidecar is running on the same node as the main C* process, the
> only real resource isolation you have is in heap/GC?  CPU/Memory/IO are all
> still shared between the main C* process and the side car, and coordinating
> those across processes is harder than coordinating them within a single
> process. For example if we wanted to have the compaction throughput,
> streaming throughput, and analytics read throughput all tied back to a
> single disk IO cap, that is harder with an external process.
>

Relatively trivial, for CPU and memory, to run them in different
containers/cgroups/etc, so you can put an exact cpu/memory limit on the
sidecar. That's different from a jmx rate limiter/throttle, but (arguably)
more precise, because it actually limits the underlying physical resource
instead of a proxy for it in a config setting.



>
> - Complexity. Considering the existence of the Sidecar project, it would
> be less complex to avoid adding another (http?) service in Cassandra.
>
>
> Not sure that is really very complex, running an http service is a pretty
> easy?  We already have netty in use to instantiate one from.
> I worry more about the complexity of having the matching schema for a set
> of sstables being read.  The complexity of new sstable versions/formats
> being introduced.  The complexity of having up to date data from memtables
> being considered by this API without having to flush before every query of
> it.  The complexity of dealing with the new memtable API introduced in
> CEP-11.  The complexity of coordinating compaction/streaming adding and
> removing files with these APIs reading them.  There are a lot of edge cases
> to consider for this external access to sstables that the main process
> considers itself the “owner” of.
>
> All of this is not to say that I think separating things out into other
> processes/services is bad.  But I think we need to be very careful with how
> we do it, or end users will end up running into all the sharp edges and the
> feature will fail.
>
> -Jeremiah
>
> On Mar 24, 2023, at 8:15 PM, Yifan Cai  wrote:
>
> Hi Jeremiah,
>
> There are good reasons to not have these inside Cassandra. Consider the
> following.
> - Resources isolation. Having the said service running within the same JVM
> may negatively impact Cassandra storage's performance. It could be more
> beneficial to have them in Sidecar, which offers strong resource isolation
> guarantees.
> - Availability. If the Cassandra cluster is being bounced, using sidecar
> would not affect the SBR/SBW functionality, e.g. SBR can still read
> SSTables via sidecar endpoints.
> - Compatibility. Sidecar provides stable REST-based APIs, such as
> uploading SSTables endpoint, which would remain compatible with different
> versions of Cassandra. The current implementation supports versions 3.0 and
> 4.0.
> - Complexity. Considering the existence of the Sidecar project, it would
> be less complex to avoid adding another (http?) service in Cassandra.
> - Release velocity. Sidecar, as an independent project, can have a quicker
> release cycle from Cassandra.
> - The features in sidecar are mostly implemented based on various existing
> tools/APIs exposed from Cassandra, e.g. ring, commit sstable, snapshot, etc.
>
> Regarding authentication and authorization
> - We will add it as a follow-on CEP in Sidecar, but we don't want to hold
> up this CEP. It would be a feature that benefits all Sidecar endpoints.
>
> - Yifan
>
> On Fri, Mar 24, 2023 at 2:43 PM Doug Rohrer  wrote:
>
>> I agree that the analytics library will need to support vnodes. To be
>> clear, there’s nothing preventing the solution from working with vnodes
>> right now, and no assumptions about a 1:1 topology between a token and a
>> node. However, we don’t, today, have the ability to test vnode support
>> end-to-end. We are working towards that, however, and should be able to
>> remove the caveat from the released analytics library once we can properly
>> test vnode support.
>> If it helps, I can update the CEP to say something more like “Caveat:
>> Currently untested with vnodes - work is ongoing to remove this limitation”
>> if that helps?
>>
>> Doug
>>
>> > On Mar 24, 2023, at 11:43 AM, Brandon Williams 
>> wrote:
>> >
>> > On Fri, Mar 24, 2023 at 10:39 AM Jeremiah D Jordan
>> >  wrote:
>> >>
>> >> I have concerns with the majority of this being in the sidecar and not
>> in the database itself.  I think it would make sense for the 

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

[Jeff Jirsa]

I’m without laptop this week but looks like 
CompactionTask#reduceScopeForLimitedSpace

So maybe it just comes for free with UCS 


> On Mar 17, 2023, at 6:21 PM, Jeremy Hanna  wrote:
> 
> You're right that it doesn't handle it in the sense that it doesn't resolve 
> it the problem, but it also doesn't do what STCS does.  From what I've seen, 
> STCS blindly tries to compact and then the disk will fill up triggering the 
> disk failure policy.  With UCS it's much less likely and if it does happen, 
> my understanding is that it will skip the compaction.  I didn't realize that 
> LCS would try to reduce the scope of the compaction.  I can't find in the 
> branch where it handles that.
> 
> Branimir, can you point to where it handles the scenario?
> 
> Thanks,
> 
> Jeremy
> 
>>> On Mar 17, 2023, at 4:52 PM, Jeff Jirsa  wrote:
>>> 
>>> 
>>> 
>>>> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna  
>>>> wrote:
>>> 
>>> 
>>> 
>>> One much more graceful element of UCS is that instead of what was 
>>> previously done with compaction strategies where the server just shuts down 
>>> when running out of space - forcing system administrators to be paranoid 
>>> about headroom.  Instead UCS has a target overhead (default 20%).  First 
>>> since the ranges are sharded, it makes it less likely that there will be 
>>> large sstables that need to get compacted to require as much headroom, but  
>>> if it detects that there is a compaction that will violate the target 
>>> overhead, it will log that and skip the compaction - a much more graceful 
>>> way of handling it.
>> 
>> Skipping doesn’t really handle it though? 
>> 
>> If you have a newly flushed sstable full of tombstones and it naturally 
>> somehow triggers you to exceed that target overhead you never free that 
>> space? Usually LCS would try to reduce the scope of the compaction, and I 
>> assume UCS will too? 
>> 
>> 
> 

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

[Jeff Jirsa]

> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna  wrote:
> 
> 
> 
> One much more graceful element of UCS is that instead of what was previously 
> done with compaction strategies where the server just shuts down when running 
> out of space - forcing system administrators to be paranoid about headroom.  
> Instead UCS has a target overhead (default 20%).  First since the ranges are 
> sharded, it makes it less likely that there will be large sstables that need 
> to get compacted to require as much headroom, but  if it detects that there 
> is a compaction that will violate the target overhead, it will log that and 
> skip the compaction - a much more graceful way of handling it.

Skipping doesn’t really handle it though? 

If you have a newly flushed sstable full of tombstones and it naturally somehow 
triggers you to exceed that target overhead you never free that space? Usually 
LCS would try to reduce the scope of the compaction, and I assume UCS will too? 

Re: [DISCUSS] Enhanced Disk Error Handling

[Jeff Jirsa]

On Wed, Mar 8, 2023 at 5:25 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:
>
>1. The safer, but slower recover strategy: replace the entire node.
>2. 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?
>

In a database with a shard manager rather than token range, you'd mark that
shard as dead and re-replicate it.

With the token range, if you COULD mark that token range as dead, and
re-bootstrap it (which today means a repair of the range followed by a
stream from a source that's not corrupt), you could do the same thing, but
there's no current way to mark that range as offline on a specific replica.

When transactional metadata ( CEP-21 ) is done, a future version of it
should make sure we eventually allow us to move past the token ring to
something that approximates this for cassandra (because doing so would also
allow us to expand/shrink faster, and handle other types of hot-ranges
better as well).

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

[Jeff Jirsa]

Anyone have stats on how many people use RF > 3 per dc? (I know what it looks like in my day job but I don’t want to pretend it’s representative of the larger community) I’m a fan of fixing this but I do wonder how common this is in the wild. On Mar 7, 2023, at 9:12 AM, Derek Chen-Becker  wrote:I think that the warning would only be thrown in the case where a potentially QUORUM-busting configuration is used. I think it would be a worse experience to not warn and let the user discover later when they can't write at QUORUM.Cheers,DerekOn Tue, Mar 7, 2023 at 9:32 AM Jeremiah D Jordan  wrote:I agree with Paulo, it would be nice if we could figure out some way to make new NTS work correctly, with a parameter to fall back to the “bad” behavior, so that people restoring backups to a new cluster can get the right behavior to match their backups.
The problem with only fixing this in a new strategy is we have a ton of tutorials and docs out there which tell people to use NTS, so it would be great if we could keep “use NTS” as the recommendation.  Throwing a warning when someone uses NTS is kind of user hostile.  If someone just read some tutorial or doc which told them “make your key space this way” and then when they do that the database yells at them telling them they did it wrong, it is not a great experience.

-Jeremiah

> On Mar 7, 2023, at 10:16 AM, Benedict  wrote:
> 
> My view is that if this is a pretty serious bug. I wonder if transactional metadata will make it possible to safely fix this for users without rebuilding (only via opt-in, of course).
> 
>> On 7 Mar 2023, at 15:54, Miklosovic, Stefan  wrote:
>> 
>> Thanks everybody for the feedback.
>> 
>> I think that emitting a warning upon keyspace creation (and alteration) should be enough for starters. If somebody can not live without 100% bullet proof solution over time we might choose some approach from the offered ones. As the saying goes there is no silver bullet. If we decide to implement that new strategy, we would probably emit warnings anyway on NTS but it would be already done so just new strategy would be provided.
>> 
>> 
>> From: Paulo Motta 
>> Sent: Monday, March 6, 2023 17:48
>> To: dev@cassandra.apache.org
>> Subject: Re: Degradation of availability when using NTS and RF > number of racks
>> 
>> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>> 
>> 
>> 
>> It's a bit unfortunate that NTS does not maintain the ability to lose a rack without loss of quorum for RF > #racks > 2, since this can be easily achieved by evenly placing replicas across all racks.
>> 
>> Since RackAwareTopologyStrategy is a superset of NetworkTopologyStrategy, can't we just use the new correct placement logic for newly created keyspaces instead of having a new strategy?
>> 
>> The placement logic would be backwards-compatible for RF <= #racks. On upgrade, we could mark existing keyspaces with RF > #racks with use_legacy_replica_placement=true to maintain backwards compatibility and log a warning that the rack loss guarantee is not maintained for keyspaces created before the fix. Old keyspaces with RF <=#racks would still work with the new replica placement. The downside is that we would need to keep the old NTS logic around, or we could eventually deprecate it and require users to migrate keyspaces using the legacy placement strategy.
>> 
>> Alternatively we could have RackAwareTopologyStrategy and fail NTS keyspace creation for RF > #racks and indicate users to use RackAwareTopologyStrategy to maintain the quorum guarantee on rack loss or set an override flag "support_quorum_on_rack_loss=false". This feels a bit iffy though since it could potentially confuse users about when to use each strategy.
>> 
>> On Mon, Mar 6, 2023 at 5: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 

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

[Jeff Jirsa]

A huge number of people use this legal and unsafe combination - like anyone
running RF=3 in AWS us-west-1 (or any other region with only 2 accessible
AZs), and no patch is going to suddenly make that safe, and banning it
hurts users a lot.

If we're really going to ship a less-bad version of this, then that
less-bad version probably wants to reject invalid configs (like RF=3 with 2
racks), but again, it'll be approximately impossible for anyone to document
what it takes to move from the maybe-unsafe version to the definitely-safe
version without rewriting all of the data into the cluster, so most people
won't be able to use it anyway?





On Mon, Mar 6, 2023 at 8:31 AM Derek Chen-Becker 
wrote:

> 1) It does seem a like a big footgun. I think it violates the principle of
> least surprise if someone has configured NTS thinking that they are
> improving availability
> 2) I don't know that we want to ban it outright, since maybe there's a
> case for someone to be using a different CL that would be OK with the loss
> of a majority of replicas (e.g. ONE). For example, we don't fail if someone
> uses ALL or EACH_QUORUM with a problematic setup, do we? Would we warn on
> keyspace creation with RF > racks or are you suggesting that the warning
> would be at query time?
> 3) agreed, this doesn't seem like an enhancement as much as it is
> identifying legal but likely incorrect configuration
>
> Cheers,
>
> Derek
>
> On Mon, Mar 6, 2023 at 3:52 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> 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
>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

Re: Downgradability

[Jeff Jirsa]

When people are serious about this requirement, they’ll build the downgrade equivalents of the upgrade tests and run them automatically, often, so people understand what the real gap is and when something new makes it break Until those tests exist, I think collectively we should all stop pretending like this is dogma. Best effort is best effort. On Feb 22, 2023, at 6:57 AM, Branimir Lambov  wrote:> 1. Major SSTable changes should begin with forward-compatibility in a prior release.This requires "feature" changes, i.e. new non-trivial code for previous patch releases. It also entails porting over any further format modification.Instead of this, in combination with your second point, why not implement backwards write compatibility? The opt-in is then clearer to define (i.e. upgrades start with e.g. a "4.1-compatible" settings set that includes file format compatibility and disabling of new features, new nodes start with "current" settings set). When the upgrade completes and the user is happy with the result, the settings set can be replaced.Doesn't this achieve what you want (and we all agree is a worthy goal) with much less effort for everyone? Supporting backwards-compatible writing is trivial, and we even have a proof-of-concept in the stats metadata serializer. It also simplifies by a serious margin the amount of work and thinking one has to do when a format improvement is implemented -- e.g. the TTL patch can just address this in exactly the way the problem was addressed in earlier versions of the format, by capping to 2038, without any need to specify, obey or test any configuration flags.>> It’s a commitment, and it requires every contributor to consider it as part of work they produce.> But it shouldn't be a burden. Ability to downgrade is a testable problem, so I see this work as a function of the suite of tests the project is willing to agree on supporting.I fully agree with this sentiment, and I feel that the current "try to not introduce breaking changes" approach is adding the burden, but not the benefits -- because the latter cannot be proven, and are most likely already broken.Regards,BranimirOn Wed, Feb 22, 2023 at 1:01 AM Abe Ratnofsky  wrote:Some interesting existing work on this subject is "Understanding and Detecting Software Upgrade Failures in Distributed Systems" - https://dl.acm.org/doi/10.1145/3477132.3483577, also summarized by Andrey Satarin here: https://asatarin.github.io/talks/2022-09-upgrade-failures-in-distributed-systems/They specifically tested Cassandra upgrades, and have a solid list of defects that they found. They also describe their testing mechanism DUPTester, which includes a component that confirms that the leftover state from one version can start up on the next version. There is a wider scope of upgrade defects highlighted in the paper, beyond SSTable version support.I believe the project would benefit from expanding our test suite similarly, by parametrizing more tests on upgrade version pairs.Also, per Benedict's comment:> It’s a commitment, and it requires every contributor to consider it as part of work they produce.But it shouldn't be a burden. Ability to downgrade is a testable problem, so I see this work as a function of the suite of tests the project is willing to agree on supporting.Specifically - I agree with Scott's proposal to emulate the HDFS upgrade-then-finalize approach. I would also support automatic finalization based on a time threshold or similar, to balance the priorities of safe and straightforward upgrades. Users need to be aware of the range of SSTable formats supported by a given version, and how to handle when their SSTables wouldn't be supported by an upcoming upgrade.--Abe--  
 Branimir Lambov
 
 e.
 branimir.lam...@datastax.com
 w. www.datastax.com

Re: Downgradability

[Jeff Jirsa]

I'm not even convinced even 8110 addresses this - just writing sstables in
old versions won't help if we ever add things like new types or new types
of collections without other control abilities. Claude's other email in
another thread a few hours ago talks about some of these surprises -
"Specifically during the 3.1 -> 4.0 changes a column broadcast_port was
added to system/local.  This means that 3.1 system can not read the table
as it has no definition for it.  I tried marking the column for deletion in
the metadata and in the serialization header.  The later got past the
column not found problem, but I suspect that it just means that data
columns after broadcast_port shifted and so incorrectly read." - this is a
harder problem to solve than just versioning sstables and network
protocols.

Stepping back a bit, we have downgrade ability listed as a goal, but it's
not (as far as I can tell) universally enforced, nor is it clear at which
point we will be able to concretely say "this release can be downgraded to
X".   Until we actually define and agree that this is a real goal with a
concrete version where downgrade-ability becomes real, it feels like things
are somewhat arbitrarily enforced, which is probably very frustrating for
people trying to commit work/tickets.

- Jeff



On Mon, Feb 20, 2023 at 11:48 AM Dinesh Joshi  wrote:

> I’m a big fan of maintaining backward compatibility. Downgradability
> implies that we could potentially roll back an upgrade at any time. While I
> don’t think we need to retain the ability to downgrade in perpetuity it
> would be a good objective to maintain strict backward compatibility and
> therefore downgradability until a certain point. This would imply
> versioning metadata and extending it in such a way that prior version(s)
> could continue functioning. This can certainly be expensive to implement
> and might bloat on-disk storage. However, we could always offer an option
> for the operator to optimize the on-disk structures for the current version
> then we can rewrite them in the latest version. This optimizes the storage
> and opens up new functionality. This means new features that can work with
> old on-disk structures will be available while others that strictly require
> new versions of the data structures will be unavailable until the operator
> migrates to the new version. This migration IMO should be irreversible.
> Beyond this point the operator will lose the ability to downgrade which is
> ok.
>
> Dinesh
>
> On Feb 20, 2023, at 10:40 AM, Jake Luciani  wrote:
>
> 
> There has been progress on
> https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-8928
>
> Which is similar to what datastax does for DSE. Would this be an
> acceptable solution?
>
> Jake
>
> On Mon, Feb 20, 2023 at 11:17 AM guo Maxwell  wrote:
>
>> It seems “An alternative solution is to implement/complete CASSANDRA-8110
>> ” can give us more
>> options if it is finished
>>
>> Branimir Lambov 于2023年2月20日 周一下午11:03写道：
>>
>>> Hi everyone,
>>>
>>> There has been a discussion lately about changes to the sstable format
>>> in the context of being able to abort a cluster upgrade, and the fact that
>>> changes to sstables can prevent downgraded nodes from reading any data
>>> written during their temporary operation with the new version.
>>>
>>> Most of the discussion is in CASSANDRA-18134
>>> , and is
>>> spreading into CASSANDRA-14277
>>>  and
>>> CASSANDRA-17698 ,
>>> none of which is a good place to discuss the topic seriously.
>>>
>>> Downgradability is a worthy goal and is listed in the current roadmap. I
>>> would like to open a discussion here on how it would be achieved.
>>>
>>> My understanding of what has been suggested so far translates to:
>>> - avoid changes to sstable formats;
>>> - if there are changes, implement them in a way that is
>>> backwards-compatible, e.g. by duplicating data, so that a new version is
>>> presented in a component or portion of a component that legacy nodes will
>>> not try to read;
>>> - if the latter is not feasible, make sure the changes are only applied
>>> if a feature flag has been enabled.
>>>
>>> To me this approach introduces several risks:
>>> - it bloats file and parsing complexity;
>>> - it discourages improvement (e.g. CASSANDRA-17698 is no longer a LHF
>>> ticket once this requirement is in place);
>>> - it needs care to avoid risky solutions to address technical issues
>>> with the format versioning (e.g. staying on n-versions for 5.0 and needing
>>> a bump for a 4.1 bugfix might require porting over support for new
>>> features);
>>> - it requires separate and uncoordinated solutions to the problem and
>>> switching mechanisms for each individual change.
>>>
>>> An alternative solution is to implement/complete 

Re: [VOTE] CEP-21 Transactional Cluster Metadata

[Jeff Jirsa]

+1


On Mon, Feb 6, 2023 at 8:16 AM Sam Tunnicliffe  wrote:

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

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[Jeff Jirsa]

Usually requires an offer to donate from the current owner, an acceptance
of that offer (PMC vote), and then the work to ensure that contributions
are acceptable from a legal standpoint (e.g. like the incubator -
https://incubator.apache.org/guides/transitioning_asf.html - "For
contributions composed of patches from individual contributors, it is safe
to import the code once the major contributors (by volume) have completed
ICLAs or SGAs.").



On Mon, Jan 30, 2023 at 10:53 AM German Eichberger via dev <
dev@cassandra.apache.org> wrote:

> Great news indeed. I am wondering what it would take to include projects
> everyone is using like medusa, reaper, cassandra-ldap, etc. as a subproject.
>
> Thanks,
> German
> --
> *From:* Francisco Guerrero 
> *Sent:* Friday, January 27, 2023 9:46 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [ANNOUNCE] Evolving governance in the Cassandra
> Ecosystem
>
> Great news! I'm very happy to see these changes coming soon.
>
> Thanks to everyone involved in this work.
>
> On 2023/01/26 21:21:01 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D95652224=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xUbCe%2FQGgZq3Ynr42YQucMkOw1IZ67cONiQSnkZI7bk%3D=0)
> and Cassandra-14395 (
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRASC-24=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RdItVOzwVs865Xd%2Ff8ancwkTDJWKPosHlKgbl1uysMw%3D=0),
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY%2Fedit%23heading%3Dh.xhizycgqxoyo=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cda65de0ac4d84d94c54708db008e897d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638104384430582894%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=pUXo983DEHRBDtjGD%2FHaZnqc1uRwpS7tBkFkNF9Qfns%3D=0),
> 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: Merging CEP-15 to trunk

[Jeff Jirsa]

 But it's not merge-than-review, because they've already been reviewed,
before being merged to the feature branch, by committers (actually PMC
members)?

You want code that's been written by one PMC member and reviewed by 2 other
PMC members to be put up for review by some random 4th party? For how long?


On Mon, Jan 23, 2023 at 2:54 PM Mick Semb Wever  wrote:

> The sooner it’s in trunk, the more eyes it will draw, IMO, if you are
>> right about most contributors not having paid attention to a feature branch.
>>
>
>
> We all agree we want the feature branch incrementally merged sooner rather
> than later.
> IMHO any merge to trunk, and any rebase and squash of ninja-fix commits,
> deserves an invite to reviewers.
> Any notion of merge-then-review isn't our community precedent.
>
> I appreciate the desire to not "be left hanging" by creating a merge
> ticket that requires a reviewer when no reviewer shows. And the desire to
> move quickly on this.
>
> I don't object if you wish to use this thread as that review process. On
> the other hand, if you create the ticket I promise to be a reviewer of it,
> so as not to delay.
>
>
>

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

[Jeff Jirsa]

Concurrent shouldn’t matter (they’re non-overlapping in the repro). And I’d personally be a bit surprised if table count matters that much. It probably just requires high core count and enough data that the streams actually interact with the rate limiter On Dec 11, 2022, at 10:32 AM, Mick Semb Wever  wrote:On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky  wrote:Sorry - responded on the take1 thread:Could we defer the close of this vote til Monday, December 12th after 6pm Pacific Time?Jon Meredith and I have been working thru an issue blocking streaming on 4.1 for the last couple months, and are now testing a promising fix. We're currently working on a write-up, and we'd like to hold the release until the community is able to review our findings.Update on behalf of Jon and Abe.The issue raised is CASSANDRA-18110.Concurrent, or nodes with high cpu count and number of tables performing, host replacements can fail.It is still unclear if this is applicable to OSS C*, and if so to what extent users might ever be impacted.More importantly, there's a simple workaround for anyone that hits the problem.Without further information on the table, I'm inclined to continue with 4.1.0 GA (closing the vote in 32 hours), but add a clear message to the release announcement of the issue and workaround. Interested in hearing others' positions, don't be afraid to veto if that's where you're at.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Jeff Jirsa]

On Thu, Nov 17, 2022 at 12:47 PM J. D. Jordan 
wrote:

> -1 on providing a bunch of choices and forcing users to pick one. We
> should have a default and it should be “good enough” for most people. The
> people who want to dig in and try other gc settings can still do it, and we
> could provide them some profiles to start from, but there needs to be a
> default.  We need to be asking new operators less questions on install, not
> more.
>
> Re:experience with Shenandoah under high load, I have in the past seen the
> exact same thing for both Shenandoah and ZGC. Both of them have issues at
> high loads while performing great at moderate loads. I have not seen G1
> ever have such issues. So I would not be fine with a switch to Shenandoah
> or ZGC as the default without extensive testing on current JVM versions
> that have hopefully improved the behavior under load
>


I have personally reverted hundreds of machines off of G1 with 12G heaps on
jdk8, where (intelligently tuned) CMS with the same workload/heap size was
fine.

It was many years ago, and G1 has changed a lot, but the "zero problems
with G1" is AT LEAST 1 problem with G1, by someone who knew how both
Cassandra and the JVM works.

Re: Should we change 4.1 to G1 and offheap_objects ?

[Jeff Jirsa]

I'll withdraw my comment about friendliness of g1 vs cms. I think it's too
late to sneak it in, but wouldn't object formally.

offheap_objects is way too late to change given we shipped the alpha in May
and there are known, long lived bugs that multiple users have reported and
wouldn't have been tested in the alpha, so I'd vote -1 on a release with
that change on the basis that we hadn't done a valid alpha/beta/testing
with that config.





On Thu, Nov 10, 2022 at 8:56 AM Jon Haddad 
wrote:

> +1 to switching to G1.
>
> No opinion about offheap objects.
>
> On 2022/11/09 19:22:08 Mick Semb Wever wrote:
> > Any objections to making these changes, at the very last minute, for
> > 4.1-rc1 ?
> > This is CASSANDRA-12029 and CASSANDRA-7486
> >
> > Provided we figure out patches for them in the next day or two.
> >
>

Re: Should we change 4.1 to G1 and offheap_objects ?

[Jeff Jirsa]

G1 you can argue for with the changes in the JDK, though it's MUCH  less
friendly to small heaps (e.g. probably our default simple user).

Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd be useful, but I'm pretty sure that's not true, and bugs
like https://issues.apache.org/jira/browse/CASSANDRA-12125  (which remains
undiagnosed) reinforce that it's less commonly used and may have latent
undiscovered bugs for default users.





On Wed, Nov 9, 2022 at 11:23 AM Mick Semb Wever  wrote:

> Any objections to making these changes, at the very last minute, for
> 4.1-rc1 ?
> This is CASSANDRA-12029 and CASSANDRA-7486
>
> Provided we figure out patches for them in the next day or two.
>

Re: [Discuss] CEP-24 Password validation and generation

[Jeff Jirsa]

I don't think logging which policy violation was triggered is that big of
an ask?

"Password changed for user X, complying with policies (reuse, complexity,
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR: Password rejected due to policy violation (entropy)"

The success log makes it much easier for users subject to audit controls,
and the failures make it much easier to tell users what's going on for
those users who operate the database for other people.




On Tue, Oct 11, 2022 at 11:48 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> I am afraid this is way out of scope of this CEP. I think we would be the
> very first on the database scene to offer such low-level and fine-grained
> information. I am not persuaded that this is something we should be giving
> a lot of attention right now. We have "cassandra / cassandra" credentials
> combo as default, I would say that is more important to deal with right now
> than providing very detailed information about what kind of passwords
> people are using.
>
> Thank you very much for (not only your) insights. This is very important
> feedback and I am glad you participate in this thread. I will try to
> summarize where we are as it is easy to get lost in these emails.
>
> 
> From: Derek Chen-Becker 
> Sent: Tuesday, October 11, 2022 18:59
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> Speaking with my operator hat on, I would want to know if there's a common
> pattern that my end users hit so that I can better educate them or provide
> tools (e.g. vaults) to help them manage the required complexity.
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 10:06 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> "but we should consider logging why it was rejected."
>
> Why? What is the use case? Why is it important for you to know what
> somebody tried to create a role with password "aa" (it will not be
> shown), just mentioning that they tried to create a password with a lot of
> repeating characters? What is the added value here?
>
> I need to double check if warnings are logged as well. I'll get back to
> you.
>
>
> 
> From: Derek Chen-Becker  de...@chen-becker.org>>
> Sent: Tuesday, October 11, 2022 17:47
> To: dev@cassandra.apache.org
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> I know we log that the password change attempt was made, but we should
> consider logging why it was rejected. As part of that, we may want to
> consider how we format that message to make it easy for an auditing system
> to parse. We should never log the actual password, or even a redacted
> version; apologies if it sounded like I was suggesting that.
>
> Cheers,
>
> Derek
>
> On Tue, Oct 11, 2022 at 9:36 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com stefan.mikloso...@netapp.com>> wrote:
> I dont follow, sorry. What logs do you mean? What would you like to see?
>
> The auditing framework we already do have in place will log that somebody
> tried to create (or alter) a role with this and that password and it failed
> (password would be redacted). If you use "with generated password", that
> password will not be even shown in audit log. I am not completely sure if
> the warning is logged too if password is not valid (I do think that only
> CQL command itself is audit-logged).
>
> The configuration of validator is in cassandra.yaml. Folks can review that?
>
> I am sorry if I am missing something here, could you expand what you mean?
>
> To Josh:
>
> You are probably right but it is so easy to bypass that it is questionable
> why it is actually there. All it takes is to do "alter role myself with
> generated password" (literally), 5 times in a row and you can set the
> original one back. One positive fact is that such password, even same as
> the original one, would still have to be valid, but it just might be same
> as it was.
>
> 
> From: Derek Chen-Becker  de...@chen-becker.org>>>
> Sent: Tuesday, October 11, 2022 17:14
> To: dev@cassandra.apache.org dev@cassandra.apache.org>
> Subject: Re: [Discuss] CEP-24 Password validation and generation
>
> NetApp Security WARNING: This 

Re: CEP-15 multi key transaction syntax

[Jeff Jirsa]

I expect that a lot of use cases will update M and insert into N tables
based on one condition, so if that's a problem with the grammar today, I
think it'd probably be worth the time to sort that out?



On Wed, Sep 21, 2022 at 12:42 PM David Capwell  wrote:

> Caleb is making great progress on this, and I have been working on CQL
> fuzz testing the new grammar to make sure we flesh out cases quickly; one
> thing we hit was about mixing conditional and non-conditional updates; will
> use a example to better show
>
> BEGIN TRANSACTION
>   LET a = (SELECT * FROM ….);
>   IF a IS NOT NULL THEN
> UPDATE …;
>   END IF
>   INSERT INTO ...
> COMMIT TRANSACTION
>
> In this case we have 1 UPDATE tied to the IF condition, and one INSERT
> that isn’t… for v1 do we need/want to support this, or is it best for v1 to
> be simple and have all updates tied to conditional when present?
>
> On Aug 22, 2022, at 9:19 AM, Avi Kivity via dev 
> wrote:
>
> I wasn't referring to specific syntax but to the concept. If a SQL dialect
> (or better, the standard) has a way to select data into a variable, let's
> adopt it.
>
> If such syntax doesn't exist, LET (a, b, c) = (SELECT x, y, z FROM tab) is
> my preference.
>
> On 8/22/22 19:13, Patrick McFadin wrote:
>
> The replies got trashed pretty badly in the responses.
> When you say: "Agree it's better to reuse existing syntax than invent new
> syntax."
>
> Which syntax are you referring to?
>
> Patrick
>
>
> On Mon, Aug 22, 2022 at 1:36 AM Avi Kivity via dev <
> dev@cassandra.apache.org> wrote:
>
>> Agree it's better to reuse existing syntax than invent new syntax.
>>
>> On 8/21/22 16:52, Konstantin Osipov wrote:
>> > * Avi Kivity via dev  [22/08/14 15:59]:
>> >
>> > MySQL supports SELECT  INTO  FROM ... WHERE
>> > ...
>> >
>> > PostgreSQL supports pretty much the same syntax.
>> >
>> > Maybe instead of LET use the ANSI/MySQL/PostgreSQL DECLARE var TYPE and
>> > MySQL/PostgreSQL SELECT ... INTO?
>> >
>> >> On 14/08/2022 01.29, Benedict Elliott Smith wrote:
>> >>> 
>> >>> I’ll do my best to express with my thinking, as well as how I would
>> >>> explain the feature to a user.
>> >>>
>> >>> My mental model for LET statements is that they are simply SELECT
>> >>> statements where the columns that are selected become variables
>> >>> accessible anywhere in the scope of the transaction. That is to say,
>> you
>> >>> should be able to run something like s/LET/SELECT and
>> >>> s/([^=]+)=([^,]+)(,|$)/\2 AS \1\3/g on the columns of a LET statement
>> >>> and produce a valid SELECT statement, and vice versa. Both should
>> >>> perform identically.
>> >>>
>> >>> e.g.
>> >>> SELECT pk AS key, v AS value FROM table
>> >>>
>> >>> =>
>> >>> LET key = pk, value = v FROM table
>> >>
>> >> "=" is a CQL/SQL operator. Cassandra doesn't support it yet, but SQL
>> >> supports selecting comparisons:
>> >>
>> >>
>> >> $ psql
>> >> psql (14.3)
>> >> Type "help" for help.
>> >>
>> >> avi=# SELECT 1 = 2, 3 = 3, NULL = NULL;
>> >>   ?column? | ?column? | ?column?
>> >> --+--+--
>> >>   f| t|
>> >> (1 row)
>> >>
>> >>
>> >> Using "=" as a syntactic element in LET would make SELECT and LET
>> >> incompatible once comparisons become valid selectors. Unless they
>> become
>> >> mandatory (and then you'd write "LET q = a = b" if you wanted to
>> select a
>> >> comparison).
>> >>
>> >>
>> >> I personally prefer the nested query syntax:
>> >>
>> >>
>> >>  LET (a, b, c) = (SELECT foo, bar, x+y FROM ...);
>> >>
>> >>
>> >> So there aren't two similar-but-not-quite-the-same syntaxes. SELECT is
>> >> immediately recognizable by everyone as a query, LET is not.
>> >>
>> >>
>> >>> Identical form, identical behaviour. Every statement should be
>> directly
>> >>> translatable with some simple text manipulation.
>> >>>
>> >>> We can then make this more powerful for users by simply expanding
>> SELECT
>> >>> statements, e.g. by permitting them to declare constants and tuples in
>> >>> the column results. In this scheme LET x = * is simply syntactic sugar
>> >>> for LET x = (pk, ck, field1, …) This scheme then supports options 2, 4
>> >>> and 5 all at once, consistently alongside each other.
>> >>>
>> >>> Option 6 is in fact very similar, but is strictly less flexible for
>> the
>> >>> user as they have no way to declare multiple scalar variables without
>> >>> scoping them inside a tuple.
>> >>>
>> >>> e.g.
>> >>> LET key = pk, value = v FROM table
>> >>> IF key > 1 AND value > 1 THEN...
>> >>>
>> >>> =>
>> >>> LET row = SELECT pk AS key, v AS value FROM table
>> >>> IF row.key > 1 AND row.value > 1 THEN…
>> >>>
>> >>> However, both are expressible in the existing proposal, as if you
>> prefer
>> >>> this naming scheme you can simply write
>> >>>
>> >>> LET row = (pk AS key, v AS value) FROM table
>> >>> IF row.key > 1 AND row.value > 1 THEN…
>> >>>
>> >>> With respect to auto converting single column results to a scalar, we
>> do
>> >>> need a way for the user to say they care 

Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

[Jeff Jirsa]

“ The proposed mechanism for dealing with both of these failure types is to 
enable a manual operator override mode. This would allow operators to inject 
metadata changes (potentially overriding the complete metadata state) directly 
on any and all nodes in a cluster. At the most extreme end of the spectrum, 
this could allow an unrecoverably corrupt state to be rectified by composing a 
custom snapshot of cluster metadata and uploading it to all nodes in the 
cluster”

What do you expect this to look like in practice? JSON representation of the 
ring? Would reads and writes have halted? In what situations would the database 
be entirely unavailable? 



> On Aug 22, 2022, at 11:15 AM, Derek Chen-Becker  wrote:
> 
> 
> This looks really interesting; thanks for putting this together! Just so I'm 
> clear on CEP nomenclature, having external management of metadata as a 
> non-goal doesn't preclude some future use, correct? Coincidentally, I'm 
> working on my ApacheCon talk on improving modularity in Cassandra and one of 
> the ideas I'm discussing is pluggably (?) replacing gossip with something(s) 
> that allow us to externalize some of the complexity of maintaining 
> consistency. I need to digest the proposal you've made, but I don't see the 
> two ideas being at odds on my first read. 
> 
> Cheers,
> 
> Derek
> 
>> On Mon, Aug 22, 2022 at 6:45 AM Sam Tunnicliffe  wrote:
>> Hi,
>> 
>> I'd like to open discussion about this CEP: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
>>
>> Cluster metadata in Cassandra comprises a number of disparate elements 
>> including, but not limited to, distributed schema, topology and token 
>> ownership. Following the general design principles of Cassandra, the 
>> mechanisms for coordinating updates to cluster state have favoured eventual 
>> consistency, with probabilisitic delivery via gossip being a prime example. 
>> Undoubtedly, this approach has benefits, not least in terms of resilience, 
>> particularly in highly fluid distributed environments. However, this is not 
>> the reality of most Cassandra deployments, where the total number of nodes 
>> is relatively small (i.e. in the low thousands) and the rate of change tends 
>> to be low.  
>> 
>> Historically, a significant proportion of issues affecting operators and 
>> users of Cassandra have been due, at least in part, to a lack of strongly 
>> consistent cluster metadata. In response to this, we propose a design which 
>> aims to provide linearizability of metadata changes whilst ensuring that the 
>> effects of those changes are made visible to all nodes in a strongly 
>> consistent manner. At its core, it is also pluggable, enabling 
>> Cassandra-derived projects to supply their own implementations if desired.
>> 
>> In addition to the CEP document itself, we aim to publish a working 
>> prototype of the proposed design. Obviously, this does not implement the 
>> entire proposal and there are several parts which remain only partially 
>> complete. It does include the core of the system, including a good deal of 
>> test infrastructure, so may serve as both illustration of the design and a 
>> starting point for real implementation. 
>> 
> 
> 
> -- 
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
> 

Re: [DISCUSS] CEP-20: Dynamic Data Masking

[Jeff Jirsa]

This type of feature is very useful, but it may be easier to analyze this 
proposal if it’s compared with other DDM implementations from other databases? 
Would it be reasonable to add a table to the proposal comparing syntax and 
output from eg Azure SQL vs Cassandra vs whatever ? 


> On Aug 19, 2022, at 4:50 AM, Andrés de la Peña  wrote:
> 
> 
> Hi everyone,
> 
> I'd like to start a discussion about this proposal for dynamic data masking: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking
> 
> Dynamic data masking allows to obscure sensitive information without changing 
> the stored data. It would be based on a set of native CQL functions providing 
> different types of masking, such as replacing the column value by "". 
> These functions could be used as regular functions or attached to table 
> columns with CREATE/ALTER table. There would be a new UNMASK permission, so 
> only the users with this permissions would be able to see the unmasked column 
> values. It would be possible to customize masking by using UDFs as masking 
> functions.
> 
> Thanks,

Re: dtests to reproduce the schema disagreement

[Jeff Jirsa]

Stop node 1 before you start node 2, essentially mocking a full network
partition.



On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev 
wrote:

> Thank you, Aleksey,
> Yes, I have tried this approach, the problem is there is a timing window
> that node 1 runs the CREATE TABLE while node 2 is down, and then we bring
> up the node 2 and it may receive the gossip from node 1 at startup, and the
> CREATE TABLE will fail on node 2 since the table already exists?
>
>
>
> On Tue, Aug 9, 2022 at 4:48 AM Aleksey Yeshchenko 
> wrote:
>
>> The absolute easiest way would be to down one of the two nodes first,
>> run CREATE TABLE on the live node, shut it down, get the other one up,
>> and run the same CREATE TABLE there, the bring up the down node.
>>
>> > On 9 Aug 2022, at 07:48, Konstantin Osipov via dev <
>> dev@cassandra.apache.org> wrote:
>> >
>> > * Cheng Wang via dev  [22/08/09 09:43]:
>> >
>> >> I am working on improving the schema disagreement issue. I need some
>> dtests
>> >> which can reproduce the schema disagreement.  Anyone know if there are
>> any
>> >> existing tests for that? Or something similar?
>> >
>> > cassandra-10250 is a good start.
>> >
>> > --
>> > Konstantin Osipov, Moscow, Russia
>>
>>

Re: dtests to reproduce the schema disagreement

[Jeff Jirsa]

I see. Then yes, make a cluster with at least 2 hosts, run the CREATE TABLE
on them at the same time. If you use the pause injection framework, you can
probably pause threads after the CFID is generated but before it's
broadcast.

If you make the CFID deterministic, you can avoid the race, but can run
into problems if you create/drop/create (a node that was down during the
drop may resurrect data)

If you leave the CFID non-deterministic, the only way you're going to get
safety is a global ordering or transactional system, which more or less
reduces down to https://issues.apache.org/jira/browse/CASSANDRA-10699

Now, there are some things you can do to minimize risk along the way - you
could try to hunt down all of the possible races where in-memory state and
on-disk state diverge, create signals/log messages / warnings to make it
easier to detect, etc. But I'd be worried that any partial fixes will
complicate 10699 (either make the merge worse, or be outright removed
later), so it may be worth floating your proposed fix before you invest a
ton of time on it.








On Mon, Aug 8, 2022 at 3:57 PM Cheng Wang  wrote:

> Jeff,
>
> The issue I was trying to address is when there are two CREATE TABLE
> queries running on two coordinator nodes concurrently, it might end up with
> 2 schema versions and they would never get resolved automatically because
> table id is random TimeUUID.
>
>
>
> On Mon, Aug 8, 2022 at 3:54 PM Jeff Jirsa  wrote:
>
>> Which (of the many) schema disagreement issue(s)?
>>
>>
>>
>> On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev <
>> dev@cassandra.apache.org> wrote:
>>
>>> Thank you for the reply, Brandon! It is helpful!
>>>
>>> I was thinking of creating a cluster with 2 nodes and having two
>>> concurrent CREATE TABLE statements running. But the test will be flaky as
>>> there is no guarantee that the query runs before the schema agreement has
>>> been reached.
>>> Any ideas for that?
>>>
>>> Thanks,
>>> Cheng
>>>
>>> On Mon, Aug 8, 2022 at 3:19 PM Brandon Williams 
>>> wrote:
>>>
>>>> If you simply do a lot of schema changes quickly without waiting for
>>>> agreement, that should get you there.
>>>>
>>>> Kind Regards,
>>>> Brandon
>>>>
>>>> On Mon, Aug 8, 2022 at 5:08 PM Cheng Wang via dev
>>>>  wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > I am working on improving the schema disagreement issue. I need some
>>>> dtests which can reproduce the schema disagreement.  Anyone know if there
>>>> are any existing tests for that? Or something similar?
>>>> >
>>>> > Thanks
>>>> > Cheng
>>>>
>>>

Re: dtests to reproduce the schema disagreement

[Jeff Jirsa]

Which (of the many) schema disagreement issue(s)?



On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev 
wrote:

> Thank you for the reply, Brandon! It is helpful!
>
> I was thinking of creating a cluster with 2 nodes and having two
> concurrent CREATE TABLE statements running. But the test will be flaky as
> there is no guarantee that the query runs before the schema agreement has
> been reached.
> Any ideas for that?
>
> Thanks,
> Cheng
>
> On Mon, Aug 8, 2022 at 3:19 PM Brandon Williams  wrote:
>
>> If you simply do a lot of schema changes quickly without waiting for
>> agreement, that should get you there.
>>
>> Kind Regards,
>> Brandon
>>
>> On Mon, Aug 8, 2022 at 5:08 PM Cheng Wang via dev
>>  wrote:
>> >
>> > Hello,
>> >
>> > I am working on improving the schema disagreement issue. I need some
>> dtests which can reproduce the schema disagreement.  Anyone know if there
>> are any existing tests for that? Or something similar?
>> >
>> > Thanks
>> > Cheng
>>
>

Re: [DISCUSS] Deprecate and remove resumable bootstrap and decommission

[Jeff Jirsa]

The hypothetical concern described is around potential data resurrection -
would you still use resumable bootstrap if you knew that data deleted
during those STW pauses was improperly resurrected?

On Wed, Aug 3, 2022 at 2:40 PM Bowen Song via dev 
wrote:

> I have benefited from the resumable bootstrap before, and I'm in favour of
> keeping the feature around.
>
> I've had streaming failures due to long STW GC pauses on some
> bootstrapping nodes, and I had to resume the bootstrap once or twice in
> order to get these nodes finish joinning the cluster. They had not
> experienced more long STW GC pauses since they joined the cluster. I would
> imagine I will spend a lots of time tuning the GC parameters in order get
> these nodes to join if the resumable bootstrapping feature is removed.
> Also, I'm not concerned about racing conditions involving repairs, because
> we don't run repairs while we are adding new nodes (to minimize the
> additional load on the cluster).
>
>
> On 03/08/2022 19:46, Josh McKenzie wrote:
>
> Context: https://issues.apache.org/jira/browse/CASSANDRA-17679
>
> From the .yaml comment on the param I was working on adding:
>
> In certain environments, operators may want to disable resumable bootstrap in 
> order to avoid potential correctness violations or data loss scenarios. 
> Largely this centers around nodes going down during bootstrap, tombstones 
> being written, and potential races with repair. By default we leave this on 
> as it's been enabled for quite some time, however the option to disable it is 
> more palatable now that we have zero copy streaming as that greatly 
> accelerates
>
>
> Given zero copy streaming in the system and the general unexplored
> correctness concerns of
> https://issues.apache.org/jira/browse/CASSANDRA-8838, specifically
> pointed out by Jeff here:
> https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234,
>  I've
> been chatting w/Paulo about this and we've both concluded we think the
> functionality should be made configurable, default off (?), deprecated in
> 4.2 and then completely removed next.
>
> - First: anyone have any concerns with the general arc of "remove
> resumable bootstrap and decommission"?
> - Second: Should we leave them enabled by default in 4.2 or disabled?
> - Third: Should we consider revisiting older branches with this
> functionality and making it toggle-able?
>
> ~Josh
>
>

Re: CEP-15 multi key transaction syntax

[Jeff Jirsa]

And would you allow a transaction that had > 1 named select and no modification 
statements, but commit if 1=1 ? 

> On Jun 4, 2022, at 2:45 PM, Jeff Jirsa  wrote:
> 
> 
> 
>> On Jun 3, 2022, at 8:39 AM, Blake Eggleston  wrote:
>> 
>> Hi dev@,
> 
> First, I’m ridiculously excited to see this. 
> 
>> 
>> I’ve been working on a draft syntax for Accord transactions and wanted to 
>> bring what I have to the dev list to solicit feedback and build consensus 
>> before moving forward with it. The proposed transaction syntax is intended 
>> to be an extended batch syntax. Basically batches with selects, and an 
>> optional condition at the end. To facilitate conditions against an arbitrary 
>> number of select statements, you can also name the statements, and reference 
>> columns in the results. To cut down on the number of operations needed, 
>> select values can also be used in updates, including some math operations. 
>> Parameterization of literals is supported the same as other statements.
>> 
>> Here's an example selecting a row from 2 tables, and issuing updates for 
>> each row if a condition is met:
>> 
>> BEGIN TRANSACTION;
>> SELECT * FROM users WHERE name='blake' AS user;
>> SELECT * from cars WHERE model='pinto' AS car;
>> UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
>> UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
>> COMMIT TRANSACTION IF car.is_running;
>> 
>> This can be simplified by naming the updates with an AS  syntax. If 
>> updates are named, a corresponding read is generated behind the scenes and 
>> its values inform the update.
>> 
>> Here's an example, the query is functionally identical to the previous 
>> query. In the case of the user update, a read is still performed behind the 
>> scenes to enable the calculation of miles_driven + 30, but doesn't need to 
>> be named since it's not referenced anywhere else.
>> 
>> BEGIN TRANSACTION;
>> UPDATE users SET miles_driven += 30 WHERE name='blake';
>> UPDATE cars SET miles_driven += 30 WHERE model='pinto' AS car;
>> COMMIT TRANSACTION IF car.is_running;
>> 
>> Here’s another example, performing the canonical bank transfer:
>> 
>> BEGIN TRANSACTION;
>> UPDATE accounts SET balance += 100 WHERE name='blake' AS blake;
>> UPDATE accounts SET balance -= 100 WHERE name='benedict' AS benedict;
>> COMMIT TRANSACTION IF blake EXISTS AND benedict.balance >= 100;
>> 
>> As you can see from the examples, column values can be referenced via a dot 
>> syntax, ie: . -> select1.value. Since the read portion 
>> of the transaction is performed before evaluating conditions or applying 
>> updates, values read can be freely applied to non-primary key values in 
>> updates. Select statements used either in checking a condition or creating 
>> an update must be restricted to a single row, either by specifying the full 
>> primary key or a limit of 1. Multi-row selects are allowed, but only for 
>> returning data to the client (see below).
>> 
>> For evaluating conditions, = & != are available for all types, <, <=, >, >= 
>> are available for numerical types, and EXISTS, NOT EXISTS can be used for 
>> partitions, rows, and values. If any column references cannot be satisfied 
>> by the result of the reads, the condition implicitly fails. This prevents 
>> having to include a bunch of exists statements.
> 
> Is there a new keyword for “partition (not) exists” or is it inferred by the 
> select?
> 
>> 
>> On completion, an operation would return a boolean value indicating the 
>> operation had been applied, and a result set for each named select (but not 
>> named update). We could also support an optional RETURN keyword, which would 
>> allow the user to only return specific named selects (ie: RETURN select1, 
>> select2).
>> 
> 
> The returned result set is after the updates are applied? 
> 
> 
>> Let me know what you think!
>> 
>> Blake

Re: CEP-15 multi key transaction syntax

[Jeff Jirsa]

> On Jun 3, 2022, at 8:39 AM, Blake Eggleston  wrote:
> 
> Hi dev@,

First, I’m ridiculously excited to see this. 

> 
> I’ve been working on a draft syntax for Accord transactions and wanted to 
> bring what I have to the dev list to solicit feedback and build consensus 
> before moving forward with it. The proposed transaction syntax is intended to 
> be an extended batch syntax. Basically batches with selects, and an optional 
> condition at the end. To facilitate conditions against an arbitrary number of 
> select statements, you can also name the statements, and reference columns in 
> the results. To cut down on the number of operations needed, select values 
> can also be used in updates, including some math operations. Parameterization 
> of literals is supported the same as other statements.
> 
> Here's an example selecting a row from 2 tables, and issuing updates for each 
> row if a condition is met:
> 
> BEGIN TRANSACTION;
>  SELECT * FROM users WHERE name='blake' AS user;
>  SELECT * from cars WHERE model='pinto' AS car;
>  UPDATE users SET miles_driven = user.miles_driven + 30 WHERE name='blake';
>  UPDATE cars SET miles_driven = car.miles_driven + 30 WHERE model='pinto';
> COMMIT TRANSACTION IF car.is_running;
> 
> This can be simplified by naming the updates with an AS  syntax. If 
> updates are named, a corresponding read is generated behind the scenes and 
> its values inform the update.
> 
> Here's an example, the query is functionally identical to the previous query. 
> In the case of the user update, a read is still performed behind the scenes 
> to enable the calculation of miles_driven + 30, but doesn't need to be named 
> since it's not referenced anywhere else.
> 
> BEGIN TRANSACTION;
>  UPDATE users SET miles_driven += 30 WHERE name='blake';
>  UPDATE cars SET miles_driven += 30 WHERE model='pinto' AS car;
> COMMIT TRANSACTION IF car.is_running;
> 
> Here’s another example, performing the canonical bank transfer:
> 
> BEGIN TRANSACTION;
>  UPDATE accounts SET balance += 100 WHERE name='blake' AS blake;
>  UPDATE accounts SET balance -= 100 WHERE name='benedict' AS benedict;
> COMMIT TRANSACTION IF blake EXISTS AND benedict.balance >= 100;
> 
> As you can see from the examples, column values can be referenced via a dot 
> syntax, ie: . -> select1.value. Since the read portion 
> of the transaction is performed before evaluating conditions or applying 
> updates, values read can be freely applied to non-primary key values in 
> updates. Select statements used either in checking a condition or creating an 
> update must be restricted to a single row, either by specifying the full 
> primary key or a limit of 1. Multi-row selects are allowed, but only for 
> returning data to the client (see below).
> 
> For evaluating conditions, = & != are available for all types, <, <=, >, >= 
> are available for numerical types, and EXISTS, NOT EXISTS can be used for 
> partitions, rows, and values. If any column references cannot be satisfied by 
> the result of the reads, the condition implicitly fails. This prevents having 
> to include a bunch of exists statements.

Is there a new keyword for “partition (not) exists” or is it inferred by the 
select?

> 
> On completion, an operation would return a boolean value indicating the 
> operation had been applied, and a result set for each named select (but not 
> named update). We could also support an optional RETURN keyword, which would 
> allow the user to only return specific named selects (ie: RETURN select1, 
> select2).
> 

The returned result set is after the updates are applied? 


> Let me know what you think!
> 
> Blake

Re: Using labels on pull requests in GitHub

[Jeff Jirsa]

An easier fix here is just to put a close action into the commit message:

Closes #nnn

e.g.
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
/ https://github.com/apache/cassandra/pull/1046

On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie  wrote:

> I think the fact that they pile up is because our merge strategy means we
> don't actually merge using the PR's we use for review so there's nothing
> codified in the workflow to close them out when a ticket's done.
>
> An easy fix would be to change our merge strategy and use the merge button
> on PR's to merge things in so they auto-close. :)
>
> (/grinding my axe)
>
> On Wed, Mar 16, 2022, at 7:27 AM, Paulo Motta wrote:
>
> Thanks for doing this Stefan.
>
> The fact that PRs are abandoned and piling up on github demonstrates a
> hygiene problem and creates a bad user experience to newcomers which are
> accustomed to the Github workflow. I'm supportive of any initiative to
> improve this
>
> I think starting labelling PRs manually and then looking into ways to
> automate this would be a good improvement from the status quo.
>
>
>

Re: [DISCUSS] Hotfix release procedure

[Jeff Jirsa]

We've done concurrent releases without security before, and you follow much
closer than others. I feel most people, if they saw all of the
changes reverted and a release of a single fix, would either instantly know
it's security (high confidence pointer to exactly which patch) OR assume
someone botched the release prep and draw attention to it. So we're trading
"someone who's very involved has a high confidence it's security but has to
dig through 30 patches to find it" vs "everyone knows exactly what's going
on", the former seems better

The only way I'd be in favor of a release that removes all other committed
patches is if the vote happened in private@ . I don't see any prohibition
on that in https://www.apache.org/foundation/voting.html#ReleaseVotes , so
that seems like an alternate, easy workaround to privacy.



On Tue, Feb 15, 2022 at 7:42 AM J. D. Jordan 
wrote:

> We already advertise that we are preparing a security release when ever we
> release all of our patch versions at the same time. So I don’t think there
> is an issue there.
> I was not involved in any PMC discussions and had no knowledge of the CVE,
> but when three branches got release votes at the same moment I knew one of
> the final couple patches that was on all three must be an un-announced CVE.
> It is especially more obvious when said patches mention JIRA ticket numbers
> with no information in the ticket. Nobody is being sneaky here as long as
> the vote and code are in the open.
>
> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote:
>
> 
>
> One issue with this approach is that we are advertising that we are
> preparing a security release by preparing such a release candidate.
>
>
>
> I wonder if we need to find a way to produce binaries without leaving an
> obvious public mark (i.e. private CI, private branch)
>
>
>
>
>
> *From: *Josh McKenzie 
> *Date: *Tuesday, 15 February 2022 at 14:09
> *To: *dev@cassandra.apache.org 
> *Subject: *[DISCUSS] Hotfix release procedure
>
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix
> releases and CI:
>
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
>
>
>
> If we are making this release for a security incident/data loss/hot fix
> reason, then I would expect to see the related change set only containing
> those patches. But the change set in the tag here the latest 4.0-dev
> commits.
>
>
>
> I'd like to propose that in the future, regardless of the state of CI, if
> we need to cut a hotfix release we do so from the previous released SHA +
> only the changes required to address the hotfix to minimally impact our end
> users and provide them with as minimally disruptive a fix as possible.
>
>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Jeff Jirsa]

We don't HAVE TO remove the Config.java entry - we can mark it as
deprecated and ignored and remove it in a future version (and you could
update Config.java to log a message about having a deprecated config
option). It's a much better operator experience: log for a major version,
then remove in the next.

On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova 
wrote:

> This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to
> fix a bug that gives impression those work. Confirmed with Benedict on the
> ticket.
>
> I agree I absolutely had to document it better, a ticket for documentation
> was opened but it slipped from my mind with this emergency release this
> week. It is unfortunate it is still in our backlog after the ADOC migration.
>
> Note taken. I truly apologize and I am going to prioritize
> CASSANDRA-17135. Let me know if there is anything else I can/should do at
> this point.
>
> On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
> wrote:
>
>> (moved dev@ to BCC)
>>
>>
>>> It looks like the otc_coalescing_strategy config key is no longer
>>> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
>>> anywhere in CHANGES.txt or NEWS.txt.
>>>
>>
>> James, you're right -- it was removed by CASSANDRA-17132
>>  in 4.0.2 and 4.1.
>>
>> I agree that the CHANGES.txt entry should be clearer and we'll improve it
>> plus add detailed info in NEWS.txt. I'll get this done soon in
>> CASSANDRA-17135 .
>> Thanks for the feedback. Cheers!
>>
>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Jeff Jirsa]

Accidentally dropped dev@, so adding back in the dev list, with the hopes
that someone on the dev list helps address this.

On Fri, Feb 11, 2022 at 2:22 PM Jeff Jirsa  wrote:

> That looks like https://issues.apache.org/jira/browse/CASSANDRA-17132 +
> https://github.com/apache/cassandra/commit/b6f61e850c8cfb1f0763e0f15721cde8893814b5
>
> I suspect this needs to be reverted, at least in 4.0.x, and it definitely
> deserved a NEWS.txt entry (and ideally some period of deprecation/warning).
>
>
>
> On Fri, Feb 11, 2022 at 2:09 PM James Brown  wrote:
>
>> It looks like the otc_coalescing_strategy config key is no longer
>> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
>> anywhere in CHANGES.txt or NEWS.txt.
>>
>> Attempting to upgrade a test cluster from 4.0.1 to 4.0.2 failed with 
>> *"Invalid
>> yaml. Please remove properties [otc_coalescing_strategy] from your
>> cassandra.yaml*"
>>
>> Is this change intentional?
>>
>> On Fri, Feb 11, 2022 at 1:40 AM Mick Semb Wever  wrote:
>>
>>> The Cassandra team is pleased to announce the release of Apache
>>> Cassandra version 4.0.2.
>>>
>>> Apache Cassandra is a fully distributed database. It is the right
>>> choice when you need scalability and high availability without
>>> compromising performance.
>>>
>>>  http://cassandra.apache.org/
>>>
>>> Downloads of source and binary distributions are listed in our download
>>> section:
>>>
>>>  http://cassandra.apache.org/download/
>>>
>>> This version is a bug fix release[1] on the 4.0 series. As always,
>>> please pay attention to the release notes[2] and Let us know[3] if you
>>> were to encounter any problem.
>>>
>>> Enjoy!
>>>
>>> [1]: CHANGES.txt
>>>
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0.2
>>> [2]: NEWS.txt
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.2
>>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>>>
>>
>>
>> --
>> James Brown
>> Engineer
>>
>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Jeff Jirsa]

(This was a +1 on the release, to be clear, not a +1 on the sentiment
below, which I appreciate but still believe we should proceed with the
release)


On Tue, Feb 8, 2022 at 3:44 PM Jeff Jirsa  wrote:

> +1
>
>
> On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie 
> wrote:
>
>> I find myself agreeing with Jeremiah's sentiment here.
>>
>> For example, we're asking people that are on 4.0.1 to make the difficult
>> choice between accepting the risk of whatever prompts an urgent release vs.
>> accepting the risk of potentially destabilizing their GA critical
>> infrastructure. The 4.0 line is regressing, at least from a CI perspective:
>> https://butler.cassandra.apache.org/#/ci/upstream/trend
>>
>> I'm a -0 on this release as structured; given we discussed this exact
>> situation when we adopted the new procedures I personally accept us moving
>> forward right now and wouldn't block the release, but going forward I'd
>> like to see us cut hotfix releases based on the latest GA plus a minimal
>> patchset to address whatever urgent need a release is targeting so long as
>> CI is in a regressing state.
>>
>>
>> On Tue, Feb 8, 2022 at 3:18 PM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>>
>>> -1 nb
>>>
>>> So we just voted on an approved the CI process page recently:
>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>>
>>> Where we said:
>>> "All releases by default are expected to have a green test run on
>>> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
>>> incidents, data loss, etc requiring hotfix), members with binding votes
>>> on a release may choose to approve a release with known failing tests.”
>>>
>>> I do not see green CI runs recently for 4.0.
>>> https://ci-cassandra.apache.org/job/Cassandra-4.0/
>>>
>>> If we are making this release for a security incident/data loss/hot fix
>>> reason, then I would expect to see the related change set only containing
>>> those patches.  But the change set in the tag here the latest 4.0-dev
>>> commits.
>>>
>>> Do we want to be violating our goal of only releasing with green CI less
>>> than a month after the vote?
>>>
>>> -Jeremiah Jordan
>>>
>>> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
>>>
>>> Proposing the test build of Cassandra 4.0.2 for release.
>>>
>>> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>>>
>>> Git:
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>>>
>>> Maven 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: [VOTE] Release Apache Cassandra 4.0.2

[Jeff Jirsa]

+1


On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie  wrote:

> I find myself agreeing with Jeremiah's sentiment here.
>
> For example, we're asking people that are on 4.0.1 to make the difficult
> choice between accepting the risk of whatever prompts an urgent release vs.
> accepting the risk of potentially destabilizing their GA critical
> infrastructure. The 4.0 line is regressing, at least from a CI perspective:
> https://butler.cassandra.apache.org/#/ci/upstream/trend
>
> I'm a -0 on this release as structured; given we discussed this exact
> situation when we adopted the new procedures I personally accept us moving
> forward right now and wouldn't block the release, but going forward I'd
> like to see us cut hotfix releases based on the latest GA plus a minimal
> patchset to address whatever urgent need a release is targeting so long as
> CI is in a regressing state.
>
>
> On Tue, Feb 8, 2022 at 3:18 PM Jeremiah D Jordan <
> jeremiah.jor...@gmail.com> wrote:
>
>> -1 nb
>>
>> So we just voted on an approved the CI process page recently:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280
>>
>> Where we said:
>> "All releases by default are expected to have a green test run on
>> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
>> incidents, data loss, etc requiring hotfix), members with binding votes
>> on a release may choose to approve a release with known failing tests.”
>>
>> I do not see green CI runs recently for 4.0.
>> https://ci-cassandra.apache.org/job/Cassandra-4.0/
>>
>> If we are making this release for a security incident/data loss/hot fix
>> reason, then I would expect to see the related change set only containing
>> those patches.  But the change set in the tag here the latest 4.0-dev
>> commits.
>>
>> Do we want to be violating our goal of only releasing with green CI less
>> than a month after the vote?
>>
>> -Jeremiah Jordan
>>
>> On Feb 7, 2022, at 8:14 AM, Mick Semb Wever  wrote:
>>
>> Proposing the test build of Cassandra 4.0.2 for release.
>>
>> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>>
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>>
>> Maven 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

[Jeff Jirsa]

+1

> On Jan 18, 2022, at 8:38 AM, Jonathan Ellis  wrote:
> 
> 
> +1
> 
>> On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas  
>> wrote:
>> 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
> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced

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

[Jeff Jirsa]

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: Resurrection of CASSANDRA-9633 - SSTable encryption

[Jeff Jirsa]

> On Nov 19, 2021, at 2:53 PM, Joseph Lynch  wrote:
> 
> 
>> 
>> For better or worse, different threat models mean that it’s not strictly 
>> better to do FDE and some use cases definitely want this at the db layer 
>> instead of file system.
> 
> Do you mind elaborating which threat models? The only one I can think
> of is users can log onto the database machine and have read access to
> the cassandra data directory but not read access to wherever the keys
> are?

Basically that - one where shell access is more likely (with or without LPE 
being required to get to the mounted volume). LPE being required in the common 
case for either makes them effectively the same, one just makes auditors much 
happier than the other.


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

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

[Jeff Jirsa]

For better or worse, different threat models mean that it’s not strictly better 
to do FDE and some use cases definitely want this at the db layer instead of 
file system. 

> On Nov 19, 2021, at 12:54 PM, Joshua McKenzie  wrote:
> 
> 
>> 
>> 
>> setting performance requirements on this regard is a
>> nonsense. As long as it's reasonably usable in real world, and Cassandra
>> makes the estimated effects on performance available, it will be up to
>> the operators to decide whether to turn on the feature
> 
> I think Joey's argument, and correct me if I'm wrong, is that implementing
> a complex feature in Cassandra that we then have to manage that's
> essentially worse in every way compared to a built-in full-disk encryption
> option via LUKS+LVM etc is a poor use of our time and energy.
> 
> i.e. we'd be better off investing our time into documenting how to do full
> disk encryption in a variety of scenarios + explaining why that is our
> recommended approach instead of taking the time and energy to design,
> implement, debug, and then maintain an inferior solution.
> 
>> On Fri, Nov 19, 2021 at 7:49 AM Joshua McKenzie 
>> wrote:
>> 
>> Are you for real here?
>> 
>> Please keep things cordial. Statements like this don't help move the
>> conversation along.
>> 
>> 
>> On Fri, Nov 19, 2021 at 3:57 AM Stefan Miklosovic <
>> stefan.mikloso...@instaclustr.com> wrote:
>> 
>>> On Fri, 19 Nov 2021 at 02:51, Joseph Lynch  wrote:
 
 On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja <
>>> shylaja.koko...@intel.com>
 wrote:
 
> To address Joey's concern, the OpenJDK JVM and its derivatives
>>> optimize
> Java crypto based on the underlying HW capabilities. For example, if
>>> the
> underlying HW supports AES-NI, JVM intrinsics will use those for
>>> crypto
> operations. Likewise, the new vector AES available on the latest Intel
> platform is utilized by the JVM while running on that platform to make
> crypto operations faster.
> 
 
 Which JDK version were you running? We have had a number of issues with
>>> the
 JVM being 2-10x slower than native crypto on Java 8 (especially MD5,
>>> SHA1,
 and AES-GCM) and to a lesser extent Java 11 (usually ~2x slower). Again
>>> I
 think we could get the JVM crypto penalty down to ~2x native if we
>>> linked
 in e.g. ACCP by default [1, 2] but even the very best Java crypto I've
>>> seen
 (fully utilizing hardware instructions) is still ~2x slower than native
 code. The operating system has a number of advantages here in that they
 don't pay JVM allocation costs or the JNI barrier (in the case of ACCP)
>>> and
 the kernel also takes advantage of hardware instructions.
 
 
> From our internal experiments, we see single digit % regression when
> transparent data encryption is enabled.
> 
 
 Which workloads are you testing and how are you measuring the
>>> regression? I
 suspect that compaction, repair (validation compaction), streaming, and
 quorum reads are probably much slower (probably ~10x slower for the
 throughput bound operations and ~2x slower on the read path). As
 compaction/repair/streaming usually take up between 10-20% of available
>>> CPU
 cycles making them 2x slower might show up as <10% overall utilization
 increase when you've really regressed 100% or more on key metrics
 (compaction throughput, streaming throughput, memory allocation rate,
>>> etc
 ...). For example, if compaction was able to achieve 2 MiBps of
>>> throughput
 before encryption and it was only able to achieve 1MiBps of throughput
 afterwards, that would be a huge real world impact to operators as
 compactions now take twice as long.
 
 I think a CEP or details on the ticket that indicate the performance
>>> tests
 and workloads that will be run might be wise? Perhaps something like
 "encryption creates no more than a 1% regression of: compaction
>>> throughput
 (MiBps), streaming throughput (MiBps), repair validation throughput
 (duration of full repair on the entire cluster), read throughput at 10ms
 p99 tail at quorum consistency (QPS handled while not exceeding P99 SLO
>>> of
 10ms), etc ... while a sustained load is applied to a multi-node
>>> cluster"?
>>> 
>>> Are you for real here?Nobody will ever guarantee you these %1 numbers
>>> ... come on. I think we are
>>> super paranoid about performance when we are not paranoid enough about
>>> security. This is a two way street.
>>> People are willing to give up on performance if security is a must.
>>> You do not need to use it if you do not want to,
>>> it is not like we are going to turn it on and you have to stick with
>>> that. Are you just saying that we are going to
>>> protect people from using some security features because their db
>>> might be slow? What if they just dont care?
>>> 
 Even a microbenchmark that just sees how long it takes to 

Re: [VOTE] CEP-17: SSTable format API

[Jeff Jirsa]

+1


On Mon, Nov 15, 2021 at 11:43 AM Branimir Lambov  wrote:

> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
>
> Discussion:
>
> https://lists.apache.org/thread.html/r636bebcab4e678dbee042285449193e8e75d3753200a1b404fcc7196%40%3Cdev.cassandra.apache.org%3E
>
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding
> vetoes.
>
> Regards,
> Branimir
>

Re: [DISCUSS] Creating a new slack channel for newcomers

[Jeff Jirsa]

New developers or new users? I'd be afraid that a new developer-focused
channel might not get many eyes (or, it'll get the same 600 eyes, and it'll
have the same problem).


On Mon, Nov 8, 2021 at 8:29 AM Benjamin Lerer  wrote:

> Hi everybody,
>
> Aleksei Zotov mentioned to me that it was a bit intimidating for newcomers
> to ask beginner questions in the cassandra-dev channel as it has over 600
> followers and that we should probably have a specific channel for
> newcomers.
> This proposal makes total sense to me.
>
> What is your opinion on this? Do you have any concerns about it?
>
> Benjamin
>

Re: [DISCUSS] CEP-3: Guardrails

[Jeff Jirsa]

Without bike-shedding too much, guardrails would be great, building them
into a more general purpose framework that limits various dangerous things
would be fantastic. The CEP says that the guardrails should be distinct
from the capability restrictions (
https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see why
that needs to be the case. A system-level guardrail and a personal-level
guardrail are both restrictions, they just have different scopes, so
implement the restriction framework first, and allow the scopes to be
expanded 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 yaml
seems like a bad outcome



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



On 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+Guardrails
>
> Guardrails are an easy way to enforce system-wide soft and hard limits to
> prevent anti-patterns of bad usage and in the long run make it not possible
> to severely degrade the performance of a node/cluster through user actions
> such as having too many secondary indexes, too large partitions, almost
> full disks, etc.
>
> Thanks,
>

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

[Jeff Jirsa]

I support adopting this CEP, and the transaction semantics, and the
incremental approach to developing transactions, so I'm +1 on all three

I also think that it is preferrable that we get to a point where the -1 be
withdrawn, because I think it's a bad precedent to force the PMC to try to
navigate the ambiguity of some of the words in the process/procedure
documents.

On Thu, Oct 14, 2021 at 2:08 PM Mick Semb Wever  wrote:

> >
> > 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?
> >
>
>
> 1.  -1
>
> There's discussions still ongoing around this CEP. I support the CEP but
> believe it is important that the community takes the patience to let
> everyone say their piece and feel that they have been heard. I do not see
> that waiting a week, or two, before another vote risks the inclusion of
> this CEP in this release cycle. I've certainly appreciated reading through
> every question raised, and wouldn't object to the CEP page being updated to
> include even more (but this is not a blocker for me).
>

Re: Tradeoffs for Cassandra transaction management

[Jeff Jirsa]

Do I read this email as "Jonathan will vote against any improvement to
transactions that doesn't guarantee local latencies and interactive SQL,
even though no such proposal exists, thereby blocking any improvement over
the current status quo?"



On Thu, Oct 14, 2021 at 6:55 AM Jonathan Ellis  wrote:

> Hi Benedict,
>
> I'm not sure how to reconcile your statement that "your request to separate
> consensus from execution is [nonsensical]" with your earlier claims that we
> could build whatever additional transactional semantics we want on top of
> Accord.  The Accord whitepaper specifically separates out the consensus and
> the execution algorithms, but if we can't use the former to create
> execution timestamps for a different transaction manager then it doesn't
> sound as flexible as you're claiming.
>
> To your other points, it looks like the core problem is that you believe
> that "multi-shard CAS semantics" is the same as "Calvin semantics" which is
> not the case.  Calvin supports arbitrarily complex transactions (included
> dependent statements and indexed reads and writes), executed in parallel,
> with locking as necessary to enable that parallelism.
>
> I think I've also been clear that I want a path to supporting (1) local
> latencies (SLOG is a more elegant solution but "let's just let people give
> up global serializability like LWT" is also reasonable) and (2) SQL with
> interactive transactions.
>
> I'd prefer to keep the discussion on the mailing list, thanks.
>
>
> On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org 
> wrote:
>
> > Jonathan,
> >
> > Your request to separate consensus from execution is about as sensical as
> > asking for this separation in Paxos, or any other distributed consensus
> > protocol. I have made these statements repeatedly, so let me break it
> down
> > step by step.
> >
> > 1. Accord is an optimal leaderless distributed consensus protocol,
> > offering multi-shard CAS semantics in one round-trip (or two under
> > contention and clock skew).
> > 2. By simple virtue of this property, it already achieves Calvin
> semantics
> > with no other work. It remains a distributed consensus protocol, and the
> > whitepaper compares to these as peers.
> > 3. To build distributed transactions with more complex semantics, the
> > remaining candidates are the CockroachDB or YugaByte approach. These must
> > utilise a distributed consensus protocol. They do so using Raft today.
> > Accord is as optimal as Raft, therefore, Accord may be used to implement
> > this technique *without penalty*. Through its multi-shard consensus it
> has
> > the added advantage of supporting stronger isolation (but not requiring
> it
> > – a read/write intent design may choose weaker isolation).
> >
> > You continue to refuse to engage with these and other points. Please
> > respond directly to ALL of the below, that I have been asking you to
> answer
> > now for several weeks.
> >
> > 1. Since Accord supports all of your mooted transaction systems without
> > penalty the conversation about which semantics to pursue may be conducted
> > in parallel with its development. What about this claim do you not yet
> > understand? If you understand, why should a vote on CEP-15 be delayed?
> > 2. Which SPECIFIC transaction semantics do you want to achieve? You are
> > all over the shop today, demanding Cockroach/YugaByte interactive
> > semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are
> > conflicting demands.
> > 3. Why do you think Accord cannot support your preferred semantics?
> > 4. Will you accept a video call so we may discuss this with you in
> detail,
> > so we may understand your difficulty understanding these points I keep
> > repeating?
> >
> > After several weeks of back and forth you should already be able to
> answer
> > these questions. If you cannot invest the time to answer them now, I
> > perceive this as obstructive and I will escalate this to a PMC vote to
> > break the deadlock.
> >
> >
> >
> > From: Jonathan Ellis 
> > Date: Wednesday, 13 October 2021 at 04:21
> > To: dev 
> > Subject: Re: Tradeoffs for Cassandra transaction management
> > Blake (and Benedict), I’ll ask for your patience here.  We don’t have a
> > precedent of pushing through major initiatives in this project in a
> matter
> > of weeks.  We [members of the PMC that weren’t involved in creating
> Accord]
> > need time to do thorough research and make sure both that we understand
> > what is being proposed and that we have evaluated reasonable
> alternatives.
> >
> > One of the difficulties in evaluating Accord is that it combines a
> > state-of-the-art consensus/ordering protocol with a fairly limited
> > transaction manager.  So it may be useful to decouple the consensus and
> > transaction processing components, which would both allow non-Cassandra
> > usage of the consensus piece, and also make explicit the boundaries with
> > transaction processing with the consequence of making it easier to 

Re: Tradeoffs for Cassandra transaction management

[Jeff Jirsa]

I'll read more of this in a bit, I want to make sure I fully digest it
before commenting on the rest, but this block here deserves a few words:


On Sat, Oct 9, 2021 at 9:54 AM Jonathan Ellis  wrote:

> After putting the above together it seems to
> me that the two main areas of tradeoff are, 1. Is it worth giving up local
> latencies to get full global consistency?  Most LWT use cases use
> LOCAL_SERIAL.


Most LWT use cases use LOCAL_SERIAL because the difference in latency is
huge today (given the 4x RTTs) AND almost none of the users actually
understand how cassandra replication or consistency works, so they
misunderstand the guarantees provided by the choice they make. When
informed of the actual tradeoffs, a LOT of those users switch to SERIAL.

Re: [VOTE] CEP-13: Denylisting partitions

[Jeff Jirsa]

+1


On Wed, Sep 8, 2021 at 9:31 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> Hi everyone,
>
> I’m proposing this CEP for approval.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> Discussion:
>
> https://lists.apache.org/thread.html/r1547c5f2fb8548e2f7dcbe1a26da8c2a95ebec81adeeb2ea0545924d%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.
>
> Thanks,
> Sumanth
>

Re: [VOTE] Release Apache Cassandra 4.0.1

[Jeff Jirsa]

+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
>
>

Re: [DISCUSS] CEP 14: Paxos Improvements

[Jeff Jirsa]

> On Aug 22, 2021, at 7:25 PM, Miles Garnsey  wrote:
> 
> 
>> 
>> The problem is that today there’s no way to reliably exclude the new DC from 
>> serving reads, that I know of? If you can, then yes you would only need to 
>> ensure repair were run prior to activating reads from this DC.
> 
> We think we have a way to do this using certain settings in the Java driver.
> 
> Agree on your other points!

I don’t see how

Your best chance is with snitch games

And those don’t guarantee correctness if a single replica GC pauses and forces 
a speculative retry


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

Re: [VOTE] CEP-11: Pluggable memtable implementations

[Jeff Jirsa]

+1

Sent from my iPhone

> On Aug 19, 2021, at 9:19 AM, bened...@apache.org wrote:
> 
> +1
> 
> From: Brandon Williams 
> Date: Thursday, 19 August 2021 at 17:16
> To: dev@cassandra.apache.org 
> Subject: Re: [VOTE] CEP-11: Pluggable memtable implementations
> +1
> 
>> On Thu, Aug 19, 2021 at 11:11 AM Branimir Lambov  wrote:
>> 
>> Hello everyone,
>> 
>> I am proposing the CEP-11 (Pluggable memtable implementations) for adoption
>> 
>> Discussion thread:
>> https://lists.apache.org/thread.html/rb5e950f882196764744c31bc3c13dfbf0603cb9f8bc2f6cfb976d285%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: [DISCUSS] CASSANDRA-16840 - Close native transport port before hint transfer during decommission

[Jeff Jirsa]

The hint behavior aside, stopping native protocol once you begin a decom
seems like something most people would benefit from, even if they dont
realize that's what they want to happen.



On Tue, Aug 10, 2021 at 12:53 PM Matt Fleming 
wrote:

> Hi,
>
> With the way that hint transfer currently works during decommission,
> it's possible to leave hints on the disk of the decommissioning node if
> those hints are generated after the decommission begins.
>
> I'd like to discuss automatically closing the native transport port
> before hints are transferred to peers during the decommission process to
> prevent this from happening.
>
> While it's possible to manually prevent this problem today if an
> operator runs "nodetool disablebinary" before starting the decom, I
> think the default behaviour is surprising enough that doing it
> automatically makes more sense.
>
> Thanks,
> Matt
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Jeff Jirsa]

Agreed. Status quo is status quo. If someone wants to change status quo,
CEP would be appreciated.

Until CEP exists and is approved, work on patches in flight seems
reasonable and valid.


On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan 
wrote:

> I see no problem with continuing to add JMX commands for the foreseeable
> future.
>
> > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic <
> stefan.mikloso...@instaclustr.com> wrote:
> >
> > Can I have a clear response from you, community, if my work on 16725
> > is rendered totally useless in the light of this discussion? The time
> > on that was already spent and I honestly can not see why it would be a
> > problem to merge that command in.
> >
> > I am particularly objecting to Paulo's idea about dropping JMX command
> > implementations altogether, I find it quite radical without any
> > meaningful justification except "wasting somebody's time" but since it
> > is my time I spent on this, I am not sure why anybody would care?
> > While I do understand that we are trying to move forward with cql and
> > so on, I find it quite ridiculous to stop "5 minutes before 12" just
> > because somebody happened to drop an email to the dev list about this
> > before I managed to finish it.
> >
> > In other words, I find it just easier to finish it and voila, we can
> > query audit's config, when we are super close to it and all who spend
> > time on that was me - rather than waiting for weeks and months until
> > this discussion settles, living without that until then.
> >
> > Regards
> >
> >> On Thu, 15 Jul 2021 at 20:38, J. D. Jordan 
> wrote:
> >>
> >> I also am in favor of continuing to support nodetool in parallel with
> developing a command line tool and associated virtual tables to replace
> nodetool/JMX at some point in the future.
> >> I don’t think “native transport is not currently available during
> startup” is something to halt progress towards this goal. There are many
> ways to change the system to make that a non-problem.  But it is something
> to remember while moving towards the goal of node management without using
> JMX.
> >>
> >> -Jeremiah
> >>
>  On Jul 15, 2021, at 12:21 PM, Mick Semb Wever  wrote:
> >>>
> >>> 
> 
> 
> 
>  What is your opinion on this?
> 
> >>>
> >>>
> >>> This discussion was touched when implementing Diagnostics Events, at
> least
> >>> the discussion of JMX vs native (rather than nodetool vs cqlsh).  At
> that
> >>> time JMX was chosen because there was no way for a client to specify
> the
> >>> host you wanted the information from. Some more info in CASSANDRA-13459
> >>> and CASSANDRA-13472.
> >>>
> >>> The java and python drivers have since added this functionality. But if
> >>> it's not widely adopted by all the drivers, and the functionality may
> have
> >>> programmatic uses, this can be problematic.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Jeff Jirsa]

On Thu, Jul 15, 2021 at 12:59 PM Brandon Williams  wrote:

> On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta 
> wrote:
> >
> > Perhaps one approach to expose VirtualTables via nodetool without
> requiring
> > the user to provide CQL credentials would be to provide a generic
> > StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> > TabularData result. This would allow to keep a consistent nodetool
> frontend
> > to users while progressively switching the backend from JMX to
> > VirtualTables.
>
> I like this idea. +1
>

You lost me at "without requiring the user to provide CQL credentials"

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

[Jeff Jirsa]

There's a tactical issue, too, that virtual tables require native transport
to be up before it's usable, so for things pre-startup (e.g. querying
streaming state during bootstrap), so I don't think nodetool/jmx dies
entirely ever (or, a non-client-facing-virtual-tables-only port has to be
created, but that's much more involved obviously)

On Thu, Jul 15, 2021 at 9:18 AM Lorina Poland  wrote:

> I think it is important to keep in mind that users may be utilizing
> nodetool programmatically, in scripts. Obviously, those scripts could use
> calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact,
> building out virtual table capability, and then deprecating nodetool. In
> other words, only deprecate/remove nodetool commands once a *whole*
> replacement is available. And then deprecate slowly, perhaps with migration
> help in the docs for nodetool -> virtual tables.
>
> Lorina
>
> On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta 
> wrote:
>
> > Perhaps one approach to expose VirtualTables via nodetool without
> requiring
> > the user to provide CQL credentials would be to provide a generic
> > StorageServiceMBean.queryVirtualTable(String name) JMX method returning a
> > TabularData result. This would allow to keep a consistent nodetool
> frontend
> > to users while progressively switching the backend from JMX to
> > VirtualTables.
> >
> > We could create a framework to automatically expose a basic nodetool
> > getter/setter command whenever a new virtual table is added, making the
> new
> > feature visible to non-power nodetool users while requiring little
> > additional effort from the VirtualTable implementor.
> >
> > When migrating commands from JMX to VirtualTables we could just update
> the
> > legacy nodetool command implementation to access the virtual table via
> the
> > generic StorageServiceMBean.queryVirtualTable(String name) method while
> > keeping the output consistent with the previous implementation, and
> > deprecating their JMX counterpart.
> >
> > Ultimately when all commands are migrated from JMX to VirtualTables we
> > could decide if we want to keep the nodetool CLI, acessing all virtual
> > tables via the generic JMX virtual table accessor, or to deprecate
> nodetool
> > altogether and tell users to query virtual tables directly via cqlsh
> > instead.
> >
> > Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <
> > pauloricard...@gmail.com>
> > escreveu:
> >
> > > Thanks for bringing this discussion Benjamin. I raised a similar point
> in
> > > CASSANDRA-16725  >
> > > and it may become a recurrent topic now the code freeze is lifted and
> > more
> > > contributors will want to add new administrative commands to nodetool
> so
> > > it's important that we discuss and decide a consistent approach to this
> > > transition moving forward.
> > >
> > > I was planning to write a CEP to propose a migration strategy from JMX
> to
> > > Virtual tables but since this discussion came before I will detail my
> > > thoughts so far.
> > >
> > > I think that we should add new commands exclusively to Virtual Tables
> and
> > > progressively migrate existing nodetool/JMX commands to
> VirtualTables/CQL
> > > until we ultimately get rid of JMX/nodetool. Nevertheless, from the
> user
> > > point of view it may be inconvenient/confusing to have administrative
> > > commands split between different interfaces so we need to think about
> > this
> > > transition carefully to provide the best possible user experience.
> > >
> > > My motivation for CASSANDRA-16513 <
> > > https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're
> > > already providing some functionalities exclusively via Virtual Tables,
> so
> > > these features may not be visible to non-power users which are
> accustomed
> > > to the nodetool CLI interface for admin commands. The original plan for
> > > that ticket was to make nodetool abstract away the underlying interface
> > > (JMX, CQL) for administrative commands, so we would expose admin
> > > functionality via the same CLI interface (nodetool) to users while
> > > progressively migrating the backend from JMX to CQL/VirtualTables.
> > >
> > > Some people raised the concern that this could cause confusion among
> > users
> > > about which credentials to use if JMX or CQL for nodetool. Based on
> this
> > > feedback I adapted the proposal to create an entirely different
> > > administrative CLI tool (which I called admintool) to access/modify
> > virtual
> > > tables. In this proposal new administrative commands would be added
> > > exclusively to Virtual Tables and would automatically land on this
> tool,
> > > and legacy nodetool commands (via JMX) would be progressively migrated
> to
> > > admintool (CQL/VT) until the migration is completed. The drawback of
> this
> > > alternative proposal is that it would still split administrative
> commands
> > > between different CLI tools.
> > >
> > > So, if we decide 

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

[Jeff Jirsa]

Same


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

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

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

[Jeff Jirsa]

+1

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

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

Re: [VOTE] Release Apache Cassandra 4.0-rc2

[Jeff Jirsa]

+1


> On Jun 28, 2021, at 9:00 PM, Jeremy Hanna  wrote:
> 
> +1 (nb) nice to see all of the fixes and the use of newer TLS by default and 
> obfuscation of passwords in the audit log for the 4.0 release.
> 
>> On Jun 29, 2021, at 6:01 AM, 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  
> 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
>> 
> 
> -
> 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: Additions to Cassandra ecosystem page?

[Jeff Jirsa]

This would be my preference.


On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead  wrote:

> I'm also comfortable with a strict approach where we just list actual
> Apache Cassandra offerings, that also provides good solid clarity to users.
>
> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org 
> wrote:
>
> > +1
> >
> > From: Brandon Williams 
> > Date: Wednesday, 23 June 2021 at 15:44
> > To: dev@cassandra.apache.org 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > On Wed, Jun 23, 2021 at 9:38 AM Joshua McKenzie 
> > wrote:
> > >
> > > The obvious core responsibility of the website should be to ASLv2
> > > permissively licensed Apache Cassandra and secondarily to CQL as a
> > protocol
> > > IMO. I don't think we as a project should be tracking derivative works,
> > > forks, or other things built on top of the code-base and certainly not
> > > things with wildly varied licensing (AGPL, proprietary closed, etc).
> >
> > I agree.  I don't see how it makes sense for us to promote less
> > compatible derivatives with more restrictive licensing.  Imitation may
> > be flattery but as you pointed out, we don't need to be the ones
> > advertising it.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> --
>
> Ben Bromhead
>
> Instaclustr | www.instaclustr.com | @instaclustr
>  | +64 27 383 8975
>

Re: Obfuscation of passwords in audit loging, in or not in 4.0?

[Jeff Jirsa]

I am on the side of "this sounds like a really bad bug" for the audit
pieces, maybe less so than FQL. Anyone using audit for real probably has
meaningful audit requirements, which means they're in an industry where
they get audited for security, which means logging passwords is a big deal.




On Thu, Jun 3, 2021 at 3:52 PM bened...@apache.org 
wrote:

> I think it can be argued that this is a pretty serious bug for a newly
> introduced feature, and qualifies for inclusion in an RC, but I don’t
> personally have a strong opinion on if this should happen.
>
> I can’t imagine how this would be an _exception_ for inclusion in 4.0.1
> though.
>
> From: Mick Semb Wever 
> Date: Thursday, 3 June 2021 at 22:45
> To: dev@cassandra.apache.org 
> Subject: Re: Obfuscation of passwords in audit loging, in or not in 4.0?
> Thanks for raising this Stefan.
>
>
>
> > While I humbly think this is 4.0-worthy, the process we have, as far
> > as I know, is that there should be only critical fixes in 4.0 so I
> > guess this will go to 4.0.1, right? Or does this qualify to go to 4.0
> > still?
> >
>
>
> I believe the question here is whether this patch is worthy of an exception
> to go to 4.0.x. (i.e. 4.0.1)
> At this point in time all improvements would be by default slated for 4.x
> (i.e. 4.1)
>
> It does not qualify as a RC critical bug for 4.0.0.
>
> Looking at the patch it is simple, and one could almost consider it a
> security fix on a new 4.0 feature, so I'd say it's a valid exception for
> 4.0.x.
> Keen to hear what others think. And how we should go about requesting such
> exceptions for non-bugs during each annual release cycle.
>

Re: [DISCUSS] Creating a branch for 4.0.0

[Jeff Jirsa]

Given we're past the RC1, I think it's time.

Also, probably a silly question, but where's the list of issues reported in
the release candidate that need to be fixed before the GA?


On Thu, Jun 3, 2021 at 8:36 AM Brandon Williams  wrote:

> Hello,
>
> In order to more safely expedite 4.0's first release, I would like to
> propose minimizing the surface area for regressions by creating a 4.0.0
> branch, as we have done in the past for initial releases.  Only critical
> bugfixes would go in this branch, essentially removing it from the merge
> order otherwise.  This should allow everyone to scratch the itches they
> choose without introducing any unnecessary risk to the impending 4.0.0
> release. Thoughts?
>
> Kind Regards,
> Brandon
>

Re: Download source release / binary files in source release

[Jeff Jirsa]

On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean  wrote:

>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda item to reflect the current situation.
>
>
The thread linked earlier is worth reading for sure. Again,
https://lists.apache.org/thread.html/f8022be5a02c6f020aac635193e729a0f73376164cea7c38474c3dc0%401332948346%40%3Cgeneral.incubator.apache.org%3E

As an ASF member and a member of the Cassandra PMC, it's pretty clear what
Roy's position was in 2012.

My personal, emotional response is in line with what Rob Weir said in
2012:  "The issue should be lack of source code, not presence of binary
code."

If someone asked me what's included in a source release, without reading
ANY doc or policy, I'd expect there to be the complete, unabridged source
of the project, and enough context to build it. That's what Cassandra has
today. The extra binaries are just that - extra. They come with no burden.
They come with no obligation to use. They come with no penalty. The source
for which the PMC is responsible is published, and that feels far more
important to me than the absence of binary code that's trivial to remove.

Roy's response in the 2012 thread, though, is unambiguous: he strongly
believes, clearly with authority in 2012, that the presence of ANY binary
file violates the spirit of a source release. That feels quite extreme to
me, though this line is probably nuanced enough to inspire a book on trust:

"One cannot vote to approve a release containing a mix of source and binary
code because the binary is not open source and cannot be verified to be
safe for release (even if it was derived from open source)."

Based on this point, I personally won't vote to approve a future release
with binary packages, but I also strongly disagree with the assertion in
that same past thread that it's worth nuking a 10+year history of releases.
That's the type of action that would severely diminish trust in the
foundation.

We SHOULD look at what's required to rebuild PAST releases. We should also
admit that people are human and be reasonable along the way. Community over
code and all that.

Re: Download source release / binary files in source release

[Jeff Jirsa]

To quote Niclas in the legal thread:

The notion that these jars are "not open source" and must therefor not be used 
in the way they are intended is a preposterous stance

This seems to genuinely be against policy in a way that is profoundly 
frustrating: the source of the project is available, the dependencies are 
included compiled, forcing those to be stripped is just ridiculous. 

> On Mar 26, 2021, at 6:59 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Could you clarify why you think this is incompatible with ASF policy?
> 
> Because a source release could not contain compiled code (category A or 
> otherwise), if it does then it not open source. See for instance [1]. This is 
> why tools like Apache Rat look for certain types of binary files in release 
> artefacts.
> 
> This has also come up before a number of times e.g. including the gradle jar 
> in a source release e.g [2]
> 
> Thanks,
> Justin
> 
> 1. http://www.apache.org/legal/release-policy.html#artifacts
> 2. https://issues.apache.org/jira/browse/LEGAL-288
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Re: Upgrade chronicle-queue version from 4 to 5

[Jeff Jirsa]

No objection and strong agreement that it should happen with 4.0 for arm64


On Wed, Jan 20, 2021 at 12:44 PM Mick Semb Wever  wrote:

> To get Cassandra 4.0 working on arm64 we have a number of dependencies
> we need to upgrade. See CASSANDRA-16384, CASSANDRA-16392 and
> CASSANDRA-15889.
>
> CASSANDRA-16384 requires the major version upgrade from
> chronicle-queue 4 to 5. A consequence[1] of this is any external
> trailers (consumers) must also be upgraded to version 5. This is a
> breakage of our Beta Release Lifecycle rules[2]. Chronicle-queue is
> used by Auditing, FQL, and Diagnostic Events.
>
> I would like to request an exception to the Beta release to get the
> upgrade in place and to support arm64. Does anyone have any objection
> or concern to the upgrade? An entry in NEWS.txt will be added.
>
>
> [1]
> https://issues.apache.org/jira/browse/CASSANDRA-16384?focusedCommentId=17268671=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17268671
>
> [2]
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> -
> 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-beta4

[Jeff Jirsa]

+1 (binding)

It's not a big deal, not worth killing the release, but 15299 / a7c4ba9eeec 
introduced a build warning in a burn test, I'll open a JIRA for it in a bit 
(unless someone ninjas it first). 

On 2020/12/18 19:16:16, Mick Semb Wever  wrote: 
> Proposing the test build of Cassandra 4.0-beta4 for release.
> 
> sha1: b0c50c10dbc443a05662b111a971a65cafa258d5
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta4-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1226/org/apache/cassandra/cassandra-all/4.0-beta4/
> 
> 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-beta4/
> 
> 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-beta4-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta4-tentative
> 

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

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

[Jeff Jirsa]

This is complicated and relatively few people on earth understand it, so
having little feedback is mostly expected, unfortunately.

My normal emotional response is "correctness is required, opt-in to
performance improvements that sacrifice strict correctness", but I'm also
sure this is going to surprise people, and would understand / accept #4
(default to current, opt-in to correct).


On Wed, Nov 18, 2020 at 4:54 AM Benedict Elliott Smith 
wrote:

> It doesn't seem like there's much enthusiasm for any of the options
> available here...
>
> On 12/11/2020, 14:37, "Benedict Elliott Smith" 
> wrote:
>
> > Is the new implementation a separate, distinctly modularized new
> body of work
>
> It’s primarily a distinct, modularised and new body of work, however
> there is some shared code that has been modified - namely PaxosState, in
> which legacy code is maintained but modified for compatibility, and the
> system.paxos table (which receives a new column, and slightly modified
> serialization code).  It is conceptually an optimised version of the
> existing algorithm.
>
> If there's a chance of being of value to 4.0, I can try to put up a
> patch next week alongside a high level description of the changes.
>
> > But a performance regression is a regression, I'm not shrugging it
> off.
>
> I don't want to give the impression I'm shrugging off the correctness
> issue either. It's a serious issue to fix, but since all successful updates
> to the database are linearizable, I think it's likely that many
> applications behave correctly with the present semantics, or at least
> encounter only transient errors. No doubt many also do not, but I have no
> idea of the ratio.
>
> The regression isn't itself a simple issue either - depending on the
> topology and message latencies it is not difficult to produce inescapable
> contention, i.e. guaranteed timeouts - that might persist as long as
> clients continue to retry. It could be quite a serious degradation of
> service to impose on our users.
>
> I don't pretend to know the correct way to make a decision balancing
> these considerations, but I am perhaps more concerned about imposing
> service outages than I am temporarily maintaining semantics our users have
> apparently accepted for years - though I absolutely share your
> embarrassment there.
>
>
> On 12/11/2020, 12:41, "Joshua McKenzie"  wrote:
>
> Is the new implementation a separate, distinctly modularized new
> body of
> work or does it make substantial changes to existing
> implementation and
> subsume it?
>
> On Thu, Nov 12, 2020 at 3:56 AM Sylvain Lebresne <
> lebre...@gmail.com> wrote:
>
> > Regarding option #4, I'll remark that experience tends to
> suggest users
> > don't consistently read the `NEWS.txt` file on upgrade, so
> option #4 will
> > likely essentially mean "LWT has a correctness issue, but once
> it broke
> > your data enough that you'll notice, you'll be able to dig the
> proper flag
> > to fix it for next time". I guess it's better than nothing, of
> course, but
> > I'll admit that defaulting to "opt-in correctness", especially
> for a
> > feature (LWT) that exists uniquely to provide additional
> guarantees, is
> > something I have a hard rallying behind.
> >
> > But a performance regression is a regression, I'm not shrugging
> it off.
> > Still, I feel we shouldn't leave LWT with a fairly serious known
> > correctness bug and I frankly feel bad for "the project" that
> this has been
> > known for so long without action, so I'm a bit biased in wanting
> to get it
> > fixed asap.
> >
> > But maybe I'm overstating the urgency here, and maybe option #1
> is a better
> > way forward.
> >
> > --
> > Sylvain
> >
>
>
>
> -
> 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: Creating a branch for 5.0 …?

[Jeff Jirsa]

> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith  
> wrote:
> 
> 
>> 
>> As I understand Sankalp's primary (and quite reasonable) argument the last 
>> time we discussed this
> 
> The more significant cost to the project is distracting contributors focused 
> on 4.0.  The project is bandwidth constrained right now.  Feature development 
> doesn't happen in a vacuum, and some of that bandwidth will have to go to 
> participating in any new feature development.  So, if feature development 
> begins in earnest, the 4.0 ship date will slip - by how much, who knows?
> 
> Of course, the new features will also get less attention than they should.  
> So it's a lose-lose in that respect.
> 
> I think if we are to consider this, any ticket or project for 5.0 should be 
> subject to a consensus vote before work begins.  Work that a contributor - 
> focused on the more urgent and less rewarding job of shipping 4.0 - would 
> participate in can be deferred.  Uncontentious work, or work where all 
> relevant contributors are free to participate, can make progress.

I have no opinion on branching, but I think we all know it’s not reasonable to 
say what people can and can’t work on in any open source project. PMC members 
and committers get an opinion on what goes in the repo, but not what gets 
worked on or reviewed by other committers. 
-
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.22

[Jeff Jirsa]

+1


On Fri, Aug 28, 2020 at 7:43 AM Brandon Williams  wrote:

> +1
>
> On Fri, Aug 28, 2020 at 8:09 AM Mick Semb Wever  wrote:
> >
> > Proposing the test build of Cassandra 3.0.22 for release.
> >
> > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative
> > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1216/org/apache/cassandra/cassandra-all/3.0.22/
> >
> > 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.22/
> >
> > 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.22-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.22-tentative
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 2.1.22

[Jeff Jirsa]

+1


On Fri, Aug 28, 2020 at 8:42 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 2.1.22 for release.
>
> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.22-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1214
> /org/apache/cassandra/cassandra-all/2.1.22/
> 
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/2.1.22/
>
> 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/2.1.22-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.1.22-tentative
>

Re: [VOTE] Release Apache Cassandra 2.2.18

[Jeff Jirsa]

+1


On Fri, Aug 28, 2020 at 5:45 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 2.2.18 for release.
>
> sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1215/org/apache/cassandra/cassandra-all/2.2.18/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/2.2.18/
>
> 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/2.2.18-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.18-tentative
>

Re: [VOTE] Release Apache Cassandra 3.11.8

[Jeff Jirsa]

+1


On Fri, Aug 28, 2020 at 6:37 AM Mick Semb Wever  wrote:

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

Re: [VOTE] Release Apache Cassandra 4.0-beta2

[Jeff Jirsa]

+1


On Fri, Aug 28, 2020 at 7:19 AM Mick Semb Wever  wrote:

> Proposing the test build of Cassandra 4.0-beta2 for release.
>
> sha1: 56eadf2004399a80f0733041cacf03839832249a
> Git:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative
> Maven Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1218/org/apache/cassandra/cassandra-all/4.0-beta2/
>
> 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-beta2/
>
> 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-beta2-tentative
> [2]: NEWS.txt:
>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta2-tentative
>

Re: Contributing research on C* usage for blog

[Jeff Jirsa]

I don't have any questions, but datastax folks: thanks for funding stuff
like this.

(I'd love to see it as a blog post, I'd also love to see people internalize
the negative feedback and assumed features and determine whether or not
people are working on the right things)

On Thu, Aug 27, 2020 at 10:25 AM Melissa Logan 
wrote:

> Hi everyone,
>
> Several open source projects conduct regular user surveys to understand
> current usage and adoption trends, e.g. OpenStack, Kubernetes, Cloud
> Foundry, etc. They can be informative to the community and other end users.
> It looks like the C* community may have conducted these in the past per
> https://twitter.com/cassandra/status/649287871577219072.
>
> Recently, an independent research company called Clearpath Strategies was
> funded by DataStax to conduct research on C* usage and adoption, and they
> would like to contribute the findings to the community.
>
> 901 practitioners were interviewed. I analyzed the data and summarized in a
> document here:
>
> https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing
>
> If this seems broadly useful, I’m proposing that we publish to the C* blog.
> New graphics will be created in the same styling as the 4.0 graphic as
> noted in the doc.
>
> If you have questions about the data, please share here or in the doc.
>
> Appreciate your thoughts and consideration.
>
> Melissa
>

Re: [Discussion] Windows support

[Jeff Jirsa]

> On Jul 30, 2020, at 8:08 AM, Andrew Cobley (Staff)  
> wrote:
> 
> Apologies, I have not been involved in this process for a few years, but I 
> saw this topic pass by and thought I would like to comment.
> 
> I’m a lecturer in computer science and used C* in a couple of dev classes, 
> some of you may remember we ran a couple of Hackday’s with Datastax.  
> Students would develop projects using C* in order to learn NoSQL databases.  
> Many had to run on their own laptops and usually under windows, which was a 
> pain.
> 
> I’ve since moved to using C* under Docker on Gcloud for teaching which 
> removes most of the pain, once students  get used to using cloud services.
> 
> My point is, for educational purposes there are plenty of other ways of 
> running small dev clusters that are probably more realistic for most uses 
> cases.
> 
> I’d be for removing windows support, but I suspect my use case is one of the 
> more minor ones.

I think hearing “we used to use this but now there are better alternatives” is 
great signal 
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSS] Revisiting Java 11's experimental status

[Jeff Jirsa]

Got it, thanks for the correction.


On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams  wrote:

> I believe you can run them on 11, but you can't build them on it.
>
> On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa  wrote:
> >
> > I still dont get it, because you can't use any released version of
> > cassandra with anything other than jdk8.
> >
> >
> >
> > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin 
> wrote:
> >
> > > Follow-up on the informal poll I did on twitter:
> > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
> > >
> > > Offered up as data to be used as you will.
> > >
> > > 161 votes
> > > <= JDK8: 59%
> > > JDK9 or 10: 7%
> > > JDK11 or 12: 27%
> > > JDK13 or 14: 7%
> > >
> > >
> > >
> > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp  wrote:
> > >
> > > > Yea, ZGC is kinda tricky in 11.
> > > >
> > > > —
> > > > Robert Stupp
> > > > @snazy
> > > >
> > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa  wrote:
> > > > >
> > > > > Zgc
> > > > >
> > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp  wrote:
> > > > >>
> > > > >> 
> > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa  wrote:
> > > > >>>
> > > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t
> even
> > > > prod ready in jdk11 , so what’s the motivation and what does the
> project
> > > > gain from revisiting the experimental designation on jdk11?
> > > > >>
> > > > >> Can you elaborate on what’s not even prod ready in Java 11?
> > > > >
> > > > >
> -
> > > > > 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] Revisiting Java 11's experimental status

[Jeff Jirsa]

I still dont get it, because you can't use any released version of
cassandra with anything other than jdk8.



On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin  wrote:

> Follow-up on the informal poll I did on twitter:
> https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21
>
> Offered up as data to be used as you will.
>
> 161 votes
> <= JDK8: 59%
> JDK9 or 10: 7%
> JDK11 or 12: 27%
> JDK13 or 14: 7%
>
>
>
> On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp  wrote:
>
> > Yea, ZGC is kinda tricky in 11.
> >
> > —
> > Robert Stupp
> > @snazy
> >
> > > On 14. Jul 2020, at 15:02, Jeff Jirsa  wrote:
> > >
> > > Zgc
> > >
> > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp  wrote:
> > >>
> > >> 
> > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa  wrote:
> > >>>
> > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even
> > prod ready in jdk11 , so what’s the motivation and what does the project
> > gain from revisiting the experimental designation on jdk11?
> > >>
> > >> Can you elaborate on what’s not even prod ready in Java 11?
> > >
> > > -
> > > 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-beta1 (take2)

[Jeff Jirsa]

+1

> On Jul 17, 2020, at 4:28 PM, Mick Semb Wever  wrote:
> 
> Proposing the test build of Cassandra 4.0-beta1 for release.
> 
> sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1211/org/apache/cassandra/cassandra-all/4.0-beta1/
> 
> 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-beta1/
> 
> The vote will be open for 60 hours (longer if needed). I've taken 12 hours
> off the normal 72 hours and this follows closely after the initial
> 4.0-beta1 vote. 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 -1s.
> 
> Eventual publishing and announcement of the 4.0-beta1 release will be
> coordinated, as described in
> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative

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

Re: [DISCUSS] Revisiting Java 11's experimental status

[Jeff Jirsa]

Zgc

> On Jul 14, 2020, at 2:26 AM, Robert Stupp  wrote:
> 
> 
>> On 14. Jul 2020, at 07:33, Jeff Jirsa  wrote:
>> 
>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod 
>> ready in jdk11 , so what’s the motivation and what does the project gain 
>> from revisiting the experimental designation on jdk11?
> 
> Can you elaborate on what’s not even prod ready in Java 11?

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