tion possible, i.e. avoids data loss with manual intervention. (Logging and metrics also face the same problem with false positives.)I'm +0 for rejection default in 5.0.1, and +1 for only logging default in 4.xOn Thu, 12 Sept 2024 at 18:56, Jeff Jirsa <jji...@gmail.com> wrote:This patch is so ha
On Sep 12, 2024, at 12:22 PM, J. D. Jordan wrote:I have lost sleep (and data) over this multiple times in the past few months, that was only recently tracked down to this exact scenario.+1 for including it in all active releases and enabling the failure of the writes on “wrong” nodes by default.I
This patch is so hard for me.
The safety it adds is critical and should have been added a decade ago.
Also it’s a huge patch, and touches “everything”.
It definitely belongs in 5.0. I’d probably reject by default in 5.0.1.
4.0 / 4.1 - if we treat this like a fix for latent opportunity for da
Rei used to be semi-active on the Cassandra lists. He took over lz4-java a few
years ago. Wonder if he’d be willing to pass the torch if he no longer has
time? CC’ing him in case he’s following email.
> On Aug 6, 2024, at 8:47 AM, Jordan West wrote:
>
> Oof this is a tough one. I agree wi
As Josh mentioned previously, not all procedural votes treat -1s as vetoes. I remain against the backport to 4.0 and 4.1, but not a veto. -1 for those branches. On Aug 3, 2024, at 11:19 PM, Yifan Cai wrote:Hi,I am proposing backporting CASSANDRA-19800 to Cassandra-4.0, 4.1 and 5.0. There is a dis
Would also vote to remove when TCM is available/stable.
More words on the create, drop, re-create, in case it’s not familiar to people:
- Create assigns an ID
- Drop removes definition and data
- Create assigns an ID
If non-deterministic, we had races where an ID was assigned concurrently in tw
It’s a 10 year old flaw in an 18 month old branch. Why does it need to go into
4.1, it’s not a regression and it clearly breaks compatibility?
> On Jul 30, 2024, at 8:52 AM, Jon Haddad wrote:
>
> This patch fixes a long standing issue that's the root cause of availability
> failures. Eve
for a vote. SureI’m -1 on 4.0 and 4.1- JeffOn Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa <jji...@gmail.com> wrote:Everyone has a low risk change they want to backport to every branch, 4.0 and 4.1 in particular are way past the point we should be adding features
The policy exists and it’s
Everyone has a low risk change they want to backport to every branch, 4.0 and
4.1 in particular are way past the point we should be adding features
The policy exists and it’s a pure feature not a regression
> On Jul 26, 2024, at 9:59 AM, Brandon Williams wrote:
>
> Given how low risk thi
+1 Should block
> On Jul 26, 2024, at 8:25 AM, Štefan Miklošovič wrote:
>
>
> I am formally asking for acknowledging (1) to be a blocker for 5.0-rc. I
> think it was introduced in (2) and it behaves like this (3).
>
> Regards
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-19779
>
(Answering this as a cassandra person, don’t confuse this reply as
board/foundation guidance)
The legal landscape is rapidly evolving with the CRA. The answer may change in
the future, but I think “we have a dependency we ship that’s user-accessible
and known to be abandoned” is an unhappy stat
+1
> On Jun 25, 2024, at 5:04 AM, Mick Semb Wever wrote:
>
>
>
> Proposing the test build of Cassandra 5.0-rc1 for release.
>
> sha1: b43f0b2e9f4cb5105764ef9cf4ece404a740539a
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.o
+1
Thank you for being explicit about which authors of gocql have signed the ICLA
> Where The Gocql Authors for copyright purposes are below. Those marked with
> asterisk have agreed to donate (copyright assign) their contributions to the
> Apache Software Foundation, signing CLAs when appropriat
If we have a public-facing API that we’re contemplating releasing to the
public, and we don’t think it’s needed, we should remove it before it’s
launched and we’re stuck with it forever.
> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan wrote:
>
> +1 from me for 1, just remove it now.
> I thi
fourth seems incredibly unlikely. The third seems maybe possible, but why not spec out the full range with the CEP instead of assuming iterative implementation?On Jun 2, 2024, at 20:59, Jeff Jirsa wrote:Would this be implemented solely in the write path? Or would you also try to enforce it in the
Would this be implemented solely in the write path? Or would you also try to enforce it in the read and sstable/compaction/repair paths as well? On May 31, 2024, at 23:24, Bernardo Botella wrote:Hello everyone,I am proposing this CEP:CEP-42: Constraints Framework - CASSANDRA - Apache Software Fo
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,
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?
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 wh
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 quit
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.
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 Authenticato
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 t
> 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
> wo
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 "
-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
,
> 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 understandin
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
+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.
>
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 implem
- 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 alr
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
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?
>> ht
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
>
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,
+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
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 partiti
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
+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 introd
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 kn
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 dete
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 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.ap
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 u
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
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, 2
> 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 headro
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 require
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
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,
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
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 -
"Specific
+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/h25skwkbdztz9h
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 compos
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
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 Weve
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 the
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 te
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 b
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: P
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 thi
“ 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 th
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,
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
ddress 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
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
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 boot
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@,
>
> Firs
> 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 forwar
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
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 bot
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
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/
(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:
>
>>
+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 po
+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
>>
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
impac
> 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? Th
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
+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/r636bebcab4e678db
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 in
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/CASSAN
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
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 wrot
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
+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.o
+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:/
+1
> On Aug 27, 2021, at 1:00 PM, Scott Andreas wrote:
>
> +1
>
>> On Aug 27, 2021, at 12:58 PM, Mick Semb Wever wrote:
>>
>>
>>>
>>>
>>> Proposal:
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements
>>> Discussion:
>>> https://lists.apache.org/thread.h
> 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.
>
> W
+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:1
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 work
+1
> On Jul 22, 2021, at 3:41 PM, Brandon Williams
> wrote:
>
> I am proposing the test build of Cassandra 4.0.0 for release.
>
> sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> Maven Artifac
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
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.quer
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,
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".
>
>
+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
+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
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
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 T
1 - 100 of 444 matches
Mail list logo
