Re: Efficient way of figuring out which nodes a set of keys belong to - Hadoop integration

On Thu, 2011-09-22 at 23:34 +0530, Tharindu Mathew wrote: I managed to modify the Hadoop-Cassandra integration to start with a column of a CF used for indexing. Are you chasing CASSANDRA-2878 here? The above issue is waiting on CASSANDRA-1600 which in turn in waiting on CASSANDRA-1034 ~mck

Re: A proposal to move away from Jira-centric development

On 17 August 2016 at 03:47, Benedict Elliott Smith wrote: > What this project really needs, and the board is chomping at the bit about, > is diversity. The fact is, right now DataStax does 95% of the substantive > development on the project, and so they make all the

Re: Proposal - 3.5.1

Totally agree with all the frustrations felt by Jon here. TL;DR Here's a proposal for 4.0 and beyond: that is puts together the comments from Benedict, Jon, Tyler, Jeremy, and Ed; - keep bimonthly feature releases, - revert from tick-tock to SemVer numbering scheme, - during the release vote

Re: Support Multi-Tenant in Cassandra

On 15 July 2016 at 16:38, jason zhao yang wrote: > > May I ask is there any plan of extending functionalities related to > Multi-Tenant? I had needs for this in the past and my questioning always seemed to eventuate to answers along the lines of this should be

Re: Question on assert

On 22 September 2016 at 03:34, Michael Kjellman < mkjell...@internalcircle.com> wrote: > They can both live in harmony and they both serve a purpose. Thanks for writing that Michael. I'm a big fan of assert statements and have over the years seen them add value and stability to projects

Re: in-tree 'Cassandra Development' docs

> So I’m not sure what we can do here, other than perhaps create some sort > of dashboard > to show tickets with unassigned reviewers, and tickets with overdue > reviews. A dashboard would certainly be helpful. What would also be helpful though is to hear some of the ways triage of incoming

Re: Rough roadmap for 4.0

We should continue with 3.X until all the 4.0 blockers have been >> committed - and there are quite a few of them remaining yet. > > And… are we right to presume that all the "roadmap 4.0" issues that don't break any compatibility will be released in the 3.X tock releases leading up to 4.0?

Re: Rough roadmap for 4.0

On 16 November 2016 at 11:45, Aleksey Yeschenko wrote: > > Doesn’t matter what the original plan was. We should continue with 3.X > until all the 4.0 blockers have been > committed - and there are quite a few of them remaining yet. Thanks for the clarity, the quick

Re: Proposals for releases - 4.0 and beyond

On 19 November 2016 at 10:49, Jeff Jirsa wrote: > Option #3: Sylvain proposed [3] feature / testing / stable branches, Y > cadence for releases, X month rotation from feature -> testing -> stable -> > EOL (X to be determined). This is similar to an Ubuntu/Debian like

Re: Proposal to retroactively mark materialized views experimental

On 3 October 2017 at 04:57, Aleksey Yeshchenko wrote: > The idea is to check the flag in CreateViewStatement, so creation of new > MVs doesn’t succeed without that flag flipped. > Obviously, just disabling existing MVs working in a minor would be silly. > As for the warning -

Re: Proposal to retroactively mark materialized views experimental

> > CDC sounds like it is in the same basket, but it already has the > > `cdc_enabled` yaml flag which defaults false. > > I went this route because I was incredibly wary of changing the CL > code and wanted to shield non-CDC users from any and all risk I > reasonably could. This approach so far

Re: Testing 4.0 Post-Freeze

> > > We propose that between the September freeze date and beta, a new branch > would not be created and trunk would only have bug fixes and performance > improvements committed to it. > +1, like really yes!! because it's a step towards a more stable-master project. If trunk is focused on

Re: GitHub PR ticket spam

> I find this a bit annoying while subscribed to commits@, > especially since we created pr@ for these kind of messages. Also I don't > really see any value in mirroring all github comments to the ticket. I agree with you Stefan. It makes the jira tickets quite painful to read. And I tend to

Re: GitHub PR ticket spam

> > > > Great idea. +1 to moving it to the work log. > > > > https://issues.apache.org/jira/browse/INFRA-16879 This is working now. See eg https://issues.apache.org/jira/browse/CASSANDRA-12926 (which I hijacked for testing and the comments in the PR have since been deleted) cheers, mick

Re: GitHub PR ticket spam

> > Great idea. +1 to moving it to the work log. > https://issues.apache.org/jira/browse/INFRA-16879 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail:

Re: Apache Cassandra Blog is now live

> We are also interested in contributing to the blog, what's the process? Dikang, it's part of the website, https://svn.apache.org/repos/asf/cassandra/site/src/README regards, Mick - To unsubscribe, e-mail:

Re: Proposing an Apache Cassandra Management process

> > contributions should be evaluated based on the merit of code and their > > value add to the whole offering. I hope it does not matter whether that > > contribution comes from PMC member or a person who is not a committer. > > > I hope this goes without saying. Absolutely. Joseph and

Re: Supporting multiple JDKs

What do we mean "support multiple JDKs" ? Are we talking Run-time or Compile-time? > If we support multiple JDKs, at a minimum we should compile code against > those JDKs. Why? I really don't get that logic. There's a cost-optimisation here in reducing what we have to support. If we

Re: Supporting multiple JDKs

> However, in addition to using such a > tool, I believe, when we make a release, we should build against the actual > JDKs we support (that way, we are not making a release just based on the > result of an external tool), and we should be able to optionally run UTs > and DTests against the JDK

Re: Reaper as cassandra-admin

> the argument that something new should be written because an existing project > has tech debt, and we'll do it the right way this time, is a pretty common > software engineering mistake. The thing you’re replacing usually needs to > have some really serious problems to make it worth

Re: Proposing an Apache Cassandra Management process

On Fri, 17 Aug 2018, at 14:27, Sankalp Kohli wrote: > I am bumping this thread because patch has landed for this with repair > functionality. We are looking to contribute Reaper to the Cassandra project. Looking at the patch it's very similar in its base design already, but Reaper does

Re: Reaper as cassandra-admin

> Is there a roadmap or release schedule, so we can get an idea of what > the Reaper devs have planned for it? Hi Murukesh, there's no roadmap per se, as it's open-source and it's the contributions as they come that make it. What I know that's in progress or been discussed is: - more

Re: Reaper as cassandra-admin

> Can you get all of the contributors cleared? > What’s the architecture? Is it centralized? Is there a sidecar? Working on it Jeff. Contributors are close to cleared. Copyright is either Spotify or Stefan, both whom have CLAs in place with ASF. Licenses of all npm dependencies are good.

Re: Supporting multiple JDKs

> > There's a cost-optimisation here in reducing what we have to support. > > I agree and animal sniffer is a great way to ferret out obvious issues. > I am not against using animal sniffer. I'm concerned that there are > various incompatibilities[1] between JDK versions and I am not 100% >

Re: Supporting multiple JDKs

> How would we be sure users will never encounter bugs unless we build > against that JDK? Apache Cassandra does not distribute JDK1.7 built releases. The only way a user could repeat such a bug is if they have built C* themselves. I don't think the project should be responsible for every

Re: Supporting multiple JDKs

Hey Sumanth, could you clear a few things up for me… > C* 2.2 > > I'm still a bit confused as to what's the benefit in compiling with > > jdk1.7 and then testing with jdk1.7 or jdk1.8 > > I meant two separate workflows for each JDK i.e. > Workflow1: Build against jdk1.7, and optionally run

Re: Proposing an Apache Cassandra Management process

> How can we continue moving this forward? > > Mick/Jon/TLP folks, is there a path here where we commit the > Netflix-provided management process, and you augment Reaper to work with it? > Is there a way we can make a larger umbrella that's modular that can > support either/both? There seems

Re: QA signup

> Periodic SNAPSHOT builds sounds great. I'd feel much better about builds > published as date- or SHA-stamped snapshots / nightlies rather than > calling them alphas at this point, as everyone's testing work is > beginning. Can someone offer details on what would need to be done to >

Re: Testing 4.0 Post-Freeze

> We have done all this for previous releases and we know it has not worked > well. So how giving it one more try is going to help here. Can someone > outline what will change for 4.0 which will make it more successful? I (again) agree with you Sankalp :-) Why not try something new? It's

Re: [VOTE] Branching Change for 4.0 Freeze

> Vote will be open for 72 hours. +1 (non-binding) - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Debug logging enabled by default since 2.2

gt;> but > >>>>> is hard to protect against regression. In fact, just looking at the > read > >>>>> callback shows two instances of debug log in the client request path > >>>>> (exercise for the reader to “git blame”). > >>>>>> Either we can go clean up all the surprises that leaked through, or > we > >>>>> can turn off debug and start backing out some of the changes in > 10241. > >>>>> Putting stuff like compaction in the same bucket as digest mismatch > and > >>>>> gossip state doesn’t make life materially better for most people. > >>>>>> -- > >>>>>> Jeff Jirsa > >>>>>> > >>>>>> > >>>>>>> On Mar 18, 2018, at 11:21 AM, Jonathan Ellis <jbel...@gmail.com> > >>>> wrote: > >>>>>>> That really depends on whether you're judicious in deciding what to > >>>> log > >>>>> at > >>>>>>> debug, doesn't it? > >>>>>>> > >>>>>>> On Sun, Mar 18, 2018 at 12:57 PM, Michael Kjellman < > >>>> kjell...@apple.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> +1. this is how it works. > >>>>>>>> > >>>>>>>> your computer doesn’t run at debug logging by default. your phone > >>>>> doesn’t > >>>>>>>> either. neither does your smart tv. your database can’t be > running at > >>>>> debug > >>>>>>>> just because it makes our lives as engineers easier. > >>>>>>>> > >>>>>>>>> On Mar 18, 2018, at 5:14 AM, Alexander Dejanovski < > >>>>>>>> a...@thelastpickle.com> wrote: > >>>>>>>>> It's a tiny bit unusual to turn on debug logging for all users by > >>>>> default > >>>>>>>>> though, and there should be occasions to turn it on when facing > >>>> issues > >>>>>>>> that > >>>>>>>>> you want to debug (if they can be easily reproduced). > >>>>>>> > >>>>>>> -- > >>>>>>> Jonathan Ellis > >>>>>>> co-founder, http://www.datastax.com > >>>>>>> @spyced > >>>>> > - > >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>>>> > >>>>> > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Mick Semb Wever Australia The Last Pickle Apache Cassandra Consulting http://www.thelastpickle.com

Re: Proposing an Apache Cassandra Management process

> But I'll try to put together a strawman proposal for the doc(s) over the > weekend. I've thrown something quickly together here: - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 -

Re: Proposing an Apache Cassandra Management process

> Can you share the link to cwiki if you have started it ? > I haven't. But I'll try to put together a strawman proposal for the doc(s) over the weekend. Regards, Mick - To unsubscribe, e-mail:

Re: Proposing an Apache Cassandra Management process

e: > > On Sep 27, 2018, at 7:35 PM, Mick Semb Wever wrote: > > > > Reaper, > > I have looked at this already. > > > Priam, > > I have looked at this already. > > > Marcus Olsson's offering, > > This isn't OSS. > > > CStar, &g

Re: Proposing an Apache Cassandra Management process

> Mick - could you enumerate the list of tools you mentioned earlier? Dinesh, quickly the following come to mind… Reaper, Priam, Marcus Olsson's offering, CStar, OpsCenter. Then there's a host of command line tools like: ic-tools, ctop (was awesome, but is it maintained anymore?),

Re: QA signup

Sorry about the terrible english in my last email. > On the target audience: > > [snip] > For developers building automation around testing and > validation, it’d be great to have a common build to work from rather > than each developer producing these builds themselves. Sure. My question

Re: Moving tickets out of 4.0 post freeze

> I'm totally spitballing here on possible uses of meaningful minors. Continuing the splitballing… What about aligning native protocol or sstable format changes with the minor version? > Regardless, the OP's statement that new features and improvements should go > to 4.0.x seems wrong

Re: Proposing an Apache Cassandra Management process

Dinesh, > Most of the discussion and work was done off the mailing list - there's a > big risk involved when folks disappear for months at a time and resurface > with big pile of code plus an agenda that you failed to loop everyone in > on. Given all the discussions that have been had offline

Re: Proposing an Apache Cassandra Management process

quot;dinesh.jo...@yahoo.com.INVALID" > >> wrote: > >> > >> Thanks for starting this, Mick. I will flesh it out. > >> Dinesh > >> > >> On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever > >> wrote: > >> > >

Cassandra website docs for 3.11 added

The docs for Cassandra-3.11.3 have been added to the website: - http://cassandra.apache.org/doc/3.11/ - http://cassandra.apache.org/doc/3.11.3/ These are not linked to from anywhere. Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do this next week if no one objects.

Re: Cassandra website docs for 3.11 added

> Next step it to regenerate the docs for Cassandra-4.0 (latest). I'll do > this next week if no one objects. This has been done by Joey Lynch, Anthony Grasso and myself . See https://cassandra.apache.org/doc/latest/ > a) list and link to the different versions of the docs A very basic

Re: Warn about SASI usage and allow to disable them

Regarding the warning, we might add it at least in 3.11, since for that version the property to enable SASI is going to be present but not disabled by default. WDYT? I'm -0 on this. A single line warning in the logs on the sasi creation won't be noticed by many users. A cqlsh warning only

Re: Warn about SASI usage and allow to disable them

> The purpose for this thread is discussing whether we want to add this > warning, the config property and, more controversially, if we want to set > SASI as disabled by default in trunk. I'm +1 on everything, except the warning. I think if we add the config property and it's disabled in

Re: JIRA Workflow Proposals

> Summary: > > 1: Component. (A) Multi-select; (B) Cascading-select > 2: Labels: leave alone +1/-1 > 3: No workflow changes for first/second review: +1/-1 > 4: Priorities: Including High +1/-1 > 5: Mandatory Platform and Feature: +1/-1 > 6: Remove Environment field: +1/-1 > 1: A 2: +1

Who should be in our distribution KEYS file?

And when should it get updated? Currently our KEYS file: that contains the public keys of those that can signed released binary artifacts; only contains a few of the PMC. My understanding is that we've avoid updating it because it causes headache for operators in having to validate the

Re: Who should be in our distribution KEYS file?

> I don't see any reason to have any keys in there, except from release > managers who are signing releases. Shouldn't any PMC (or committer) should be able to be a release manager? The release process should be reliable and reproducible enough to be safe for rotating release managers

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

> But I'd like to see a serious investigation of the options -- feature set, > maturity, maintainer availability, etc -- before making a decision. This > will take some time, but this is a place where "measure twice, cut once" > seems like the right approach. This^ 100%. I dislike the idea

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

> I am hoping all the folks who are saying we should not vote will drive the > other thread. Also note that there is consensus about doing a side car but > no consensus on which approach to take. I hope not deciding which approach > is not a poison pill for side car!! Call me pedantic, but I

Re: QA signup

Scott, > @Mick, thanks for your reply re: publishing snapshots/nightlies. In > terms of what’s needed to configure these, would it be automation around > building release artifacts, publishing jars to the Maven snapshots repo, … Maven artefacts are deployed to the ASF snapshot repository in

Re: JIRA Workflow Proposals

> Of course, if we remove Priority from the Bug type, I agree with others > that the top level priority ceases to mean anything, and there probably > shouldn’t be one. Benedict, another idea, and this might be for down the road, is to have "Severity" or bug types and "Impact" on non-bug

Re: any apache netbeans users out there?

> I am netbeans user and will be checking NetBeans support. Actually NetBeans > supports maven natively and any proper maven project should be able to be > built on netbeans without any modifications. Thanks SZ ! Note Cassandra is (primarily) ant based. The project file in that ticket is

any apache netbeans users out there?

Cassandra currently has project support for IntelliJ and Eclipse, but not NetBeans. If there is anyone who uses netbeans (even occasionally) and could help test the project support proposed in https://issues.apache.org/jira/browse/CASSANDRA-15073 it would be really appreciated :-) This is

Re: [VOTE] Release Apache Cassandra 2.1.21

> > I propose the following artifacts for release as 2.1.21. > +1 for this release of 2.1.21 Comments: - we don't really need the checksums on gpg signature files. (Previously releases are also doing this.) I believe they can just be manually deleted from the staging nexus repository.

Acceptable for trunk? Committing the patch for "Customize cassandra log directory" (CASSANDRA-15090)

The ticket CASSANDRA-15090 has a patch to introduce the variable $CASSANDRA_LOG_DIR Strictly speaking it is not a bug, but it is a simple patch that would help some operators. Can I get a waiver on the feature freeze to commit this patch to trunk? cheers, Mick

Re: Acceptable for trunk? Committing the patch for "Customize cassandra log directory" (CASSANDRA-15090)

> Common sense of a committer should be sufficient. Thanks Aleksey :-P - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Time for a new 3.0/3.11 release?

> Is there any chance to get CASSANDRA-15005 (ready, with PR) into a > 3.11.5 release? I doubt it Soroka. It's not a bug and there's no patch for it, so I'd see no reason why Michael would wait for this when he generously finds time to cut a release. Maybe the author and reviewer

Re: Time for a new 3.0/3.11 release?

> I will try and wrap up my review of 14812 today. CASSANDRA-14812 has been committed. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Time for a new 3.0/3.11 release?

> It would be nice to have time to get CASSANDRA-14812 in Yes. I will try and wrap up my review of 14812 today. Another pair of eyes is always welcome, especially anyone with experience on the various StoppingTransformation usages. regards, Mick

Re: 4.0 alpha before apachecon?

> > Let's just pull the trigger on it. We know there are a couple of rough > edges, but that is the point of an alpha. Is the idea to also cut 2.2.15, 3.0.19, and 3.11.5, at the same time as 4.0-alpha1 ? (Michael, have you the cycles for this?) regards, Mick

Re: Builds email notifications

> This is going to be a job('Cassandra-template-artifacts') {publishers > ...} step in the template, if I recall. Not sure what email plugins are > installed. I'd be happy to look at a PR. Quick or the dead around here :-) It has been done manually, and a separate PR opened here:

[DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

With the feature freeze for 4.0 getting a little closer to its end, and after Scott's NGCC presentation on how Cassandra can be better at moving forward, I'm keen to bring up the idea of a "Cassandra Enhancement Proposal" (CEP) process. Big changes in the past have not always been as

Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

> I think we need to have a meta discussion about the goal for > introducing a new process. Indeed, and these were only two brief examples that came to me. Another, using the sidecar proposal as an example, is simply to ensure a little patience is taken during the initial brainstorming

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

> 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. I agree. I'm -0 (non-binding anyway) on the release for this reason. > If people

Re: How to stop github notification emails?

> https://issues.apache.org/jira/browse/INFRA-18982 Marcus, instead of ignoring them can we send them to pr@ (or commits@) please? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands,

Re: Ideas for removing unnecessary friction in contributing to docs/website.

> The website should be the easiest thing for people to work on. Most of the > documentation should be easy as well. Not all documentation has a 1-1 > correlation to code. > > The Website and Documentation are sibling artifacts in my opinion, but the > website shouldn't have a hard dependency

Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

> To be really clear, I do not refer to the flexible definition of the > process, but to whether participation in even a modest interpretation > of the process is necessary at all. Benedict, could you check the document now. The 'Purpose' section has been updated to meet your input around

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

> Seems like the intersection of this is: "Lazy consensus is simply an > announcement of 'silence gives assent.'" with a caveat of "you have N hours > to dissent before we take silence as assent" when you're unsure or a topic > is contentious, which tracks with what I've seen kind of informally

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

On Fri, 1 Nov 2019, at 13:32, 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. Thanks everyone, e

[VOTE] Cassandra Enhancement Proposal (CEP) documentation

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 recently accepted Cassandra Release Lifecycle documentation this should

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

> Update on test runs: `ant test-burn` was failing in trunk.    https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-trunk-test-burn/934/testReport/org.apache.cassandra.net/ConnectionBurnTest/initializationError/ This is now fixed with 3522b54 I'm also seeing a regression of

Re: Improving our frequency of (patch) releases, and letting committers make releases

> I believe some basic distribution changes would greatly help the entire > question here, including making release builds easier for other people > to perform, shortening the cycle times as desired. If there is some > interest in building releases, I would like some help solving the >

Re: [DISCUSS] Proposing an Cassandra Enhancement Proposal (CEP) process

> The 'Purpose' section has > been updated to meet your input around the flexibility of participation > (and process). I think it is what you are after, but ofc I could be > wrong (or it doesn't go far enough?). Feel free to edit the doc as well. The "Cassandra Enhancement Proposal"

Improving our frequency of (patch) releases, and letting committers make releases

> We're still in the position where only four people in the project: > Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a > release. Our current patch release frequency is lacking. It's been 8 months since 3.11.4. This is having an impact on users and their faith in the

Re: [VOTE] Release Apache Cassandra 2.2.15

> I propose the following artifacts for release as 2.2.15. > > sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative > Artifacts: >

Spotify’s backup tool "Medusa" is now open source

In case you missed it on the users' list, Spotify and The Last Pickle have open sourced this tool for Cassandra backups. https://thelastpickle.com/blog/2019/11/05/cassandra-medusa-backup-tool-is-open-source.html In the spirit of OSS we'd love all the input and collaboration on this tool that

Re: moving the site from SVN to git

> Personally, no, I don't. What I need to know is if someone who actually > works on the site needs the history in *git*. Yes. I need the history in *git*. And I believe that INFRA can do the migration for you. (For example, INFRA-12055 and spark-website)

Re: [VOTE-2] Apache Cassandra Release Lifecycle

> We have discussed in the email thread[1] about Apache Cassandra Release > Lifecycle. We came up with a doc[2] for it. We have finalized the doc > here[3] Please vote on it if you agree with the content of the doc [3]. +1 nb the doc is good. it adds value for users, and does not need to

Re: time for a release?

> Any reason not to put this up for a vote? If I don't hear anything by > Monday I'll start a vote thread. We're still in the position where only four people in the project: Michael, Sylvain, Jake, and Eric; can cut, stage, and propose a release. Is it time to add more people to our KEYS

[VOTE] Release Apache Cassandra 2.2.16

Proposing the test build of Cassandra 2.2.16 for release. sha1: c4d9e9ca4ade40b956e37935bce68737b0c063b9 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.16-tentative Maven Artifacts:

Re: [VOTE] Release Apache Cassandra 2.2.16

> The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s. +1 (non-binding) Checked:  - gpg signatures (maven artefacts, dist

Re: [VOTE] Release Apache Cassandra 3.0.20

> The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s. +1 (non-binding) Checked: - gpg signatures (maven artefacts, dist

Re: another alpha?

On Tue, 3 Mar 2020, at 00:57, David Capwell wrote: > Personally would prefer to wait on CASSANDRA-15358. In my testing > alpha2+ fails with this frequently on deployed clusters (actively > testing patch). > >> On Mar 2, 2020, at 1:59 PM, Nate McCall wrote: > >> The clash change is important

Re: Cassandra CI Status

> > - parallelise dtests (because 12 hours is wild) > > That's one word for it. :) > > We used to ad hoc take a crack at sorting the individual test times by > longest and taking top-N and seeing if there was LHF to shave off that. > Being on a flight atm, not having that data handy right

Re: [DISCUSS] Switch to using GitHub pull requests?

> My mind set is that by switching to PRs (even if all the conversations are > in JIRA) we can setup automation which helps detect issues before merging. CircleCI can build github forked branches. AFAIK there's no reason to open a PR. The finer granularity of code review comments can also be

Re: Cassandra CI Status

> > If I don't hear any objection, I'll commit this. Off this, as it > > aggregates test reports, it's now possible to start test posting emails > > with the test report summary, as well as bringing in the dtest builds > > into the pipeline. > > > Based on the pipeline approach I've gotten

Next round of releases…

Jeff brought up yesterday on #cassandra-dev the need for a round of releases, because of CASSANDRA-15400. Does anyone object, or knows of anything in the works that needs to go into the next releases of 2.2, 3.0, 3.11, or trunk? regards, Mick

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

> Proposing the test build of Cassandra 4.0-alpha3 for release. > > sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha3-tentative > Maven Artifacts: >

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

> >> Next step would be to do each package-type install and startup functional > >> testing, > >> but I don't have that time right now :) > > > > > > I'm going to presume others that have voted have done package-type installs > > and the basic testing, and move ahead. [snip] > > I usually

Re: [Discuss] num_tokens default in Cassandra 4.0

> TLDR, based on availability concerns, skew concerns, operational > concerns, and based on the fact that the new allocation algorithm can > be configured fairly simply now, this is a proposal to go with 4 as the > new default and the allocate_tokens_for_local_replication_factor set to > 3.

[VOTE] Release Apache Cassandra 4.0-alpha3

Proposing the test build of Cassandra 4.0-alpha3 for release. sha1: 5f7c88601c65cdf14ee68387ed68203f2603fc29 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha3-tentative Maven Artifacts:

Re: Fwd: [CI] What are the troubles projects face with CI and Infra

Nate, I leave it to you to forward what-you-chose to the board@'s thread. > Are there still troubles and what are they? TL;DR  the ASF could provide the Cassandra community with an isolated jenkins installation: so that we can manage and control the Jenkins master, as well as ensure all

Re: [VOTE] Release Apache Cassandra 4.0-alpha3

> Summary of notes: > - Artifact set checks out OK with regards to key sigs and checksums. > - CASSANDRA-14962 is an issue when not using the current deb build > method (using new docker method results in different source artifact > creation & use). The docker rpm build suffers the same source

[RELEASE] Apache Cassandra 4.0-alpha3 released

The Cassandra team is pleased to announce the release of Apache Cassandra version 4.0-alpha3. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads

Re: [DISCUSS] Switch to using GitHub pull requests?

> In my opinion/experience, this is all a direct consequence of lack of trust > in CI caused by flakiness. The challenge of this project's test state certainly feel like an insurmountable challenge at times… Having been battling away with Jenkins, because I do have ASF access and don't

Re: [DISCUSS] Switch to using GitHub pull requests?

> Tests fail due to variety of reasons. Some of them fail due to > underlying infrastructural issues. For example, getting a clean run of > Python DTests typically involves rerunning them a couple times. Is it > possible to do that at the test framework level i.e. in Jenkins and/or >

Re: [DISCUSS] Switch to using GitHub pull requests?

> > ASF policy is that patches from contributors that haven't a ICLA > > filed can not have their patches automatically run through any ASF CI > > system. It's up to a committer (or someone who has filed a ICLA) to > > trigger the test run on the patch. > > I couldn't find this CI+ICLA policy

Re: Next round of releases…

> Jeff brought up yesterday on #cassandra-dev the need for a round of > releases, because of CASSANDRA-15400. > > Does anyone object, or knows of anything in the works that needs to go > into the next releases of 2.2, 3.0, 3.11, or trunk? I'll start the release process over the next few

Re: Next round of releases…

> I think there is also an issue with 3.0.19+ which prevents starting up > Cassandra on Windows at all, thus ideally some sort of fix in that area > would be nice to be included as well. The ticket is CASSANDRA-15426, and we'll wait til a fix is in.

Re: [Discuss] num_tokens default in Cassandra 4.0

-1 Discussions here and on slack have brought up a number of important concerns. I think those concerns need to be summarised here before any informal vote. It was my understanding that some of those concerns may even be blockers to a move to 16. That is we have to presume the worse case

[VOTE] Release Apache Cassandra 3.0.20

Proposing the test build of Cassandra 3.0.20 for release. sha1: 89edf5073ba4181dd2f70294cdbcb47f5a45c82e Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.20-tentative Maven Artifacts:

  1   2   3   4   5   6   7   8   9   >