Re: Welcome Patrick McFadin as Cassandra Committer

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

Re: Welcome our next PMC Chair Josh McKenzie

Congratulations Josh! Thank you Mick! -Joey On Thu, Mar 23, 2023 at 10:56 AM Molly Monroy wrote: > Congrats Josh - looking forward to working with you more closely! It's > been a pleasure, Mick! > > On Thu, Mar 23, 2023 at 8:32 AM Josh McKenzie > wrote: > >> Definitely want to +1 the appreciat

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

One of the explicit goals of making an official sidecar project was to try to make it something the project does not break compatibility with as one of the main issues the third-party sidecars (that handle distributed control, backup, repair, etc ...) have is they break constantly because C* breaks

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

> If we want to bring groups/containers/etc into the default deployment > mechanisms of C*, great. I am all for dividing it up into micro services > given we solve all the problems I listed in the complexity section. > > I am actually all for dividing C* up into multiple micro services, but the

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

+1 This proposal looks really exciting! -Joey On Wed, Apr 5, 2023 at 2:13 AM Aleksey Yeshchenko wrote: > > +1 > > On 4 Apr 2023, at 16:56, Ekaterina Dimitrova wrote: > > +1 > > On Tue, 4 Apr 2023 at 11:44, Benjamin Lerer wrote: >> >> +1 >> >> Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña a

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

Having native dependencies shouldn't make the project x86 only, it should just accelerate the performance on x86 when available. Can't we just try to load the fastest available provider (so arm will use native java but x86 will use proper hardware acceleration) and failing that fall-back to the def

Re: [VOTE] Accept java-driver

+1 (nb) I am so grateful for all the hard work that went into getting the java driver accepted into the project, well done to all involved! -Joey On Tue, Oct 3, 2023 at 7:38 AM C. Scott Andreas wrote: > +1 (nb) > > Accepting this donation would mark a huge milestone for the project. > > On Oct

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

+1 Sounds like a great change that will help us unify around a common testing paradigm, and even pave the path to in-tree load testing plus integrated correctness checking which would be extremely valuable! -Joey On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe wrote: > +1 > > Agree w/ all the

Re: Cassandra PMC Chair Rotation, 2024 Edition

This is exciting news!! Congratulations Dinesh and thank you for taking on this role! Also thank you to Josh for taking the role this year! -Joey On Thu, Jun 20, 2024 at 12:39 PM Rahul Xavier Singh < rahul.xavier.si...@gmail.com> wrote: > Congrats Dinesh! > > On Thu, Jun 20, 2024 at 12:27 PM F

Re: Difference between heartbeat and generation on a Gossip packet

Hi Abdelkarim, Other people on this list are much more knowledgeable than me and can correct me if I'm wrong, but my understanding is that the combination of generation and version (aka heartbeat) form a logical clock tuple consisting of (generation, version) and that combination is the HeartBeatS

Re: [VOTE] Release Apache Cassandra 2.2.13

+1 nb Tests look reasonable with passing unit tests and about 13 failing dtests On Tue, Jul 3, 2018 at 1:55 PM kurt greaves wrote

Re: reroll the builds?

We ran the tests against 3.0, 2.2 and 3.11 using circleci and there are various failing dtests but all three have green unit tests. 3.11.3 tentative (31d5d87, test branch , unit tests

Re: JIRAs in Review

We have a few improvements and bug fixes that could use reviewer feedback. Useful improvements for 4.0: https://issues.apache.org/jira/browse/CASSANDRA-14303 and https://issues.apache.org/jira/browse/CASSANDRA-14557 - Makes the user interface for creating keyspaces easier to use and less error pr

Re: Proposing an Apache Cassandra Management process

While I would love to use a different build system (e.g. gradle) for the sidecar, I agree with Dinesh that a separate repo would make sidecar development much harder to verify, especially on the testing and compatibility front. As Jeremiah mentioned we can always choose later to release the sidecar

Re: Proposing an Apache Cassandra Management process

> We are looking to contribute Reaper to the Cassandra project. > Just to clarify are you proposing contributing Reaper as a project via donation or you are planning on contributing the features of Reaper as patches to Cassandra? If the former how far along are you on the donation process? If the l

Re: Side Car New Repo vs not

I think that the pros of incubating the sidecar in tree as a tool first outweigh the alternatives at this point of time. Rough tradeoffs that I see: Unique pros of in tree sidecar: * Faster iteration speed in general. For example when we need to add a new JMX endpoint that the sidecar needs, or ch

Re: JIRAs in Review

Just want to bump this up if any reviewers have time before the 9/1 window. I think these are all patch available and ready for review at this point. Useful improvements for 4.0: > > https://issues.apache.org/jira/browse/CASSANDRA-14303 and > https://issues.apache.org/jira/browse/CASSANDRA-14557 -

Re: Reaper as cassandra-admin

I and the rest of the Netflix Cassandra team share Dinesh's concerns. I was excited to work on this project precisely because we were taking only the best designs, techniques, and functionality out of the community sidecars such as Priam, Reaper, and any other community tool and building the simple

Re: Yet another repair solution

I'm pretty interested in seeing and understanding your solution! When we started on CASSANDRA-14346 reading your design documents and plan you sketched out in CASSANDRA-10070 were really helpful in improving our design. I'm particularly interested in how the Scheduler/Job/Task APIs turned out (we'r

Re: QA signup

I don't think anyone has mentioned this yet but we probably want to consider releasing 4.0 alpha jars to maven central soon so the open source ecosystem can start testing a consistent Cassandra 4.0; for example I had to hack 4.0 into Priam's build [1] by manually building a jar and checking it in w

Re: Proposing an Apache Cassandra Management process

On Fri, Sep 7, 2018 at 5:03 PM Jonathan Haddad wrote: > > We haven’t even defined any requirements for an admin tool. It’s hard to > make a case for anything without agreement on what we’re trying to build. > We were/are trying to sketch out scope/requirements in the #14395 and #14346 tickets as w

Re: Proposing an Apache Cassandra Management process

> What’s the benefit of doing it that way vs starting with reaper and > integrating the netflix scheduler? If reaper was just a really inappropriate > choice for the cassandra management process, I could see that being a better > approach, but I don’t think that’s the case. > The benefit, as Din

Re: Proposing an Apache Cassandra Management process

On Fri, Sep 7, 2018 at 10:00 PM Blake Eggleston wrote: > > Right, I understand the arguments for starting a new project. I’m not saying > reaper is, technically speaking, the best place to start. The point I’m > trying to make is that the non-technical advantages of using an existing > project

Re: [VOTE] Development Approach for Apache Cassandra Management process

+1 for piecemeal (option b). I think I've explained my opinion on all the various threads and tickets. -Joey On Wed, Sep 12, 2018 at 10:48 AM Vinay Chella wrote: > > +1 for option b, considering the advantages mentioned in dev email thread > that Sankalp linked. > > ~Vinay > > > On Wed, Sep 12,

Re: [VOTE] Development Approach for Apache Cassandra Management process

> I'd like to ask those of you that are +1'ing, are you willing to contribute > or are you just voting we start an admin tool from scratch because you > think it'll somehow produce a perfect codebase? Roopa, Vinay, Sumanth and I are voting as community members (and a sizeable user) and our willing

Re: QA signup

> In looking at the Confluence space restrictions, it appears the main page is > open for editing and I don't see restrictions on page creation; can you try > to sign in, create one, and let me know if that doesn't work? I signed in and went to "Jira reports" and then tried to hit "Add Jira Repo

Re: [DISCUSS] changing default token behavior for 4.0

I am a big fan of lowering the default number of tokens for many reasons (availability, repair, etc...). I also agree there are some usability blockers to "just lowering the number today", but I very much agree that the current default of 256 random tokens is a huge bug I hope we fix by 4.0 release

Re: MD5 in the read path

Michael Kjellman and others (Jason, Sam, et al.) have already done a lot of work in 4.0 to help change the use of MD5 to something more modern [1][2]. Also I cut a ticket a little while back about the significant performance penalty of using MD5 for digests when doing quorum reads of wide partition

Re: MD5 in the read path

> > Thank you all for the response. > For RandomPartitioner, MD5 is used to avoid collision. However, why is it > necessary for comparing data between different replicas? Is it not feasible > to use CRC for data comparison? > My understanding is that it is not necessary to use MD5 and we can switch

4.0 Testing Signup

Following up on Jon's call for QA, I put together the start of a confluence page for people to list out

Re: 4.0 Testing Signup

On Thu, Nov 8, 2018 at 11:04 AM Romain Hardouin wrote: > > Hi, > I'm volunteer to be contributor on Metrics or Tooling component. Are we > supposed/allowed to edit Confluence page directly?Btw I think that tooling > should be split, maybe one ticket per tool? > Awesome! Yes feel free to add your

Re: 4.0 Testing Signup

On Thu, Nov 8, 2018 at 1:42 PM kurt greaves wrote: > Been thinking about this for a while and agree it's how we should approach > it. BIkeshedding but seems like a nice big table would be suitable here, > and I think rather than a separate confluence page per component we just > create separate J

Re: JIRA Workflow Proposals

Benedict, Thank you for putting this document together, I think something like this will really improve the quality and usefulness of the Jira tickets! A few pieces of overall feedback on the proposal: * I agree with Jeremy and Joshua on keeping labels. Labels are the only way that contributors w

Re: JIRA Workflow Proposals

Just my 2c 1. D C B E A 2. B, C, A 3. A 4. +0.5 -Joey On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith wrote: > Just to re-summarise the questions for people: > > 1. (A) Only contributors may edit or transition issues; (B) Only > contributors may transition issues; (C) Only Jira-users ma

Re: [VOTE] Change Jira Workflow

+1 non-binding On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne wrote: > +1 > -- > Sylvain > > > On Tue, Dec 18, 2018 at 9:34 AM Oleksandr Petrov < > oleksandr.pet...@gmail.com> > wrote: > > > +1 > > > > On Mon, Dec 17, 2018 at 7:12 PM Nate McCall wrote: > > > > > > On Tue, Dec 18, 2018 at 4:19

Re: [VOTE] Release Apache Cassandra 3.0.18

3.0.18-tentative unit and dtest run: https://circleci.com/gh/jolynch/cassandra/tree/3.0.18-tentative unit tests: 0 failures dtests: 1 failure * test_closing_connections - thrift_hsha_test.TestThriftHSHA ( https://issues.apache.org/jira/browse/CASSANDRA-14595) +1 non binding -Joey On Sat, Feb 2,

Re: [VOTE] Release Apache Cassandra 3.11.4

3.11.4-tentative unit and dtest run: https://circleci.com/gh/jolynch/cassandra/tree/3.11.4-tentative unit tests: 0 failures dtests: 1 failure * test_closing_connections - thrift_hsha_test.TestThriftHSHA ( https://issues.apache.org/jira/browse/CASSANDRA-14595) +1 non binding -Joey On Sat, Feb 2,

Re: [VOTE] Release Apache Cassandra 2.2.14

2.2.14-tentative unit and dtest run: https://circleci.com/gh/jolynch/cassandra/tree/2.2.14-tentative unit tests: 0 failures dtests: 5 failures * test_closing_connections - thrift_hsha_test.TestThriftHSHA ( https://issues.apache.org/jira/browse/CASSANDRA-14595) * test_multi_dc_tokens_default - toke

Re: Audit logging to tables.

Hi Sagar, Vinay can confirm, but as far as I am aware we have no current plans to implement audit logging to a table directly, but the implementation is fully pluggable (like compaction, compression, etc ...). Check out the blog post [1] and documentation [2] Vinay wrote for more details, but the

Re: Choosing a supported Python 3 major version for cqlsh

Since we'll be maintaining backwards compatibility with python 2.7, we can't really use python 3 only language features or reserved keywords anyways so we should probably just target the lowest common denominator (so 3.4 or 3.5 probably) and then after Python 2 is officially EOL in 2020 perhaps we

Re: Stabilising Internode Messaging in 4.0

*I am relatively new to these code paths—especially compared to the committers that have been working on these issues for years such as the 15066 authors as well as Jason Brown—but like many Cassandra users I am familiar with many of the classes of issues Aleksey and Benedict have identified with t

Re: Stabilising Internode Messaging in 4.0

Let's try this again, apparently email is hard ... I am relatively new to these code paths—especially compared to the committers that have been working on these issues for years such as the 15066 authors as well as Jason Brown—but like many Cassandra users I am familiar with many of the classes of

Re: 4.0 alpha before apachecon?

We hashed this out a bit in slack and I think the current rough consensus (please speak up if you don't agree) is that we update our release guidelines [1] to allow API changes between alpha and beta as the common artifact is useful for testing and we will probably end up finding API breakage while

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

Running all tests at https://circleci.com/workflow-run/79918e2a-ea8e-48a6-a38d-96cf85de27ff Will report back with results shortly, -Joey On Thu, Sep 5, 2019 at 3:55 PM Jon Haddad wrote: > +1 > > On Thu, Sep 5, 2019 at 3:44 PM Michael Shuler > wrote: > > > I propose the following artifacts for

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

for 4.0), this looks somewhat reasonable to me. I'm launching a multi-dc cluster to do some light load testing. -Joey On Thu, Sep 5, 2019 at 4:03 PM Joseph Lynch wrote: > > Running all tests at > https://circleci.com/workflow-run/79918e2a-ea8e-48a6-a38d-96cf85de27ff > > W

Re: [VOTE] Release Apache Cassandra 4.0-alpha1 (24 hour vote)

On Fri, Sep 6, 2019 at 12:57 AM Sankalp Kohli wrote: > > Can we have a vote once the tests pass? I know we all are including me are > excited about cutting this alpha but we cannot cut a release with test > failing or not being run due to some Java home issue. > > If people have already started

Re: Cassandra image for Kubernetes

On Fri, Sep 20, 2019 at 8:09 AM Ben Bromhead wrote: > > Providing an official docker image is a little tricky, as despite what > container marketing would tell you, containers need to make assumptions > about outside orchestration/management methods. Folks in this thread have > already identified

Re: [VOTE] Cassandra Enhancement Proposal (CEP) documentation

+1 -Joey On Fri, Nov 1, 2019 at 5:33 AM Mick Semb Wever wrote: > Please vote on accepting the Cassandra Enhancement Proposal (CEP) document > as a starting point and guide towards improving collaboration on, and > success of, new features and significant improvements. In combination with > the

Re: [Discuss] num_tokens default in Cassandra 4.0

Any objections to the compromise of 16 as proposed in Chris's original patch? -Joey On Thu, Jan 30, 2020, 3:47 PM Anthony Grasso wrote: > I think lowering the number of tokens is a great idea! Similar to Jon, when > I have reduced the number of tokens for clients it has been improvement in > re

Re: [Discuss] num_tokens default in Cassandra 4.0

I think that we might be bikeshedding this number a bit because it is easy to debate and there is not yet one right answer. I hope we recognize either choice (4 or 16) is fine in that users can always override us and we can always change our minds later or better yet improve allocation so users don

Re: Idea: Marking required scope for 4.0 GA vs. optional

On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani wrote: > > Can we agree to move the improvements out to 4.0.x? Generally I've been asked to put performance issues as improvements, e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor on real clusters without that patch, and therefore

Re: Google Season of Docs 2020 participation

Given the datastax donation I agree it makes sense for us to propose projects that are unlikely to overlap. What do people think about documentation that is slightly more instructional as opposed to informational? Perhaps some kind of tutorial series on "Practical examples of building useful syste

Re: [VOTE] Project governance wiki doc (take 2)

+1 (nb). Thank you Josh for advocating for these changes! I am curious about how Code Contribution Guideline #2 reading "Code modifications must have been reviewed by at least one other contributor" and Guideline #3 reading "Code modifications require two +1 committer votes (can be author + revie

Re: [VOTE] Project governance wiki doc (take 2)

On Mon, Jun 22, 2020 at 3:23 AM Benedict Elliott Smith wrote: > > If you read the clauses literally there's no conflict - not all committers > that +1 the change need to review the work. It just means that two > committers have indicated they are comfortable with the patch being merged. > One

Re: [VOTE] Accept the Harry donation

+1 (non-binding) On Wed, Sep 16, 2020 at 11:10 AM Jordan West wrote: > > +1 > > On Wed, Sep 16, 2020 at 10:29 AM sankalp kohli > wrote: > > > +1 > > > > On Wed, Sep 16, 2020 at 10:07 AM Ekaterina Dimitrova < > > e.dimitr...@gmail.com> > > wrote: > > > > > +1 (non-binding) > > > > > > On Wed, 16

Re: Repair scheduling tools

I just want to say I think it would be great for our users if we moved repair scheduling into Cassandra itself. The team here at Netflix has opened the ticket and have written a detailed design document

Re: Repair scheduling tools

n > > >>>>> production, and seeing the success of distributed scheduled repair > > here > > >>>> at > > >>>>> Netflix, I strongly believe that adding this to Cassandra would be > a > > >>>> great > > >&

Re: Repair scheduling tools

> compaction. We have large Cassandra deployments and can work > with > > > > > Netflix > > > > > >>> folks for intensive testing to boost user confidence. > > > > > >>> > > > > > >>> On the other hand, have we

Re: Repair scheduling tools

> > I wouldn't trivialize it, scheduling can end up dealing with more than a > single repair. If theres 1000 keyspace/tables, with 400 nodes and 256 > vnodes on each thats a lot of repairs to plan out and keep track of and can > easily cause heap allocation spikes if opted in. > > Chris The curren

Re: Repair scheduling tools

st megabytes of data, and I really do believe would not cause significant, if any, heap pressure. The repairs *themselves* certainly would create heap pressure, but that happens regardless of the scheduler. -Joey On Thu, Apr 5, 2018 at 7:25 PM, Joseph Lynch wrote: > I wouldn't tri

Re: Repair scheduling tools

> > We see this in larger clusters regularly. Usually folks have just > 'grown into it' because it was the default. > I could understand a few dozen nodes with 256 vnodes, but hundreds is surprising. I have a whitepaper draft lying around showing how vnodes decrease availability in large clusters

Re: Roadmap for 4.0

The Netflix team prefers September as well. We don't have time before that to do a full certification (e2e and performance testing), but can probably work it into end of Q3 / start of Q4. I personally hope that the extra time gives us as a community a chance to come up with a compelling user story

Re: Repair scheduling tools

> > I personally would rather see improvements to reaper and supporting reaper > so the repair tool improvements aren't tied to Cassandra releases. If we > get to a place where the repair tools are stable then figuring out how to > bundle for the best install makes sense to me. > I view the design

Re: Repair scheduling tools

Given the feedback here and on the ticket, I've written up a proposal for a repair sidecar tool in the ticket's design document. If there are no major concerns we're going to start working

Quantifying Virtual Node Impact on Cassandra Availability

Josh Snyder and I have been working on evaluating virtual nodes for large scale deployments and while it seems like there is a lot of anecdotal support for reducing the vnode count [1], we couldn't find any concrete math on the topic, so we had some fun and took a whack at quantifying how different

Re: Quantifying Virtual Node Impact on Cassandra Availability

/jolynch/python_performance_toolkit/raw/master/notebooks/cassandra_availability/whitepaper/cassandra-availability-virtual.pdf> On Mon, Apr 16, 2018 at 1:14 PM, Joseph Lynch wrote: > Josh Snyder and I have been working on evaluating virtual nodes for large > scale deployments and while it seems like there is a

Re: Quantifying Virtual Node Impact on Cassandra Availability

e sstables are already split by some > numeric > > > factor that has lots of even divisors (60 for RF 2,3,4,5), you simply > > bulk > > > copy the already-subdivided sstables for the new nodes' hash ranges and > > > you'd basically be done. In AWS EBS volumes, t

Re: Quantifying Virtual Node Impact on Cassandra Availability

hat?) > > > > > > > > Pre-subdivided sstables for manually maanged tokens would REALLY pay > > big > > > > dividends in large-scale cluster expansion. Say you wanted to double > or > > > > triple the cluster. Since the sstables are already split

Re: Welcome Joey Lynch as Cassandra PMC member

Thank you all for the warm wishes and I greatly appreciate this opportunity! This is such a great community and I am proud to be part of it. Cheers! -Joey On Wed, Jul 24, 2024 at 10:12 AM Benjamin Lerer wrote: > The PMC's members are pleased to announce that Joey Lynch has accepted the > invit

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

Congratulations to Jordan and Stefan! -Joey On Tue, Sep 3, 2024 at 10:06 AM Doug Rohrer wrote: > Congrats folks - well deserved. > > Doug > > > On Aug 30, 2024, at 4:18 PM, Jon Haddad wrote: > > > > The PMC's members are pleased to announce that Jordan West and Stefan > Miklosovic have accepte

Re: [DISCUSS] Releases after 4.0

I am slightly concerned about removing support for critical bug fixes in 3.0 on a short time-frame (<1 year). I know of at least a few major installations, including ours, who are just now able to finish upgrades to 3.0 in production due to the number of correctness and performance bugs introduced

Re: [VOTE] Release Apache Cassandra 4.0-rc1

We have been testing the release at various scales and workloads and for the most part everything has been working really well (great performance, zero copy streaming is amazing, compaction is fast, etc ...). However, upon testing incremental repair (currently the default in 4.0) we hit a potential

Re: Welcome Stefan Miklosovic as Cassandra committer

Congratulations, Stefan! On Tue, May 4, 2021 at 9:07 AM Andrés de la Peña wrote: > > Congrats! > > On Tue, 4 May 2021 at 05:47, Berenguer Blasi > wrote: > > > Congrats Stefan! > > > > On 3/5/21 22:24, Yifan Cai wrote: > > > Congrats! > > > > > > On Mon, May 3, 2021 at 1:23 PM Paulo Motta > > wr

Re: Welcome Dinesh Joshi as Cassandra PMC member

Congratulations Dinesh! Well deserved! -Joey On Wed, Jun 2, 2021 at 12:23 PM Benjamin Lerer wrote: > > The PMC's members are pleased to announce that Dinesh Joshi has accepted > the invitation to become a PMC member. > > Thanks a lot, Dinesh, for everything you have done for the project all > t

Re: Welcome Adam Holmberg as Cassandra committer

Congratulations Adam! On Tue, Aug 17, 2021 at 10:25 AM Jordan West wrote: > > Congrats Adam! > > On Tue, Aug 17, 2021 at 5:51 AM Paulo Motta > wrote: > > > Congratulations and well deserved Adam! > > > > Em ter., 17 de ago. de 2021 às 03:58, Sumanth Pasupuleti < > > sumanth.pasupuleti...@gmail.c

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

Benedict, Thank you very much for advancing this proposal, I'm extremely excited to see flexible quorums used in this way and am looking forward to the integration of Accord into Cassandra! I read the whitepaper and have a few questions, but I was wondering what do you think about having some exte

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

> With the proposal hitting the one-month mark, the contributors are interested > in gauging the developer community's response to the proposal. I support this proposal. From what I can understand, this proposal moves us towards having the building blocks we need to correctly deliver some of the

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

1. +1 nb 2. +1 nb 3. +1 nb I am excited to see a real proposal backed by a number of competent engineers that will meaningfully improve our ability to deliver important and complex features for Cassandra. To be frank, I'm somewhat confused as to the dissent on the CEP strategy itself (tactical im

Re: Welcome Sumanth Pasupuleti as Apache Cassandra Committer

Congratulations Sumanth! Well deserved!! -Joey On Fri, Nov 5, 2021 at 11:17 AM Oleksandr Petrov wrote: > > The PMC members are pleased to announce that Sumanth Pasupuleti has > recently accepted the invitation to become committer. > > Sumanth, thank you for all your contributions to the project

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

I also feel that having all the resources to get help in more or less one place (#cassandra-dev slack / ML) probably helps newcomers on the whole since they can ask questions and likely engage with someone who can help. I know that I've asked a few silly questions in #cassandra-dev and appreciated

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

I think a CEP is wise (or a more thorough design document on the ticket) given how easy it is to do security incorrectly and key management, rotation and key derivation are not particularly straightforward. I am curious what advantage Cassandra implementing encryption has over asking the user to u

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

encryption of commit logs and hints already? So this should be > removed? I find it rather strange to offer commit log and hints > encryption at rest but for some reason sstable encryption would be > omitted. > > On Tue, 16 Nov 2021 at 15:46, Joseph Lynch wrote: > > > > I think

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

ely encrypt some tables, but leave others unencrypted. Doing > this outside Cassandra on the filesystem level is very tedious and > error-prone - a lots of symlinks and pretty hard to handle newly created > tables or keyspaces. > > However, I don't know if there's enough dem

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

On Thu, Nov 18, 2021 at 7:23 PM Kokoori, Shylaja 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. Like

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> > I've seen this be a significant obstacle for people who want to adopt > Apache Cassandra many times and an insurmountable obstacle on multiple > occasions. From what I've seen, I think this is one of the most watched > tickets with the most "is this coming soon" comments in the project backlog

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> > 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. > I am for re

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> > Yes, this needs to be done. The credentials for this stuff should be > just fetched from wherever one wants. 100% agree with that and that > maybe next iteration on top of that, should be rather easy. This was > done in CEP-9 already for SSL context creation so we would just copy > that approac

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> 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

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> 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

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

On Fri, Nov 19, 2021 at 9:52 AM Derek Chen-Becker wrote: > > https://bugs.openjdk.java.net/browse/JDK-7184394 added AES intrinsics in > Java 8, in 2012. While it's always possible to have a regression, and it's > important to understand the performance impact, stories of 2-10x sound > apocryphal.

Re: [DISCUSS] Nested YAML configs for new features

Isn't one of the primary reasons to have a YAML configuration instead of a properties file is to allow typed and structured (implies nested) configuration? I think it makes a lot of sense to group related configuration options (e.g. a feature) into a typed class when we're talking about more than o

Re: [DISCUSS] Nested YAML configs for new features

On Wed, Nov 24, 2021 at 5:55 AM Jacek Lewandowski wrote: > > I am just wondering how to represent in properties things like lists of > non-scalar values? > In my experience properties are not sufficient for complex configuration sorta for this reason, that's why using structured YAML (or any stru

Re: [DISCUSS] Nested YAML configs for new features

On Wed, Nov 24, 2021 at 9:00 AM Bowen Song wrote: > Structured / nested config is easier for human eyes to read but very > hard for simple scripts to handle. Flat config is harder for human eyes > but easy for simple scripts. I can see user may prefer one over another > depending on their own use

Re: [DISCUSS] Nested YAML configs for new features

On Mon, Nov 29, 2021 at 11:51 AM bened...@apache.org wrote: > > Maybe we can make our query language more expressive 😊 > > We might anyway want to introduce e.g. a LIKE filtering option to > find/discover flattened config parameters? This sounds more complicated than just having the settings vir

Re: [VOTE] Formalizing our CI process

> No release can be cut without a fully green CI run on ci-cassandra.apache.org I appreciate the goal but this seems problematic given all four release branches (2.2, 3.0, 3.11, 4.0) + trunk appear to have about 15-20 failures on ci-cassandra.apache.org at the time of this vote. If this vote passe

Re: [VOTE] Formalizing our CI process

On Wed, Jan 12, 2022 at 12:47 AM Berenguer Blasi wrote: > > We shouldn't be at 15-20 failures but at 2 or 3. The problem is that those 2 > or 3 have already been hammered for over a year by 2 or 3 different > committers and they didn't crack. > Last I checked circleci was almost fully green on

Re: [VOTE] Formalizing our CI process

On Tue, Jan 11, 2022 at 4:48 PM Joshua McKenzie wrote: >> If this vote passes would that mean we cannot cut any release > > We would not cut a release with known failing tests, no. Which for critical > infrastructure software _seems_ like it should probably be table stakes, no? > While I very mu

Re: [VOTE] Formalizing our CI process

the 2/3 flakies. Most >> current failures imo are timeuuid C17133 or early termination of process >> C17140 related afaik. So getting back to the 2/3 'impossible' flakies >> should be doable and a reasonable target (famous last words...). My 2cts. >> >> Regards

Re: [VOTE] Formalizing our CI process

On Wed, Jan 12, 2022 at 3:25 AM Berenguer Blasi wrote: > > jenkins CI was at 2/3 flakies consistently post 4.0 release. That is really impressive and I absolutely don't mean to downplay that achievement. > Then things broke and we've been working hard to get back to the 2/3 flakies. > Most > cu

Re: [VOTE] Formalizing our CI process

On Wed, Jan 12, 2022 at 11:43 AM Joshua McKenzie wrote: > > I fully concede your point and concern Joey but I propose we phrase that > differently to emphasize the importance of clean tests. > > "All releases by default are expected to have a green test run on > ci-cassandra Jenkins. In exceptio

  1   2   >