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

2011-09-25 Thread Mick Semb Wever
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

2016-08-16 Thread Mick Semb Wever
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

2016-09-15 Thread Mick Semb Wever
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

2016-09-09 Thread Mick Semb Wever
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

2016-09-30 Thread Mick Semb Wever
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

2016-08-28 Thread Mick Semb Wever
> 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

2016-11-17 Thread Mick Semb Wever
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

2016-11-15 Thread Mick Semb Wever
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

2016-11-20 Thread Mick Semb Wever
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

2017-10-02 Thread Mick Semb Wever
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

2017-10-04 Thread Mick Semb Wever
> > 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

2018-07-03 Thread Mick Semb Wever
> > > 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

2018-08-05 Thread Mick Semb Wever
> 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

2018-08-08 Thread Mick Semb Wever
> > > > 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

2018-08-06 Thread Mick Semb Wever
> > 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

2018-08-08 Thread Mick Semb Wever
> 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

2018-08-21 Thread Mick Semb Wever
> > 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

2018-08-22 Thread Mick Semb Wever
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

2018-08-23 Thread Mick Semb Wever
> 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

2018-08-28 Thread Mick Semb Wever
> 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

2018-08-20 Thread Mick Semb Wever
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

2018-08-27 Thread Mick Semb Wever
> 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

2018-08-27 Thread Mick Semb Wever
> 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

2018-08-23 Thread Mick Semb Wever
> > 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

2018-09-05 Thread Mick Semb Wever
> 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

2018-08-30 Thread Mick Semb Wever
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

2018-09-07 Thread Mick Semb Wever
> 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

2018-09-07 Thread Mick Semb Wever
> 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

2018-07-09 Thread Mick Semb Wever
> 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

2018-07-12 Thread Mick Semb Wever
> 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

2018-03-19 Thread Mick Semb Wever
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

2018-10-21 Thread Mick Semb Wever
> 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

2018-10-19 Thread Mick Semb Wever
> 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

2018-10-04 Thread Mick Semb Wever
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

2018-09-27 Thread Mick Semb Wever
> 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

2018-09-19 Thread Mick Semb Wever
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

2018-09-24 Thread Mick Semb Wever
> 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

2018-09-23 Thread Mick Semb Wever
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

2018-11-18 Thread Mick Semb Wever
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

2019-01-04 Thread Mick Semb Wever
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

2019-01-06 Thread Mick Semb Wever
> 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

2019-01-16 Thread Mick Semb Wever
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

2019-01-14 Thread Mick Semb Wever
> 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

2018-12-06 Thread Mick Semb Wever
> 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?

2019-01-07 Thread Mick Semb Wever
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?

2019-01-07 Thread Mick Semb Wever
> 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

2018-09-12 Thread Mick Semb Wever
> 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

2018-09-12 Thread Mick Semb Wever
> 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

2018-09-18 Thread Mick Semb Wever
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

2018-12-08 Thread Mick Semb Wever
> 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: [VOTE] Release Apache Cassandra 2.1.21

2019-02-05 Thread Mick Semb Wever
> > 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.

Re: any apache netbeans users out there?

2019-04-02 Thread Mick Semb Wever
> 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?

2019-04-02 Thread Mick Semb Wever
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