Re: [VOTE] Simplifying our release versioning process

Isn't the JDK we build with when publishing to maven somewhat of a public interface due to cassandra-all library usage? I agree that we probably just need to clearly document what JVMs we test a release on which is a good signal for what we think will work at runtime (and this may be a much newer J

Re: [VOTE] Simplifying our release versioning process

+1 given "Have it for *at least* 1 MAJOR in deprecated status (deprecate-then-remove)" How does that sit with you Joey? > Great! Really appreciate the clarification! -Joey

Re: [VOTE] Simplifying our release versioning process

I'm unclear if Josh/Ekaterina/Benedict's statements are part of the vote amending our project governance. If consensus is required for breaking changes with a strong preference for not breaking I am +1, but the original text of Josh's proposal is merely "We use a deprecate-then-remove strategy for

Re: [DISCUSS] How we version our releases

On Mon, Apr 21, 2025 at 3:12 PM Miklosovic, Stefan via dev < dev@cassandra.apache.org> wrote: > Seeing this thread where we discuss about deprecations, I use this for > asking if there is some action to take when looking into (1) I conducted a > small research for some time ago. > > > > There are

Re: [DISCUSS] How we version our releases

On Mon, Apr 21, 2025 at 9:20 AM Josh McKenzie wrote: > Honestly, excepting thrift support I can't remember something we removed > from the system in this way so a lot of this is perhaps premature process > optimization. > That is definitely fair, as long as we don't go deprecating things after a

Re: [DISCUSS] How we version our releases

I feel like the "T-1" approach only really makes sense if there are additional time guarantees with features that have left experimental status. I agree it is good to shift our versions to the left (folks already treated the concatenation of major.minor as our major), but I agree with Benedict and

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

+1 On Mon, Mar 10, 2025 at 1:28 PM Patrick McFadin wrote: > +1 > > On Mon, Mar 10, 2025 at 9:28 AM Dinesh Joshi wrote: > >> +1 >> >> On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote: >> >>> Please vote on the acceptance of the Cassandra Cluster Manager (CCM) >>> and its IP Clearance: >>> h

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

r (my user table), some stuff you want to LRU (infrequently > accessed nightly jobs), and some stuff you want to tier off (user > engagement). > > What it really boils down to are these properties: > > * Do we upload to object store when writing the SSTable? > * Do we upload after a

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

Great discussion - I agree strongly with Jon's points, giving operators this option will make many operator's lives easier. Even if you still have to have 100% disk space to meet performance requirements, that's still much more efficient than you can run C* with just disks (as you need to leave hea

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congratulations Ekaterina - very well deserved! On Tue, Mar 4, 2025 at 3:25 PM Paulo Motta wrote: > Aloha, > > The Project Management Committee (PMC) for Apache Cassandra is delighted > to announce that Ekaterina Dimitrova has joined the PMC! > > Thanks a lot, Ekaterina, for everything you have

Re: Patrick McFadin joins the PMC

Wahoo! Congratulations Patrick! -Joey On Wed, Jan 22, 2025 at 11:06 AM Jordan West wrote: > The PMC's members are pleased to announce that Patrick McFadin has accepted > an invitation to become a PMC member. > > Thanks a lot, Patrick, for everything you have done for the project all > these yea

Re: Status of CEP-1

/CK23JSY2K/p173177560319 On Sat, Nov 16, 2024 at 10:20 AM Joseph Lynch wrote: > Oh I didn't agree we needed a new CEP, I thought we were agreeing on > focusing on releasing the sidecar as is. CEP-1 was already voted on, we > built consensus on the controversial part (having functionality ou

Re: Status of CEP-1

gt; > > > > > one. It achieves the same end goal and we can create new CEPs > for the scope > > > > > > that is deferred. > > > > > > > > > > > > Dinesh > > > > > > > > > > > > On Mon, Oct 14, 2024 at 4:51 PM Pat

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Fri, Nov 8, 2024 at 10:42 PM Jordan West wrote: > +1 > > On Wed, Nov 6, 2024 at 11:15 Chris Lohfink wrote: > >> +1 >> >> On Wed, Nov 6, 2024 at 11:10 AM Francisco Guerrero >> wrote: >> >>> +1 (nb) >>> >>> On 2024/11/06 14:07:47 "Tolbert, Andy" wrote: >>> > +1 (nb) >>> > >>> > On Tue, Nov

Re: [Discuss] Repair inside C*

Definitely like this in C* itself. We only changed our proposal to putting repair scheduling in the sidecar before because trunk was frozen for the foreseeable future at that time. With trunk unfrozen and development on the main process going at a fast pace I think it makes way more sense to integr

Re: Status of CEP-1

Hi everyone! I am curious what Dinesh's perspective is but I think the specific enumerated scope in CEP-1 isn't super critical to be honest. That CEP successfully (imo) built consensus that the community wants a separate management process, and that sidecar both exists today and has useful functio

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: 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: 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: 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: [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: [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] 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] 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: [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: 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: 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: Should we change 4.1 to G1 and offheap_objects ?

It seems like this is a choice most users might not know how to make? On Thu, Nov 17, 2022 at 7:06 AM Josh McKenzie wrote: > > Have we ever discussed including multiple profiles that are simple to swap > between and documented for their tested / intended use cases? > > Then the burden of having

Re: Should we change 4.1 to G1 and offheap_objects ?

I'm surprised we released 4.0 without changing the default to G1 given that many Cassandra deployments have changed the project's default because it is incorrect. I know that 7486 broke a user 7 years ago, but I think we have had a ton of testing since then in the community to build our confidence.

Re: Thanks to Nate for his service as PMC Chair

Thank you for all your work and dedication Nate, it has been greatly appreciated. Congratulations Mick, we are in good hands with you as chair! -Joey On Mon, Jul 11, 2022 at 5:54 AM Paulo Motta wrote: > > Hi, > > I wanted to announce on behalf of the Apache Cassandra Project Management > Commi

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

+1 nb Really excited for this, Thank you Branimir! -Joey On Wed, Feb 16, 2022 at 12:58 AM Branimir Lambov wrote: > > Hi everyone, > > I'd like to propose CEP-19 for approval. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation > Discussi

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

Woo Congratulations to the new committers and I am so excited to see the project recognizing these contributions! -Joey On Tue, Feb 15, 2022 at 10:13 AM Benjamin Lerer wrote: > > The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez > and Lorina Poland have accepted the i

Re: [GSOC] Call for Mentors

Hi Paulo! Thanks for organizing this. I would like to propose CASSANDRA-17381 [1] which will implement/verify BoundedReadCompactionStrategy for this year's GSOC and I can mentor (although I think we may need a co-mentor?). Please let me know if there is any further context I need to provide or jir

Re: [VOTE] Formalizing our CI process

> "All releases by default are expected to have a green test run on > ci-cassandra 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." +1 with amendmen

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

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

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

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

> 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: [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: [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 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

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

> 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

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

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

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

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

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

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

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: [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: 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: [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: [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: [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: 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: 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 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: [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: [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] 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: [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] 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: 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: 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: [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: [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: [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: 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] 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: [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)

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: 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: 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: 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: 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: 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: [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: [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 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] 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: 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: 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: 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: 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

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

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: [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: 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: [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: [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: 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: 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 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: 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

  1   2   >