from:"Kenneth Brotman"

RE: Looking for common cases in cassandra fit to autoheal

2019-03-01 Thread Kenneth Brotman

Michael is right.  It's not the topic of this list.  Write me offline and I'll 
be glad to direct you to some resources with the information you are looking 
for.

Kenneth Brotman 

-Original Message-
From: Michael Shuler [mailto:mshu...@pbandjelly.org] On Behalf Of Michael Shuler
Sent: Friday, March 01, 2019 12:49 PM
To: dev@cassandra.apache.org
Subject: Re: Looking for common cases in cassandra fit to autoheal

Your request is not related to the topic of this mailing list, the
development of Apache Cassandra. Your question would be better suited
for the user@ mailing list. Your question is also quite vague, and you
might include some detail or context about what exactly you are looking
for. You may also wish to drop the unenforceable email footer or use a
personal email address, if it's appended by your mail server.

-- 
Kind regards,
Michael
http://www.pbandjelly.org/2011/03/to-whom-it-may-concern/

On 3/1/19 2:33 PM, Sundaramoorthy, Natarajan wrote:
> Can someone please reply? Thanks
>  
>  
> 
> 
> -Original Message-
> From: Sundaramoorthy, Natarajan [mailto:natarajan_sundaramoor...@optum.com] 
> Sent: Wednesday, February 27, 2019 3:17 PM
> To: dev@cassandra.apache.org
> Subject: Looking for common cases in cassandra fit to autoheal
> 
> Can someone please provide some common cases in cassandra which can be 
> candidate for autoheal? Looking for log files and issue..Both from VM and/or 
> pod world welcome...Thanks in advance for help
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
> 
> 
> -
> 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

RE: Roadmap for 4.0

2018-04-04 Thread Kenneth Brotman

So in a vibrant community like ours, each year it is reasonable to expect
that some new features will be ready.  We probably can't predict far in
advance which ones.  So each year whatever is ready, is included in that
year's major release (using a 12 month cycle as an example) and then no one
is rushing to meet a deadline because they are holding up a version, because
that feature will just be able to go in the next version.  No pressure; and
no energy discussing how we will approach each version.  That's a lot of
high caliber talent we are consuming.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Wednesday, April 04, 2018 4:51 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

The group seems to be trying to find a set of features that will define
version 4.0.  I'm saying that makes things way too complicated.  You'll
drift, time will go by, no release because of this or that.  I'm saying
instead, accept that you can't know the time frame really that it will take
to properly develop and test a feature.  You won't want to release it until
it's ready.  So take the pressure and complication out of it.

Every once in a while a nice set of features will be ready and should not be
delayed when they are.  That's when you have a new major release.  Let it
happen more naturally instead of forcing it.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID]
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

I wouldn't want to add anything to a release that isn't ready.  Whatever
isn't ready can go in a future release. 

-Original Message-
From: Scott Andreas [mailto:sc...@paradoxica.net]
Sent: Wednesday, April 04, 2018 4:18 PM
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:

---
Jeff:
>> A hard date for a feature freeze makes sense, a hard date for a 
>> release does not.

Josh:
> Strongly agree. We should also collectively define what "Done" looks 
> like post freeze so we don't end up in bike-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> An "exciting" 4.0 release to me is one that is stable and usable with 
> no perf regressions on day 1 and includes some of the big internal 
> changes mentioned previously.
>
> This will set the community up well for some awesome and exciting 
> stuff that will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott

From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is
ready for release by that date is what will be in that release.

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> wrote:
> Can I suggest a way of defining the next few progressions as a way of
approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the 
> code
as can be ready for a release on a date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant 
> improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be 
> ready
for release in that major version,
> A minor release every 3 months of whatever can be 
> ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea

RE: Roadmap for 4.0

2018-04-04 Thread Kenneth Brotman

The group seems to be trying to find a set of features that will define
version 4.0.  I'm saying that makes things way too complicated.  You'll
drift, time will go by, no release because of this or that.  I'm saying
instead, accept that you can't know the time frame really that it will take
to properly develop and test a feature.  You won't want to release it until
it's ready.  So take the pressure and complication out of it.

Every once in a while a nice set of features will be ready and should not be
delayed when they are.  That's when you have a new major release.  Let it
happen more naturally instead of forcing it.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Wednesday, April 04, 2018 4:23 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

I wouldn't want to add anything to a release that isn't ready.  Whatever
isn't ready can go in a future release. 

-Original Message-
From: Scott Andreas [mailto:sc...@paradoxica.net]
Sent: Wednesday, April 04, 2018 4:18 PM
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:

---
Jeff:
>> A hard date for a feature freeze makes sense, a hard date for a 
>> release does not.

Josh:
> Strongly agree. We should also collectively define what "Done" looks 
> like post freeze so we don't end up in bike-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> An "exciting" 4.0 release to me is one that is stable and usable with 
> no perf regressions on day 1 and includes some of the big internal 
> changes mentioned previously.
>
> This will set the community up well for some awesome and exciting 
> stuff that will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott

From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is
ready for release by that date is what will be in that release.

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> wrote:
> Can I suggest a way of defining the next few progressions as a way of
approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the 
> code
as can be ready for a release on a date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant 
> improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be 
> ready
for release in that major version,
> A minor release every 3 months of whatever can be 
> ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code 
> would
be ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion.
Please see the following two (lengthy) threads from last year for
background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb
9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644
598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

--

RE: Roadmap for 4.0

2018-04-04 Thread Kenneth Brotman

I wouldn't want to add anything to a release that isn't ready.  Whatever
isn't ready can go in a future release. 

-Original Message-
From: Scott Andreas [mailto:sc...@paradoxica.net] 
Sent: Wednesday, April 04, 2018 4:18 PM
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0

Re-raising a point made earlier in the thread by Jeff and affirmed by Josh:

---
Jeff:
>> A hard date for a feature freeze makes sense, a hard date for a 
>> release does not.

Josh:
> Strongly agree. We should also collectively define what "Done" looks 
> like post freeze so we don't end up in bike-shedding hell like we have 
> in the past.
---

Another way of saying this: ensuring that the 4.0 release is of high quality
is more important than cutting the release on a specific date.

If we adopt Sylvain's suggestion of freezing features on a "feature
complete" date (modulo a "definition of done" as Josh suggested), that will
help us align toward the polish, performance work, and dog-fooding needed to
feel great about shipping 4.0. It's a good time to start thinking about the
approaches to testing, profiling, and dog-fooding various contributors will
want to take on before release.

I love how Ben put it:

> An "exciting" 4.0 release to me is one that is stable and usable with 
> no perf regressions on day 1 and includes some of the big internal 
> changes mentioned previously.
>
> This will set the community up well for some awesome and exciting 
> stuff that will still be in the pipeline if it doesn't make it to 4.0.

That sounds great to me, too.

- Scott


From: Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
Sent: Wednesday, April 4, 2018 2:20:59 PM
To: dev@cassandra.apache.org
Subject: RE: Roadmap for 4.0

Focusing on 4.0 release then, lets agree on a date next year. Whatever is
ready for release by that date is what will be in that release.

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com]
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman
<kenbrot...@yahoo.com.invalid> wrote:
> Can I suggest a way of defining the next few progressions as a way of
approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the code
as can be ready for a release on a date sometime next year ;to be decided on
by us this month.
> Versions 4.x: minor releases about every three months starting
after a major release with improvements to the code that can be ready for
release, with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements
are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with
improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready
for release in that major version,
> A minor release every 3 months of whatever can be ready
for release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would
be ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion.
Please see the following two (lengthy) threads from last year for
background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb
9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644
598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
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


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Roadmap for 4.0

2018-04-04 Thread Kenneth Brotman

Focusing on 4.0 release then, lets agree on a date next year. Whatever is ready 
for release by that date is what will be in that release.  

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com] 
Sent: Wednesday, April 04, 2018 12:59 PM
To: dev
Subject: Re: Roadmap for 4.0

On Thu, Apr 5, 2018 at 3:26 AM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
wrote:
> Can I suggest a way of defining the next few progressions as a way of 
> approaching this?
>
> How about something like this:
> Version 4.0:  A major release of as many improvements to the code as 
> can be ready for a release on a date sometime next year ;to be decided on by 
> us this month.
> Versions 4.x: minor releases about every three months starting after 
> a major release with improvements to the code that can be ready for release, 
> with bug fixes as needed done in between.
> Version: 5.0: a major release of whatever significant improvements 
> are ready for release one year after the release of 4.0
> Versions 5.x: minor releases about every three months with 
> improvements, with bug fixes as needed done in between,
> And so on:
> A Major release every 12 months of whatever can be ready for 
> release in that major version,
> A minor release every 3 months of whatever can be ready for 
> release in that minor version.
> Bug fixes as needed.
>
> The folks working on code could then get an idea of when their code would be 
> ready for release version-wise.
>
> Kenneth Brotman

Hi Kenneth,
Appreciate the input, but this is quite a well-trodden path of discussion. 
Please see the following two (lengthy) threads from last year for background:

https://lists.apache.org/thread.html/f7e1fa12ea2fb9c3eb366a04dfd7cab5d0d64eb9f4057ad65bd62ace@%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/684b559bf27b9deca0be0dd9629e6cd1fff5644598180f950ff4f478@%3Cdev.cassandra.apache.org%3E

Let's focus this thread on 4.0 release.

-
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

RE: Roadmap for 4.0

2018-04-04 Thread Kenneth Brotman

Can I suggest a way of defining the next few progressions as a way of 
approaching this? 

How about something like this:
Version 4.0:  A major release of as many improvements to the code as 
can be ready for a release on a date sometime next year ;to be decided on by us 
this month. 
Versions 4.x: minor releases about every three months starting after a 
major release with improvements to the code that can be ready for release, with 
bug fixes as needed done in between.
Version: 5.0: a major release of whatever significant improvements are 
ready for release one year after the release of 4.0
Versions 5.x: minor releases about every three months with 
improvements, with bug fixes as needed done in between,
And so on: 
A Major release every 12 months of whatever can be ready for 
release in that major version,
A minor release every 3 months of whatever can be ready for 
release in that minor version.
Bug fixes as needed.

The folks working on code could then get an idea of when their code would be 
ready for release version-wise.

Kenneth Brotman

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Wednesday, April 04, 2018 8:00 AM
To: dev@cassandra.apache.org
Subject: Re: Roadmap for 4.0

Agreed with Josh.  There’s nothing set in stone after we release 4.0, trying to 
extrapolate what we do here for the rest of humanity’s timeline isn’t going to 
be a useful exercise.

Regarding building a big list - it’s of no value.  In fact, if we’re already 
talking about releasing 4.0 we should really only be merging in small features 
that enhance user experience like improving nodetool output or reasonable 
optimizations.  Merging in big features at the very end of the merge window is 
a really great idea to have dozens of follow up bug fix releases that nobody 
considers stable, where the Coli conjecture always wins.  IMO, it would be 
better / more responsible to merge them into trunk *after* we branch for 4.0. 
Yes, that makes the next release less exciting, but I really don’t think 
“exciting” is what we’re shooting for.  I’m more in favor of stable.

Regarding supporting 3.0 / 3.11, since we’re talking about feature freezing 4.0 
2 months from now, and releasing it *sometime* after that, then add 6 months, 
we’re talking about close to an extra year of 3.0 support.  People are, of 
course, free to continue patching 3.0, back porting fixes, etc, but I am 
completely OK with saying there’s only 9 more months of support starting today.

I’m also in the go straight to 3.11 camp.  I see no reason to upgrade to only 
3.0 if you’re on 2.x.  

Jon

> On Apr 4, 2018, at 6:29 AM, Josh McKenzie <jmcken...@apache.org> wrote:
> 
>> 
>> This discussion was always about the release strategy. There is no 
>> separation between the release strategy for 4.0 and the release 
>> strategy for the project, they are the same thing and what is 
>> intended to be discussed here.
> 
> Not trying to be pedantic here, but the email thread is titled 
> "Roadmap for 4.0" and has been concerned with how we get 4.0 out the 
> door. I don't think it's implicit that whatever strategy we settle on 
> for 4.0 is intended to apply to subsequent releases, since the 3.0.X 
> to 3.X to 4.0 relationship/delta is different than a 4.0 to 5.0 can be 
> expected to be.
> 
> 
>> sidenote: 3.10 was released in January 2017, and while the changes 
>> list for
>> 4.0 is getting quite large there's not much there that's going to win 
>> over users. It's mostly refactorings and improvements that affect 
>> developers more so than users.
> 
> If you assume most 3. users are on 3.10, this argument makes sense. I 
> believe a majority are on 3.0.X or 2.1/2.2, which leaves a minority 
> looking at the small delta from 3.10 to 4.0 in the current form.
> 
> 
> 
> On Wed, Apr 4, 2018 at 8:25 AM, kurt greaves <k...@instaclustr.com> wrote:
> 
>>> 
>>> I'm also a bit sad that we seem to be getting back to our old demons 
>>> of trying to shove as much as we possibly can in the next major as 
>>> if having a feature miss it means it will never happen.
>> 
>> That wasn't the intention of this thread, but that's the response I got.
>> Thought I made it pretty clear that this was about compiling a list 
>> of things that people are currently working on and can commit to 
>> getting finished soon (which should be a relatively small list 
>> considering the limited number of full time contributors).
>> 
>> Of course, we should probably (re-(re-(re-)))start a discussion on 
>> release
>>> "strategy" in parallel because it doesn't seem we have one right 
>>> now, but that's im

RE: Repair scheduling tools

2018-04-03 Thread Kenneth Brotman

Why not make it configurable?  
auto_manage_repair_consistancy: true (default: false)

Then users can use the built in auto repair function that would be created or 
continue to handle it as now.  Default behavior would be "false" so nothing 
changes on its own.  Just wondering why not have that option?  It might 
accelerate progress as others have already suggested.  

Kenneth Brotman

-Original Message-
From: Nate McCall [mailto:zznat...@gmail.com] 
Sent: Tuesday, April 03, 2018 1:37 PM
To: dev
Subject: Re: Repair scheduling tools

This document does a really good job of listing out some of the issues of 
coordinating scheduling repair. Regardless of which camp you fall into, it is 
certainly worth a read.

On Wed, Apr 4, 2018 at 8:10 AM, Joseph Lynch <joe.e.ly...@gmail.com> wrote:
> 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 
> <https://issues.apache.org/jira/browse/CASSANDRA-14346>
> and have written a detailed design document 
> <https://docs.google.com/document/d/1RV4rOrG1gwlD5IljmrIq_t45rz7H3xs9G
> bFSEyGzEtM/edit#heading=h.iasguic42ger>
> that includes problem discussion and prior art if anyone wants to 
> contribute to that. We tried to fairly discuss existing solutions, 
> what their drawbacks are, and a proposed solution.
>
> If we were to put this as part of the main Cassandra daemon, I think 
> it should probably be marked experimental and of course be something 
> that users opt into (table by table or cluster by cluster) with the 
> understanding that it might not fully work out of the box the first 
> time we ship it. We have to be willing to take risks but we also have 
> to be honest with our users. It may help build confidence if a few 
> major deployments use it (such as Netflix) and we are happy of course 
> to provide that QA as best we can.
>
> -Joey
>
> On Tue, Apr 3, 2018 at 10:48 AM, Blake Eggleston 
> <beggles...@apple.com>
> wrote:
>
>> Hi dev@,
>>
>>
>>
>> The question of the best way to schedule repairs came up on 
>> CASSANDRA-14346, and I thought it would be good to bring up the idea 
>> of an external tool on the dev list.
>>
>>
>>
>> Cassandra lacks any sort of tools for automating routine tasks that 
>> are required for running clusters, specifically repair. Regular 
>> repair is a must for most clusters, like compaction. This means that, 
>> especially as far as eventual consistency is concerned, Cassandra 
>> isn’t totally functional out of the box. Operators either need to 
>> find a 3rd party solution or implement one themselves. Adding this to 
>> Cassandra would make it easier to use.
>>
>>
>>
>> Is this something we should be doing? If so, what should it look like?
>>
>>
>>
>> Personally, I feel like this is a pretty big gap in the project and 
>> would like to see an out of process tool offered. Ideally, Cassandra 
>> would just take care of itself, but writing a distributed repair 
>> scheduler that you trust to run in production is a lot harder than 
>> writing a single process management application that can failover.
>>
>>
>>
>> Any thoughts on this?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Blake
>>
>>

-
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

RE: A Simple List of New Major Features Desired for Apache Cassandra Version 4.0

2018-03-31 Thread Kenneth Brotman

Thanks Ben for taking the time to write your response.  I am still learning the 
culture and ways of the group.  I'm admittedly new to the open source way of 
doing things.  I am always anxious to pitch in.  Carry on.  I will leave it 
alone for now.

Kenneth Brotman

-Original Message-
From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Saturday, March 31, 2018 6:59 PM
To: dev@cassandra.apache.org
Subject: Re: A Simple List of New Major Features Desired for Apache Cassandra 
Version 4.0

Thank you, Kenneth, for listening to the PMC and for putting the discussion in 
the correct list. I also appreciate your enthusiasm.

To address a few of your points from your previous emails in no particular
order:

   - There is already a compiled list of features slated for 4.0, this list
   is simply a search using the following JQL on JIRA - `project =
   CASSANDRA AND fixVersion = 4.0 ORDER BY priority DESC, updated DESC`. By
   looking at this list, we can see fixes/patches/features that have been
   committed to trunk as well as tickets that are still in progress but
   someone at some point thought it was likely to land in 4.0
   - I appreciate a desire to create a bucket list of any and all desired
   features for 4.0, the reality is that this is an open source project driven
   by individual contributors and so what goes in 4.0 is largely up to those
   who do the work and put those features in.
   - Whilst it has been a long time since 3.0 was first released, the 3.x
   tick-tock experiment resulted in a large number of major releases in short
   succession and as such, I think most folks are simply recovering from that
   push + there is no longer a march to a vendors drum beat. Hence the slow
   down in major feature release and a focus on getting existing features more
   stable.
   - The major release of 3.11 was only released at the end of June 2017
   and it has had 2 point releases in the meantime.
   - Whilst not having a consistent major release schedule can be
   frustrating for end users and product marketers, not having a stable
   database is far more maddening.
   - Having said that, there is a good body of both large and small changes
   that are in "done/resolved", "patch ready", "awaiting feedback" etc and
   slated for 4.0 which would be good to get out the door. While this is a
   matter of opinion I think it's about reaching a nice balance of having not
   too many changes making it a larger adoption risk and having enough time to
   work on some good things (e.g.
   https://issues.apache.org/jira/browse/CASSANDRA-12229), such that it's
   actually worth working toward cutting a major release.
   - I'd respectfully disagree that we have a "basic collaboration
   challenge". This is primarily a community that communicates by gradually
   moving towards consensus (which takes time) and this thread is simply one
   of the many discussions and interactions that move towards consensus about
   4.0. If anything we are resource/people constrained, but that is true of
   all open source communities.

I've decided to respond on the previous thread, "Roadmap to 4.0"
(however just via the dev list where the discussion should live) with my 
suggestions as I don't want to ignore both Kurt and Jeffs previous 
contributions on this subject.

On Fri, Mar 30, 2018 at 6:49 PM Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
wrote:

> Just list any desired new major features for 4.0 that you want added.  
> I will maintain a compiled list for all to see.  Don't worry about any 
> steps beyond this.  Don't make any judgements about or make any 
> comments at all about what others add.
>
> No judgments at this point.  This is a list of everyone's suggestions.  
> Add your suggestions for new major features you desire to be added for 
> version
> 4.0 only. Keep it simple, not detailed yet.  That comes a few steps 
> from now.  What we have is a basic collaboration challenge.  No problem.
>
> Kenneth Brotman
>
>
>
>
>
> --
Ben Bromhead
CTO | Instaclustr <https://www.instaclustr.com/>
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

A Simple List of New Major Features Desired for Apache Cassandra Version 4.0

2018-03-30 Thread Kenneth Brotman

Just list any desired new major features for 4.0 that you want added.  I
will maintain a compiled list for all to see.  Don't worry about any steps
beyond this.  Don't make any judgements about or make any comments at all
about what others add. 

No judgments at this point.  This is a list of everyone's suggestions.  Add
your suggestions for new major features you desire to be added for version
4.0 only. Keep it simple, not detailed yet.  That comes a few steps from
now.  What we have is a basic collaboration challenge.  No problem.

Kenneth Brotman

RE: Paying off tech debt and correctly naming things

2018-03-22 Thread Kenneth Brotman

Perfect!

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Thursday, March 22, 2018 8:10 AM
To: dev@cassandra.apache.org
Subject: Re: Paying off tech debt and correctly naming things

Cool.  I think there’s general agreement that doing this in as small bites as 
possible is going to be the best approach.  I have no interest in mega patches. 
 

>  The combined approach takes a
> change that's already non-trivially dealing with complex subsystem 
> changes and injects a bunch of trivial renaming noise across unrelated 
> subsystems into the signal of an actual logic refactor.

I agree.  This is why I like the idea of proactively working to improve the 
readability of the codebase as a specific goal, rather than being wrapped into 
some other unrelated patch.  Keeping the scope in check is the challenge.  
Simple class and method renames, as several have pointed out, is easy enough 
with IDEA.  

I’ll start with class renames, as individual patches for each of them.  I’ll be 
sure to call it out on the ML.  First one will be ColumnFamilyStore -> 
TableStore.  

Jon

> On Mar 22, 2018, at 7:13 AM, Jason Brown  wrote:
> 
> Jon,
> 
> Thanks for bringing up this topic. I'll admit that I've been around 
> this code base for long enough, and have enough accumulated history, 
> that I probably can't fully appreciate the impact for a newcomer wrt naming.
> However, as Josh points out, this situation probably happens to "every 
> non-trivially aged code-base ever".
> 
> One thing I'd like to add is that with these types of large 
> refactoring changes, the review effort is non-trivial. This is because 
> the review still has to ensure that correctness is preserved and it's 
> easy to overlook a seemingly innocuous change.
> 
> That being said, I am supportive of this effort. However, I believe 
> it's going to be best, for contributor and reviewer, to break it up 
> into smaller, more digestible pieces. I'd also like to request that we 
> not go whole hog and try to do everything in a compressed time frame; 
> reviewer availability is already stretched thin and I'm afraid of 
> deepening the review queue, especially mine :)
> 
> Thanks,
> 
> -Jason
> 
> 
> 
> 
> On Thu, Mar 22, 2018 at 6:41 AM, Josh McKenzie  wrote:
> 
>>> Some of us have big patches in flight, things that actually pay off 
>>> some technical debt, and dealing with such renames is rebase
>> hell :\
>> For sure, but with a code-base this old / organically grown, I expect 
>> this will always be the case. If we're talking something as simple as 
>> an intellij rename refactor, while menial, couldn't someone with a 
>> giant patch just do the same thing on their side and spend half an 
>> hour of their life clicking next? ;)
>> 
>>> That said, there is good time for such renames - it’s during those 
>>> major refactors and rewrites. When you are changing a subsystem, 
>>> might as well do the appropriate renames.
>> Does that hold true for a code-base with as much static state and 
>> abstraction leaking / bad factoring as we have? (i.e. every 
>> non-trivially aged code-base ever) The combined approach takes a 
>> change that's already non-trivially dealing with complex subsystem 
>> changes and injects a bunch of trivial renaming noise across 
>> unrelated subsystems into the signal of an actual logic refactor.
>> 
>> On Thu, Mar 22, 2018 at 9:31 AM, Aleksey Yeshchenko 
>> 
>> wrote:
>>> Poor and out-of-date naming of things is probably the least serious 
>>> part
>> of our technical debt. Bad factoring, and straight-up
>>> poorly written components is where it’s really at.
>>> 
>>> Doing a big rename for rename sake alone does more harm than it is 
>>> good,
>> sometimes. Some of us have big patches
>>> in flight, things that actually pay off some technical debt, and 
>>> dealing
>> with such renames is rebase hell :\
>>> 
>>> That said, there is good time for such renames - it’s during those 
>>> major
>> refactors and rewrites. When you are
>>> changing a subsystem, might as well do the appropriate renames.
>>> 
>>> —
>>> AY
>>> 
>>> On 20 March 2018 at 22:04:48, Jon Haddad (j...@jonhaddad.com) wrote:
>>> 
>>> Whenever I hop around in the codebase, one thing that always manages 
>>> to
>> slow me down is needing to understand the context of the variable 
>> names that I’m looking at. We’ve now removed thrift the transport, 
>> but the variables, classes and comments still remain. Personally, I’d 
>> like to go in and pay off as much technical debt as possible by 
>> refactoring the code to be as close to CQL as possible. Rows should 
>> be rows, not partitions, I’d love to see the term column family 
>> removed forever in favor of always using tables. That said, it’s a 
>> big task. I did a quick refactor in a branch, simply changing the 
>> ColumnFamilyStore class to TableStore, and pushed it up to GitHub. 
>> [1]
>>> 
>>>

RE: Paying off tech debt and correctly naming things

2018-03-22 Thread Kenneth Brotman

I agree with Jason Brown: good topic to address, effect not trivial.  Going 
whole hog too risky.  Careful meticulous small areas at a time with warning to 
everyone so they can chime in if they are working on that area and would prefer 
it left alone for now.  

I wouldn't want it to delay others things.  For example, not sure where 
everyone is on this but, if Reaper was integrated in Cassandra so it just 
worked away in Cassandra without needing any installation or attention of any 
kind - in time for version 4.0 - would be really cool.

Kenneth Brotman

-Original Message-
From: Jason Brown [mailto:jasedbr...@gmail.com] 
Sent: Thursday, March 22, 2018 7:14 AM
To: dev@cassandra.apache.org
Subject: Re: Paying off tech debt and correctly naming things

Jon,

Thanks for bringing up this topic. I'll admit that I've been around this code 
base for long enough, and have enough accumulated history, that I probably 
can't fully appreciate the impact for a newcomer wrt naming.
However, as Josh points out, this situation probably happens to "every 
non-trivially aged code-base ever".

One thing I'd like to add is that with these types of large refactoring 
changes, the review effort is non-trivial. This is because the review still has 
to ensure that correctness is preserved and it's easy to overlook a seemingly 
innocuous change.

That being said, I am supportive of this effort. However, I believe it's going 
to be best, for contributor and reviewer, to break it up into smaller, more 
digestible pieces. I'd also like to request that we not go whole hog and try to 
do everything in a compressed time frame; reviewer availability is already 
stretched thin and I'm afraid of deepening the review queue, especially mine :)

Thanks,

-Jason

On Thu, Mar 22, 2018 at 6:41 AM, Josh McKenzie <jmcken...@apache.org> wrote:

> > Some of us have big patches in flight, things that actually pay off 
> > some technical debt, and dealing with such renames is rebase
> hell :\
> For sure, but with a code-base this old / organically grown, I expect 
> this will always be the case. If we're talking something as simple as 
> an intellij rename refactor, while menial, couldn't someone with a 
> giant patch just do the same thing on their side and spend half an 
> hour of their life clicking next? ;)
>
> > That said, there is good time for such renames - it’s during those 
> > major refactors and rewrites. When you are changing a subsystem, 
> > might as well do the appropriate renames.
> Does that hold true for a code-base with as much static state and 
> abstraction leaking / bad factoring as we have? (i.e. every 
> non-trivially aged code-base ever) The combined approach takes a 
> change that's already non-trivially dealing with complex subsystem 
> changes and injects a bunch of trivial renaming noise across unrelated 
> subsystems into the signal of an actual logic refactor.
>
> On Thu, Mar 22, 2018 at 9:31 AM, Aleksey Yeshchenko 
> <alek...@apple.com>
> wrote:
> > Poor and out-of-date naming of things is probably the least serious 
> > part
> of our technical debt. Bad factoring, and straight-up
> > poorly written components is where it’s really at.
> >
> > Doing a big rename for rename sake alone does more harm than it is 
> > good,
> sometimes. Some of us have big patches
> > in flight, things that actually pay off some technical debt, and 
> > dealing
> with such renames is rebase hell :\
> >
> > That said, there is good time for such renames - it’s during those 
> > major
> refactors and rewrites. When you are
> > changing a subsystem, might as well do the appropriate renames.
> >
> > —
> > AY
> >
> > On 20 March 2018 at 22:04:48, Jon Haddad (j...@jonhaddad.com) wrote:
> >
> > Whenever I hop around in the codebase, one thing that always manages 
> > to
> slow me down is needing to understand the context of the variable 
> names that I’m looking at. We’ve now removed thrift the transport, but 
> the variables, classes and comments still remain. Personally, I’d like 
> to go in and pay off as much technical debt as possible by refactoring 
> the code to be as close to CQL as possible. Rows should be rows, not 
> partitions, I’d love to see the term column family removed forever in 
> favor of always using tables. That said, it’s a big task. I did a 
> quick refactor in a branch, simply changing the ColumnFamilyStore 
> class to TableStore, and pushed it up to GitHub. [1]
> >
> > Didn’t click on the link? That’s ok. The TL;DR is that it’s almost 
> > 2K
> LOC changed across 275 files. I’ll note that my branch doesn’t change 
> any of the almost 1000 search results of “columnfamilystore” found in 
> the codebase and hundreds of tests f

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-19 Thread Kenneth Brotman

I've been trying to withdraw from the conversation since Friday.

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 9:56 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

And to be explicit about this: I'm going to withdraw from this conversation 
now. I don't think we're generating sufficient signal in this dialog compared 
to the noise.

Thanks for the enthusiasm and input Kenneth.

On Mon, Mar 19, 2018 at 11:48 AM, Josh McKenzie <jmcken...@apache.org>
wrote:

> You missed the point ...  let them do it their way when it makes no
>> difference
>
> If you're suggesting we use a static markdown based generator as the 
> "go to" method for content generation and accept PR's for "New 
> Hotness" (do it their way), then sure, that seems a totally fair 
> compromise. Pretty sure that's not what you're suggesting, and people 
> Wild Westing a contribution to a project, that the project then owns 
> when you get bored of it and move on, doesn't qualify for "makes no 
> difference".
>
> On Mon, Mar 19, 2018 at 11:10 AM, Kenneth Brotman < 
> kenbrot...@yahoo.com.invalid> wrote:
>
>> You missed the point.  If someone can do a good job on something, 
>> just let them do it their way when it makes no difference.  
>> Specifically regarding the website, I should be able to submit HTML, 
>> CSS and JS if I want, others should be able to do it with the static 
>> generator thing if they want.  I could have fixed the website with 
>> complete version specific pages, with some really good text to fill 
>> in where there is none now and so on; and done that several different 
>> ways by now.  I'm donating my time too.  Please keep that in mind.
>>
>> Let me ask again, where are the standards?  How can you leave the 
>> website for the project you will be associated with looking that substandard?
>> Rahul Singh has been making a very important point that different 
>> types of uses with different uses cases use the website. This is a 
>> public website; not an internal site for coders.
>>
>> Kenneth Brotman
>>
>> -Original Message-
>> From: Josh McKenzie [mailto:jmcken...@apache.org]
>> Sent: Monday, March 19, 2018 7:42 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online 
>> documentation
>>
>> Wow. Ok, let's try this again.
>>
>> Josh, you made my point for me.   Lower the barriers to entry
>>
>> Kenneth, I disagree. The C* community is not expressing universal 
>> interest in having a hand-crafted bespoke website, but many have 
>> expressed being open to using markdown to create content. Former: 
>> high barrier to entry *for the community as a whole, not just you.* 
>> Important distinction.
>>
>> If someone like me offers to knock out something that's been a 
>> problem for
>> > the group and can do a very professional job, next time get out of 
>> > the
>> way.
>>
>> It's been a problem because people haven't devoted time to it, not 
>> because they couldn't figure out markdown. The Apache Way is about 
>> consensus, not telling people to get out of the way when they don't 
>> agree with you.
>>
>> I don't make junk Josh.
>>
>> Actions speak louder than words and thus far your tone, 
>> combativeness, and repeated unwillingness to acknowledge what looks 
>> to be a strong general consensus from your peers is the evidence we have to 
>> go on.
>>
>> On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman < 
>> kenbrot...@yahoo.com.invalid> wrote:
>>
>> > Josh, you made my point for me.   Lower the barriers to entry, not throw
>> > extra steps I don’t need at me.  If someone like me offers to knock 
>> > out something that's been a problem for the group and can do a very 
>> > professional job, next time get out of the way.  I don't make junk Josh.
>> > Sorry that Apache is not interested in a site with multi-media 
>> > support; or even sites with complete pages.  Show me one quality 
>> > open source Apache site.  Wake up.  Raise your bar!  Engineers 
>> > shouldn't speak in the language of mediocrity.
>> >
>> > Kenneth Brotman
>> >
>> > -Original Message-
>> > From: Josh McKenzie [mailto:jmcken...@apache.org]
>> > Sent: Monday, March 19, 2018 5:27 AM
>> > To: dev@cassandra.apache.org
>> > Subject: Re: A JIRA proposing a seperate repository for the online 
>> >

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-19 Thread Kenneth Brotman

You missed the point.  If someone can do a good job on something, just let them 
do it their way when it makes no difference.  Specifically regarding the 
website, I should be able to submit HTML, CSS and JS if I want, others should 
be able to do it with the static generator thing if they want.  I could have 
fixed the website with complete version specific pages, with some really good 
text to fill in where there is none now and so on; and done that several 
different ways by now.  I'm donating my time too.  Please keep that in mind.  

Let me ask again, where are the standards?  How can you leave the website for 
the project you will be associated with looking that substandard?  Rahul Singh 
has been making a very important point that different types of uses with 
different uses cases use the website. This is a public website; not an internal 
site for coders.

Kenneth Brotman

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 7:42 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

Wow. Ok, let's try this again.

Josh, you made my point for me.   Lower the barriers to entry

Kenneth, I disagree. The C* community is not expressing universal interest in 
having a hand-crafted bespoke website, but many have expressed being open to 
using markdown to create content. Former: high barrier to entry *for the 
community as a whole, not just you.* Important distinction.

If someone like me offers to knock out something that's been a problem for
> the group and can do a very professional job, next time get out of the way.

It's been a problem because people haven't devoted time to it, not because they 
couldn't figure out markdown. The Apache Way is about consensus, not telling 
people to get out of the way when they don't agree with you.

I don't make junk Josh.

Actions speak louder than words and thus far your tone, combativeness, and 
repeated unwillingness to acknowledge what looks to be a strong general 
consensus from your peers is the evidence we have to go on.

On Mon, Mar 19, 2018 at 10:21 AM, Kenneth Brotman < 
kenbrot...@yahoo.com.invalid> wrote:

> Josh, you made my point for me.   Lower the barriers to entry, not throw
> extra steps I don’t need at me.  If someone like me offers to knock 
> out something that's been a problem for the group and can do a very 
> professional job, next time get out of the way.  I don't make junk Josh.
> Sorry that Apache is not interested in a site with multi-media 
> support; or even sites with complete pages.  Show me one quality open 
> source Apache site.  Wake up.  Raise your bar!  Engineers shouldn't 
> speak in the language of mediocrity.
>
> Kenneth Brotman
>
> -Original Message-
> From: Josh McKenzie [mailto:jmcken...@apache.org]
> Sent: Monday, March 19, 2018 5:27 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online 
> documentation
>
> >
> > I've been writing html a long time; since about 1990.  You're asking 
> > me to learn a weird little program, a static site generator just to 
> > change something I can already do without using a program at all.
>
> You're one person among a community of back-end Java devs. If you want 
> people to contribute to things you need to lower the barriers to 
> entry, not deep-dive into some bespoke thing that may never see the 
> light of day and, when completed, misses the mark on what users of cassandra 
> care about:
> clarity and speed. Also: bus-factor 1 is bad.
>
> Another weird thing: Wouldn't we want a website that is dynamic and
> > multi-media rich?
>
> Personally? No. We're talking function here, not form. As an engineer, 
> I don't want to wade through someone else's idea of what "dynamic and 
> multi-media rich" means when I'm trying to find an answer to something 
> or learn something so I can get on with my job.
>
>
>
> On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall <zznat...@gmail.com> wrote:
>
> > On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman 
> > <kenbrot...@yahoo.com.invalid> wrote:
> > > I don't know what we are doing for the website technologies right 
> > > now
> > because like everything else what we do is not documented anywhere.
> > Where are the servers: the cloud?  What server software are we 
> > running?  How is the html, etc. generated and published?  How is 
> > search
> done for the website?
> >
> > http://cassandra.apache.org/doc/latest/development/documentation.htm
> > l The resulting static HTML from Sphinx is hosted on ASF 
> > infrastructure.
> >
> > 
> > - To unsubscribe, e-ma

RE: Website front page broken links

2018-03-19 Thread Kenneth Brotman

Split the ticket up. Don't leave the home page broken for weeks!  Move the 
third party discussion to another JIRA.  Get the home page fixed ASAP!

Kenneth Brotman

-Original Message-
From: Hannu Kröger [mailto:hkro...@gmail.com] 
Sent: Monday, March 19, 2018 12:43 AM
To: dev@cassandra.apache.org
Subject: Re: Website front page broken links

ah, of course. Sorry for the duplicate.

Hannu

> On 19 Mar 2018, at 09:36, kurt greaves <k...@instaclustr.com> wrote:
> 
> A ticket already exists that covers this, with a patch. just needs 
> some consensus around the third party page.
> https://issues.apache.org/jira/browse/CASSANDRA-14128
> 
> On 19 Mar. 2018 18:26, "Hannu Kröger" <hkro...@gmail.com> wrote:
> 
>> Hello,
>> 
>> I created this ticket
>> https://issues.apache.org/jira/browse/CASSANDRA-14324
>> 
>> Basically the website front page contains manybroken links to 
>> planetcassandra.org
>> 
>> Hannu
>> -
>> 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

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-19 Thread Kenneth Brotman

Josh, you made my point for me.   Lower the barriers to entry, not throw extra 
steps I don’t need at me.  If someone like me offers to knock out something 
that's been a problem for the group and can do a very professional job, next 
time get out of the way.  I don't make junk Josh.  Sorry that Apache is not 
interested in a site with multi-media support; or even sites with complete 
pages.  Show me one quality open source Apache site.  Wake up.  Raise your bar! 
 Engineers shouldn't speak in the language of mediocrity.

Kenneth Brotman  

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Monday, March 19, 2018 5:27 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

>
> I've been writing html a long time; since about 1990.  You're asking 
> me to learn a weird little program, a static site generator just to 
> change something I can already do without using a program at all.

You're one person among a community of back-end Java devs. If you want people 
to contribute to things you need to lower the barriers to entry, not deep-dive 
into some bespoke thing that may never see the light of day and, when 
completed, misses the mark on what users of cassandra care about:
clarity and speed. Also: bus-factor 1 is bad.

Another weird thing: Wouldn't we want a website that is dynamic and
> multi-media rich?

Personally? No. We're talking function here, not form. As an engineer, I don't 
want to wade through someone else's idea of what "dynamic and multi-media rich" 
means when I'm trying to find an answer to something or learn something so I 
can get on with my job.

On Sun, Mar 18, 2018 at 5:12 PM, Nate McCall <zznat...@gmail.com> wrote:

> On Mon, Mar 19, 2018 at 12:41 AM, Kenneth Brotman 
> <kenbrot...@yahoo.com.invalid> wrote:
> > I don't know what we are doing for the website technologies right 
> > now
> because like everything else what we do is not documented anywhere.  
> Where are the servers: the cloud?  What server software are we 
> running?  How is the html, etc. generated and published?  How is search done 
> for the website?
>
> http://cassandra.apache.org/doc/latest/development/documentation.html
> The resulting static HTML from Sphinx is hosted on ASF infrastructure.
>
> -
> 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

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-18 Thread Kenneth Brotman

The answer is right before us:  Let's use Rahul Singh's Awesome Cassandra list 
for now: https://github.com/anant/awesome-cassandra  while he works on some 
other things for us.  I will be submitting contributions to it regularly and 
referencing it as the go to resource.  It will serve us well for now.

Kenneth Brotman

-Original Message-
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Sunday, March 18, 2018 4:41 AM
To: dev@cassandra.apache.org
Subject: RE: A JIRA proposing a seperate repository for the online documentation

I don't know what we are doing for the website technologies right now because 
like everything else what we do is not documented anywhere.  Where are the 
servers: the cloud?  What server software are we running?  How is the html, 
etc. generated and published?  How is search done for the website?

Kenneth Brotman


-Original Message-
From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com]
Sent: Saturday, March 17, 2018 7:12 AM
To: dev@cassandra.apache.org
Subject: RE: A JIRA proposing a seperate repository for the online documentation

Static site generator just takes content from flat files or apis (that can be 
managed from a headless cms) and creates static files or progressive web apps 
that are optimized for speed. Nothing to do with multi-media or dynamic in 
terms of client side javascript / css. It’s just an old technology with a new 
name. Thats how we used to generate sites back in 1990s.. :)

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On Mar 17, 2018, 10:03 AM -0400, Kenneth Brotman 
<kenbrot...@yahoo.com.invalid>, wrote:
> How about if we look at the website a little differently. Isn't it an 
> opportunity to showcase Cassandra and related technologies like search! 
> Shouldn't we be an extraordinary advocate and example of the technology 
> ourselves?
>
> Rahul, your comment on the different users with different use cases was very 
> wise.
>
> I've been writing html a long time; since about 1990. You're asking me to 
> learn a weird little program, a static site generator just to change 
> something I can already do without using a program at all.
>
> Another weird thing: Wouldn't we want a website that is dynamic and 
> multi-media rich?
>
> Kenneth Brotman
>
>
> -Original Message-
> From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com]
> Sent: Saturday, March 17, 2018 5:57 AM
> To: dev@cassandra.apache.org
> Subject: RE: A JIRA proposing a seperate repository for the online 
> documentation
>
> I’ve previously deep dived into Static Site generators and there are numerous 
> ones.
>
> http://leaves.anant.us/#!/leaf/7255?tag=static.site
>
> I don’t like changing technology for the sake of change. I think it’s a 
> stupid waste of time. In one hand I agree, the substance is more important 
> than the form. On the other hand. I [insert f-bomb] hate writing HTML / CSS, 
> or restructured text. Markdown is much easier. Hugo is one of many that if 
> setup right, it can save a ton of time and make it more accessible for people 
> to contribute.
>
> There is a difference however in developer documentation for developers of 
> cassandra, user documentation for cassandra users, documentation for and 
> administrators. They are different users and have different use cases Some 
> need reference style docs, others need guides.
>
> Some good examples, (the software quality not-withstanding), correlate with 
> software propularity are Wordpress. I am not wild about Wordpress, but their 
> codex.wordpress.org has been generally a good “user doc.”
>
> Envision the outcome even if you have to mimic someone else. I don’t mind 
> stealing/copying if it gets us one step further than we are. The reaper docs 
> look easy to maintain and I could care less about Hugo, Hexo, Jekyll, Hyde, 
> KafkasMom, EinsteinsDog, ShrodingersCat static site generator.
>
> I think action should come before decision in open source. Prove something 
> before suggesting a change. Jon’s reaper example is good. If anyone has 
> something better, show it. Prove it.
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Mar 16, 2018, 6:54 PM -0400, Kenneth Brotman 
> <kenbrotman@yahoo.cominvalid>, wrote:
> > There is no need for another program. Keep the code in html, css and js 
> > People can modify that and show proposed changes in that. No need to 
> > convert back and forth from other formats. If someone is doing something 
> > more involved, they probably already have a program themselves.
> >
> > -Original Message-
> > From: beggles...@apple.com [mailto:beggles...@apple.com]
> > Sent: Friday, March 16, 2018 3:16 PM
> > To: dev@cassandra.apache.org
> > Subject: Re: A J

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-18 Thread Kenneth Brotman

I don't know what we are doing for the website technologies right now because 
like everything else what we do is not documented anywhere.  Where are the 
servers: the cloud?  What server software are we running?  How is the html, 
etc. generated and published?  How is search done for the website?

Kenneth Brotman


-Original Message-
From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] 
Sent: Saturday, March 17, 2018 7:12 AM
To: dev@cassandra.apache.org
Subject: RE: A JIRA proposing a seperate repository for the online documentation

Static site generator just takes content from flat files or apis (that can be 
managed from a headless cms) and creates static files or progressive web apps 
that are optimized for speed. Nothing to do with multi-media or dynamic in 
terms of client side javascript / css. It’s just an old technology with a new 
name. Thats how we used to generate sites back in 1990s.. :)

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On Mar 17, 2018, 10:03 AM -0400, Kenneth Brotman 
<kenbrot...@yahoo.com.invalid>, wrote:
> How about if we look at the website a little differently. Isn't it an 
> opportunity to showcase Cassandra and related technologies like search! 
> Shouldn't we be an extraordinary advocate and example of the technology 
> ourselves?
>
> Rahul, your comment on the different users with different use cases was very 
> wise.
>
> I've been writing html a long time; since about 1990. You're asking me to 
> learn a weird little program, a static site generator just to change 
> something I can already do without using a program at all.
>
> Another weird thing: Wouldn't we want a website that is dynamic and 
> multi-media rich?
>
> Kenneth Brotman
>
>
> -Original Message-
> From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com]
> Sent: Saturday, March 17, 2018 5:57 AM
> To: dev@cassandra.apache.org
> Subject: RE: A JIRA proposing a seperate repository for the online 
> documentation
>
> I’ve previously deep dived into Static Site generators and there are numerous 
> ones.
>
> http://leaves.anant.us/#!/leaf/7255?tag=static.site
>
> I don’t like changing technology for the sake of change. I think it’s a 
> stupid waste of time. In one hand I agree, the substance is more important 
> than the form. On the other hand. I [insert f-bomb] hate writing HTML / CSS, 
> or restructured text. Markdown is much easier. Hugo is one of many that if 
> setup right, it can save a ton of time and make it more accessible for people 
> to contribute.
>
> There is a difference however in developer documentation for developers of 
> cassandra, user documentation for cassandra users, documentation for and 
> administrators. They are different users and have different use cases Some 
> need reference style docs, others need guides.
>
> Some good examples, (the software quality not-withstanding), correlate with 
> software propularity are Wordpress. I am not wild about Wordpress, but their 
> codex.wordpress.org has been generally a good “user doc.”
>
> Envision the outcome even if you have to mimic someone else. I don’t mind 
> stealing/copying if it gets us one step further than we are. The reaper docs 
> look easy to maintain and I could care less about Hugo, Hexo, Jekyll, Hyde, 
> KafkasMom, EinsteinsDog, ShrodingersCat static site generator.
>
> I think action should come before decision in open source. Prove something 
> before suggesting a change. Jon’s reaper example is good. If anyone has 
> something better, show it. Prove it.
>
> --
> Rahul Singh
> rahul.si...@anant.us
>
> Anant Corporation
>
> On Mar 16, 2018, 6:54 PM -0400, Kenneth Brotman 
> <kenbrotman@yahoo.cominvalid>, wrote:
> > There is no need for another program. Keep the code in html, css and js 
> > People can modify that and show proposed changes in that. No need to 
> > convert back and forth from other formats. If someone is doing something 
> > more involved, they probably already have a program themselves.
> >
> > -Original Message-
> > From: beggles...@apple.com [mailto:beggles...@apple.com]
> > Sent: Friday, March 16, 2018 3:16 PM
> > To: dev@cassandra.apache.org
> > Subject: Re: A JIRA proposing a seperate repository for the online 
> > documentation
> >
> > It would probably be more productive to list some specific concerns you 
> > have with Hugo. Then explain why you think they make using it a bad idea 
> > Then offer some alternatives.
> >
> > On 3/16/18, 1:18 PM, "Kenneth Brotman" <kenbrot...@yahoo.com.INVALID> wrote:
> >
> > Thanks for that Eric Evans.
> >
> > I'm not sure Hugo is the way to go. I don't see how I would generate the 
> &

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-17 Thread Kenneth Brotman

How about if we look at the website a little differently.  Isn't it an 
opportunity to showcase Cassandra and related technologies like search!  
Shouldn't we be an extraordinary advocate and example of the technology 
ourselves?  

Rahul, your comment on the different users with different use cases was very 
wise.  

I've been writing html a long time; since about 1990.  You're asking me to 
learn a weird little program, a static site generator just to change something 
I can already do without using a program at all.  

Another weird thing: Wouldn't we want a website that is dynamic and multi-media 
rich?

Kenneth Brotman

-Original Message-
From: Rahul Singh [mailto:rahul.xavier.si...@gmail.com] 
Sent: Saturday, March 17, 2018 5:57 AM
To: dev@cassandra.apache.org
Subject: RE: A JIRA proposing a seperate repository for the online documentation

I’ve previously deep dived into Static Site generators and there are numerous 
ones.

http://leaves.anant.us/#!/leaf/7255?tag=static.site

I don’t like changing technology for the sake of change. I think it’s a stupid 
waste of time. In one hand I agree, the substance is more important than the 
form. On the other hand. I [insert f-bomb] hate writing HTML / CSS, or 
restructured text. Markdown is much easier. Hugo is one of many that if setup 
right, it can save a ton of time and make it more accessible for people to 
contribute.

There is a difference however in developer documentation for developers of 
cassandra, user documentation for cassandra users, documentation for and 
administrators. They are different users and have different use cases. Some 
need reference style docs, others need guides.

Some good examples, (the software quality not-withstanding), correlate with 
software propularity are Wordpress. I am not wild about Wordpress, but their 
codex.wordpress.org has been generally a good “user doc.”

Envision the outcome even if you have to mimic someone else. I don’t mind 
stealing/copying if it gets us one step further than we are. The reaper docs 
look easy to maintain and I could care less about Hugo, Hexo, Jekyll, Hyde, 
KafkasMom, EinsteinsDog, ShrodingersCat static site generator.

I think action should come before decision in open source. Prove something 
before suggesting a change. Jon’s reaper example is good. If anyone has 
something better, show it. Prove it.

--
Rahul Singh
rahul.si...@anant.us

Anant Corporation

On Mar 16, 2018, 6:54 PM -0400, Kenneth Brotman <kenbrot...@yahoo.com.invalid>, 
wrote:
> There is no need for another program. Keep the code in html, css and js 
> People can modify that and show proposed changes in that. No need to convert 
> back and forth from other formats. If someone is doing something more 
> involved, they probably already have a program themselves.
>
> -Original Message-
> From: beggles...@apple.com [mailto:beggles...@apple.com]
> Sent: Friday, March 16, 2018 3:16 PM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online 
> documentation
>
> It would probably be more productive to list some specific concerns you have 
> with Hugo. Then explain why you think they make using it a bad idea Then 
> offer some alternatives.
>
> On 3/16/18, 1:18 PM, "Kenneth Brotman" <kenbrot...@yahoo.com.INVALID> wrote:
>
> Thanks for that Eric Evans.
>
> I'm not sure Hugo is the way to go. I don't see how I would generate the 
> quality of work I would want with it. It seems like another example of coders 
> learning and using a more complicated program to generate the code they could 
> have already generated - it’s a disease in the I.T. industry right now. But I 
> could be wrong.
>
> Here's the thing. I've been spending a lot of my time for the past three 
> weeks now trying to help with the website. That is a tiny website. I've never 
> worked with a website that tiny. Bear with me.
>
> I'm studying Jeff Carpenter and Eben Hewitt's book: Cassandra The Definitive 
> Guide 
> https://www.amazon.com/Cassandra-Definitive-Guide-Distributed-Scale/dp/1491933666/ref=sr_1_1?ie=UTF8=1521230539=8-1=cassandra+the+definitive+guide
>  and have already have a terrible itch to start contributing some code. I 
> just want to get set up to do that. The book seems to be a good way to get 
> familiar with the internals and the code of Cassandra.
>
> I can only do so much for the group at one time just like anyone else. I'll 
> only do top quality work. I'll only be a part of top quality work. It could 
> be that I won't feel comfortable with what the group wants to do for the 
> website.
>
> Please keep working on it as it is really embarrassing, terrible, substandard 
> unacceptable beneath professional standards...
>
> I will contribute if it's possible for me to do so. Let's see what we decide 
> to do going forward f

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-16 Thread Kenneth Brotman

Thanks for that Eric Evans.  

I'm not sure Hugo is the way to go.  I don't see how I would generate the 
quality of work I would want with it.  It seems like another example of coders 
learning and using a more complicated program to generate the code they could 
have already generated - it’s a disease in the I.T. industry right now.  But I 
could be wrong.  

Here's the thing.  I've been spending a lot of my time for the past three weeks 
now trying to help with the website.  That is a tiny website.  I've never 
worked with a website that tiny.  Bear with me.  

I'm studying Jeff Carpenter and Eben Hewitt's book: Cassandra The Definitive 
Guide 
https://www.amazon.com/Cassandra-Definitive-Guide-Distributed-Scale/dp/1491933666/ref=sr_1_1?ie=UTF8=1521230539=8-1=cassandra+the+definitive+guide
 and have already have a terrible itch to start contributing some code.  I just 
want to get set up to do that.  The book seems to be a good way to get familiar 
with the internals and the code of Cassandra.

I can only do so much for the group at one time just like anyone else.  I'll 
only do top quality work.  I'll only be a part of top quality work.  It could 
be that I won't feel comfortable with what the group wants to do for the 
website.  

Please keep working on it as it is really embarrassing, terrible, substandard 
unacceptable beneath professional standards...

I will contribute if it's possible for me to do so. Let's see what we decide to 
do going forward for the website.

Kenneth Brotman
(Cassandra coder?) 

-Original Message-
From: Eric Evans [mailto:john.eric.ev...@gmail.com] 
Sent: Friday, March 16, 2018 7:59 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

On Thu, Mar 15, 2018 at 11:40 AM, Kenneth Brotman 
<kenbrot...@yahoo.com.invalid> wrote:
> Well pickle my cucumbers Jon!  It's good to know that you have experience 
> with Hugo, see it as a good fit and that all has been well.  I look forward 
> to the jira epic!
>
> How exactly does the group make such a decision:  Call for final discussion?  
> Call for vote?  Wait for the PMC to vote?

Good question!

Decisions like this are made by consensus; As the person who is attempting to 
do something, you discuss your ideas with the group, listen to the feedback of 
others, and develop consensus around a direction.

This is more difficult than demanding your way, or having someone(s) in a 
position of absolute power tell you what you can and cannot do, but the result 
is better.

> -Original Message-
> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon 
> Haddad
> Sent: Thursday, March 15, 2018 9:24 AM
> To: dev@cassandra.apache.org
> Subject: Re: A JIRA proposing a seperate repository for the online 
> documentation
>
> Murukesh is correct on a very useable, pretty standard process of 
> multi-versioned docs.
>
> I’ll put my thoughts in a JIRA epic tonight.  I’ll be a multi-phase process.  
> Also correct in that I’d like us to move to Hugo for the site, I’d like us to 
> have a unified system between the site & the docs, and hugo has been 
> excellent. We run the reaper site & docs off hugo, it works well.  We just 
> don’t do multi-versions (because we don’t support multiple): 
> https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs 
> <https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs>.
>
> Jon
>
>> On Mar 15, 2018, at 8:57 AM, Murukesh Mohanan <murukesh.moha...@gmail.com> 
>> wrote:
>>
>> On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman 
>> <kenbrot...@yahoo.com.invalid <mailto:kenbrot...@yahoo.com.invalid>>
>> wrote:
>>
>>> Help me out here.  I could have had a website with support for more 
>>> than one version done several different ways by now.
>>>
>>> A website with several versions of documentation is going to have 
>>> sub-directories for each version of documentation obviously.  I've 
>>> offered to create those sub-directories under the "doc" folder of 
>>> the current repository; and I've offered to move the online 
>>> documentation to a separate repository and have the sub-directories 
>>> there.  Both were shot down.  Is there a third way?  If so please just 
>>> spill the beans.
>>>
>>
>> There is. Note that the website is an independent repository. So to 
>> host docs for multiple versions, only the website's repository (or 
>> rather, the final built contents) needs multiple directories. You can 
>> just checkout each branch or tag, generate the docs, make a directory 
>> for that branch or tag in the website repo, and copy the generated 
>> docs there with appropriate modifications.
>>

RE: NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

2018-03-16 Thread Kenneth Brotman

If anyone sees interesting uses of this related to the development of C*, 
please email me privately as the very idea of such an inquiry seems to be 
bothering some folks.

Kenneth Brotman

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Friday, March 16, 2018 5:30 AM
To: dev@cassandra.apache.org
Subject: Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's for 
accelerating demanding HPC workloads

>
> It's off topic if there aren't any C* uses but I wasn't (still not 
> sure) there aren't. Maybe you're missing out.

This dev list is for the development of C*. The type of discussion on this 
email thread should be kept to user@.

On Thu, Mar 15, 2018 at 1:32 PM, Kenneth Brotman < 
kenbrot...@yahoo.com.invalid> wrote:

> It's off topic if there aren't any C* uses but I wasn't (still not 
> sure) there aren't. Maybe you're missing out.
>
> -Original Message-
> From: Jason Brown [mailto:jasedbr...@gmail.com]
> Sent: Thursday, March 15, 2018 10:26 AM
> To: dev@cassandra.apache.org
> Subject: Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's 
> for accelerating demanding HPC workloads
>
> All,
>
> This is completely OFF-TOPIC for this mailing list. Please stop.
>
> -Jason
>
> On Thu, Mar 15, 2018 at 10:09 AM, daemeon reiydelle 
> <daeme...@gmail.com>
> wrote:
>
> > Not so sure they are C* relevant, I build (100's of GPU enabled 
> > node) HPC's that use them for ML, AI, Graph analytics, etc. with the 
> > sources in C* or more typically Hadoop/EMR data.
> >
> >
> > <==>
> > "Who do you think made the first stone spear? The Asperger guy.
> > If you get rid of the autism genetics, there would be no Silicon Valley"
> > Temple Grandin
> >
> >
> > *Daemeon C.M. ReiydelleSan Francisco 1.415.501.0198London 44 020 
> > 8144
> > 9872*
> >
> >
> > On Thu, Mar 15, 2018 at 8:40 AM, Kenneth Brotman < 
> > kenbrot...@yahoo.com.invalid> wrote:
> >
> > > I see things like this
> > > https://www.nvidia.com/en-us/data-center/tesla/#section3 as 
> > > something I might be using in things I help build.  Does anyone 
> > > have any experience with them?
> > >
> > >
> > >
> > > Kenneth Brotman
> > >
> > >
> >
>
>
> -
> 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

RE: NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

2018-03-15 Thread Kenneth Brotman

It's off topic if there aren't any C* uses but I wasn't (still not sure) there 
aren't. Maybe you're missing out.

-Original Message-
From: Jason Brown [mailto:jasedbr...@gmail.com] 
Sent: Thursday, March 15, 2018 10:26 AM
To: dev@cassandra.apache.org
Subject: Re: NVIDIA TESLA: The World's Most Advance Data Center GPU's for 
accelerating demanding HPC workloads

All,

This is completely OFF-TOPIC for this mailing list. Please stop.

-Jason

On Thu, Mar 15, 2018 at 10:09 AM, daemeon reiydelle <daeme...@gmail.com>
wrote:

> Not so sure they are C* relevant, I build (100's of GPU enabled node) 
> HPC's that use them for ML, AI, Graph analytics, etc. with the sources 
> in C* or more typically Hadoop/EMR data.
>
>
> <==>
> "Who do you think made the first stone spear? The Asperger guy.
> If you get rid of the autism genetics, there would be no Silicon Valley"
> Temple Grandin
>
>
> *Daemeon C.M. ReiydelleSan Francisco 1.415.501.0198London 44 020 8144 
> 9872*
>
>
> On Thu, Mar 15, 2018 at 8:40 AM, Kenneth Brotman < 
> kenbrot...@yahoo.com.invalid> wrote:
>
> > I see things like this
> > https://www.nvidia.com/en-us/data-center/tesla/#section3 as 
> > something I might be using in things I help build.  Does anyone have 
> > any experience with them?
> >
> >
> >
> > Kenneth Brotman
> >
> >
>


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-15 Thread Kenneth Brotman

Well pickle my cucumbers Jon!  It's good to know that you have experience with 
Hugo, see it as a good fit and that all has been well.  I look forward to the 
jira epic!  

How exactly does the group make such a decision:  Call for final discussion?  
Call for vote?  Wait for the PMC to vote?  

Kenneth Brotman

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Thursday, March 15, 2018 9:24 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

Murukesh is correct on a very useable, pretty standard process of 
multi-versioned docs.

I’ll put my thoughts in a JIRA epic tonight.  I’ll be a multi-phase process.  
Also correct in that I’d like us to move to Hugo for the site, I’d like us to 
have a unified system between the site & the docs, and hugo has been excellent. 
We run the reaper site & docs off hugo, it works well.  We just don’t do 
multi-versions (because we don’t support multiple): 
https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs 
<https://github.com/thelastpickle/cassandra-reaper/tree/master/src/docs>. 

Jon

> On Mar 15, 2018, at 8:57 AM, Murukesh Mohanan <murukesh.moha...@gmail.com> 
> wrote:
> 
> On Fri, Mar 16, 2018 at 0:19 Kenneth Brotman 
> <kenbrot...@yahoo.com.invalid <mailto:kenbrot...@yahoo.com.invalid>>
> wrote:
> 
>> Help me out here.  I could have had a website with support for more 
>> than one version done several different ways by now.
>> 
>> A website with several versions of documentation is going to have 
>> sub-directories for each version of documentation obviously.  I've 
>> offered to create those sub-directories under the "doc" folder of the 
>> current repository; and I've offered to move the online documentation 
>> to a separate repository and have the sub-directories there.  Both 
>> were shot down.  Is there a third way?  If so please just spill the beans.
>> 
> 
> There is. Note that the website is an independent repository. So to 
> host docs for multiple versions, only the website's repository (or 
> rather, the final built contents) needs multiple directories. You can 
> just checkout each branch or tag, generate the docs, make a directory 
> for that branch or tag in the website repo, and copy the generated 
> docs there with appropriate modifications.
> 
> I do this on a smaller scale using GitHub Pages (repo:
> https://github.com/murukeshm/cassandra 
> <https://github.com/murukeshm/cassandra> site:
> https://murukeshm.github.io/cassandra/ 
> <https://murukeshm.github.io/cassandra/>
> <https://murukeshm.github.io/cassandra/3.11.1/ 
> <https://murukeshm.github.io/cassandra/3.11.1/>> ). The method is a 
> bit hacky as I noted in CASSANDRA-13907. A daily cronjobs updated the repo if 
> docs are updated. 3.9+ versions are available.
> 
> 
> 
> 
>> Also, no offense to anyone at Sphinx but for a project our size it's 
>> not suitable.  We need to move off it now.  It's a problem.
>> 
>> Can we go past this and on to the documenting!  Please help resolve this.
>> 
>> How are we going to:
>> Make the submission of code changes include required changes to 
>> documentation including the online documentation?
>> Allow, encourage the online documentation to publish multiple 
>> versions of documentation concurrently including all officially supported 
>> versions?
> 
> 
> Only on this point: we'll need to start by improving the website build 
> process. Michael's comment on 13907 (
> https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentId
> =16211365=com.atlassian.jira.plugin.system.issuetabpanels:comment
> -tabpanel#comment-16211365 
> <https://issues.apache.org/jira/browse/CASSANDRA-13907?focusedCommentI
> d=16211365=com.atlassian.jira.plugin.system.issuetabpanels:commen
> t-tabpanel#comment-16211365>
> )
> shows it's a painful, fiddly process. That seems to be the main 
> blocker. I think Jon has shown interest in moving to Hugo from the 
> current Jekyll setup.
> 
> 
> 
>> Move our project onto a more suitable program than Sphinx for our needs?
>> 
>> Kenneth Brotman
>> 
>> -Original Message-
>> From: Eric Evans [mailto:john.eric.ev...@gmail.com]
>> Sent: Thursday, March 15, 2018 7:50 AM
>> To: dev@cassandra.apache.org
>> Subject: Re: A JIRA proposing a seperate repository for the online 
>> documentation
>> 
>> On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh 
>> <rahul.xavier.si...@gmail.com>
>> wrote:
>>> 
>>> I don’t understand why it’s so complicated. In tree docs

NVIDIA TESLA: The World's Most Advance Data Center GPU's for accelerating demanding HPC workloads

2018-03-15 Thread Kenneth Brotman

I see things like this
https://www.nvidia.com/en-us/data-center/tesla/#section3 as something I
might be using in things I help build.  Does anyone have any experience with
them?  

 

Kenneth Brotman

RE: A JIRA proposing a seperate repository for the online documentation

2018-03-15 Thread Kenneth Brotman

Help me out here.  I could have had a website with support for more than one 
version done several different ways by now.  

A website with several versions of documentation is going to have 
sub-directories for each version of documentation obviously.  I've offered to 
create those sub-directories under the "doc" folder of the current repository; 
and I've offered to move the online documentation to a separate repository and 
have the sub-directories there.  Both were shot down.  Is there a third way?  
If so please just spill the beans.

Also, no offense to anyone at Sphinx but for a project our size it's not 
suitable.  We need to move off it now.  It's a problem.

Can we go past this and on to the documenting!  Please help resolve this.  

How are we going to:
Make the submission of code changes include required changes to documentation 
including the online documentation?
Allow, encourage the online documentation to publish multiple versions of 
documentation concurrently including all officially supported versions?
Move our project onto a more suitable program than Sphinx for our needs?

Kenneth Brotman

-Original Message-
From: Eric Evans [mailto:john.eric.ev...@gmail.com] 
Sent: Thursday, March 15, 2018 7:50 AM
To: dev@cassandra.apache.org
Subject: Re: A JIRA proposing a seperate repository for the online documentation

On Thu, Mar 15, 2018 at 4:58 AM, Rahul Singh <rahul.xavier.si...@gmail.com> 
wrote:
>
> I don’t understand why it’s so complicated. In tree docs are as good as any. 
> All the old docs are there in the version control system.
>
> All we need to is a) generate docs for old versions b) improve user 
> experience on the site by having it clearly laid out what is latest vs. old 
> docs and c) have some semblance of a search maybe using something like 
> Algolia or whatever.

This.

Keeping the docs in-tree is a huge win, because they can move in lock-step with 
changes occurring in that branch/version.  I don't think we've been enforcing 
this, but code-changes that alter documented behavior should be accompanied by 
corresponding changes to the documentation, or be rejected.  Code-changes that 
correspond with undocumented behavior are an opportunity to include some docs 
(not grounds to reject a code-review IMO, but certainly an opportunity to 
politely ask/suggest).

Publishing more than one version (as generated from the respective 
branches/tags), is a solvable problem.

> > On Thu, Mar 15, 2018 at 1:22 Kenneth Brotman 
> > <kenbrot...@yahoo.com.invalid
> > wrote:
> >
> > > https://issues.apache.org/jira/browse/CASSANDRA-14313
> > >
> > >
> > >
> > > For some reason I'm told by many committers that we should not 
> > > have sets of documentation for other versions than the current 
> > > version in a tree for that version. This has made it difficult, 
> > > maybe impossible to have documentation for all the supported 
> > > versions on the website at one time.
> > >
> > >
> > >
> > > As a solution I propose that we maintain the online documentation 
> > > in a separate repository that is managed as the current repository 
> > > under the guidance of the Apache Cassandra PMC (Project Management 
> > > Committee); and that in the new repository . . .
> > >
> > >
> > >
> > > Please see the jira. I hope it's a good answer to everyone.

--
Eric Evans
john.eric.ev...@gmail.com

-
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

A JIRA proposing a seperate repository for the online documentation

2018-03-14 Thread Kenneth Brotman

https://issues.apache.org/jira/browse/CASSANDRA-14313

 

For some reason I'm told by many committers that we should not have sets of
documentation for other versions than the current version in a tree for that
version.  This has made it difficult, maybe impossible to have documentation
for all the supported versions on the website at one time.  

 

As a solution I propose that we maintain the online documentation in a
separate repository that is managed as the current repository under the
guidance of the Apache Cassandra PMC (Project Management Committee); and
that in the new repository . . .

 

Please see the jira.  I hope it's a good answer to everyone.

 

KennethBrotman

RE: Pull request question

2018-03-14 Thread Kenneth Brotman

Thanks.  Something is not working right or I have brain fog.  I tried twice.  
Got unwanted results each time so I closed the pull requests with uncommitted 
merges.  I hope that is okay.  Here is the JIRA: 
https://issues.apache.org/jira/browse/CASSANDRA-14312

I must need to do something to sync my repository back up with the Apache 
Cassandra mirror site.  The pull requests were trying to bring over a bunch of 
other files.

Thanks for the reply.

Kenneth Brotman

-Original Message-
From: Dinesh Joshi [mailto:dinesh.jo...@yahoo.com.INVALID] 
Sent: Tuesday, March 13, 2018 11:13 PM
To: dev@cassandra.apache.org
Subject: Re: Pull request question

Hi Kenneth,
Normally you would open a Jira ticket and put the details in there including a 
link to your branch, pull request or patch. Is this pull request associated 
with a jira? If so, could you please point us to it? And yes, normally you 
would send pull requests against trunk unless they're for fixes to particular 
versions of Cassandra.
Dinesh 

On Tuesday, March 13, 2018, 10:48:22 PM PDT, Kenneth Brotman 
<kenbrot...@yahoo.com.INVALID> wrote:  
 
 I made some sub directories and files so we could start to work on having 
separate versions of documentation.  I did the pull request to the truck.
Was that right?

 

Kenneth Brotman

  


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Pull request question

2018-03-13 Thread Kenneth Brotman

I made some sub directories and files so we could start to work on having
separate versions of documentation.  I did the pull request to the truck.
Was that right?

 

Kenneth Brotman

RE: Mentor

2018-02-26 Thread Kenneth Brotman

That one is JIRA 14264:
https://issues.apache.org/jira/browse/CASSANDRA-14264

I won't be writing that one anytime soon but if it existed I would be
reading it.  If the guru's would throw some text in the JIRA as they have it
handy, myself or someone else will take it from there.

Kenneth Brotman


-Original Message-
From: Darshan Sreenivasamurthy [mailto:darshants.darsh...@gmail.com] 
Sent: Monday, February 26, 2018 11:33 AM
To: dev@cassandra.apache.org
Subject: Re: Mentor

+ 1



> On Feb 26, 2018, at 11:24 AM, Kenneth Brotman
<kenbrot...@yahoo.com.INVALID> wrote:
> 
> how about a nice Quick Tour Document for dev's that want to get oriented
on the code efficiently.



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Mentor

2018-02-26 Thread Kenneth Brotman

Yeah, how about a nice Quick Tour Document for dev's that want to get oriented 
on the code efficiently.  I would like that too.

Kenneth Brotman

-Original Message-
From: Sumant Sahney [mailto:sahneysum...@gmail.com] 
Sent: Monday, February 26, 2018 11:12 AM
To: dev@cassandra.apache.org
Subject: Mentor

Hi,
I am new to Open Source.
I am really confused on how to get started with open source. I would really 
appreciate if someone can help me through the process and help me get started.
Can someone please share the code documentation with me as well. Which I can 
refer to get an idea about all the modules.

Thanks,
Sumant 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Alignment and coodination between DataStax's online documentation and Apache Cassandra online documentation

2018-02-24 Thread Kenneth Brotman

To the amazing people of DataStax,

 

The DataStax website is a little unwieldy as it tries to support open source
Cassandra and DataStax's version.  Meanwhile some of that information would
help fill in the Apache Cassandra web site.  If you would like to work on
this, I'm up for it.  

 

Kenneth Brotman

Filling in the blank To Do sections on the Apache Cassandra web site

2018-02-23 Thread Kenneth Brotman

These nine web pages on the Apache Cassandra web site have blank To Do
sections.  Most of the web pages are completely blank.  Mind you there is a
lot of hard work already done on the documentation.  I'll make JIRA's for
any of the blank sections where there is not already a JIRA.  Then it will
be on to writing up those sections.  If you have any text to help me get
started for any of these sections that would be really cool. 

 

http://cassandra.apache.org/doc/latest/architecture/overview.html

 

http://cassandra.apache.org/doc/latest/architecture/dynamo.html

 

http://cassandra.apache.org/doc/latest/architecture/guarantees.html

 

http://cassandra.apache.org/doc/latest/data_modeling/index.html

 

http://cassandra.apache.org/doc/latest/operating/read_repair.html

 

http://cassandra.apache.org/doc/latest/operating/hints.html

 

http://cassandra.apache.org/doc/latest/operating/backups.html

 

http://cassandra.apache.org/doc/latest/operating/bulk_loading.html

 

http://cassandra.apache.org/doc/latest/troubleshooting/index.html

 

Kenneth Brotman

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-23 Thread Kenneth Brotman

A sincere thank you for everyone that replied.  I will heavy lift the docs for 
a while, do my Slender Cassandra reference project and then I’ll try to find 
one or two areas where I can contribute code to get going on that.  

I'll have a few JIRA's started by the end of the workday.

Kenneth Brotman


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-21 Thread Kenneth Brotman

 

Jeff,

 

I already addressed everything you said.  Boy! Would I like to bring up the out 
of date articles on the web that trip people up and the lousy documentation on 
the Apache website but I can’t because a lot of folks don’t know me or why I’m 
saying these things.  

 

I will be making another post that I hope clarifies what’s going on with me.  
After that I will either be a freakishly valuable asset to this community or I 
will be a freakishly valuable asset to another community.  

 

You sure have a funny way of reigning in people that are used to helping out.  
You sure misjudged me.  Wow.

 

Kenneth Brotman

 

From: Jeff Jirsa [mailto:jji...@gmail.com] 
Sent: Wednesday, February 21, 2018 3:12 PM
To: cassandra
Cc: Cassandra DEV
Subject: Re: Cassandra Needs to Grow Up by Version Five!

 

 

On Wed, Feb 21, 2018 at 2:53 PM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
wrote:

Hi Akash,

I get the part about outside work which is why in replying to Jeff Jirsa I was 
suggesting the big companies could justify taking it on easy enough and you 
know actually pay the people who would be working at it so those people could 
have a life.

The part I don't get is the aversion to usability.  Isn't that what you think 
about when you are coding?  "Am I making this thing I'm building easy to use?"  
If you were programming for me, we would be constantly talking about what we 
are building and how we can make things easier for users.  If I had to fight 
with a developer, architect or engineer about usability all the time, they 
would be gone and quick.  How do approach programming if you aren't trying to 
make things easy.

 

 

There's no aversion to usability, you're assuming things that just aren't true 
Nobody's against usability, we've just prioritized other things HIGHER. We make 
those decisions in part by looking at open JIRAs and determining what's asked 
for the most, what members of the community have contributed, and then balance 
that against what we ourselves care about. You're making a statement that it 
should be the top priority for the next release, with no JIRA, and history of 
contributing (and indeed, no real clear sign that you even understand the full 
extent of the database), no sign that you're willing to do the work yourself, 
and making a ton of assumptions about the level of effort and ROI.

 

I would love for Cassandra to be easier to use, I'm sure everyone does. There's 
a dozen features I'd love to add if I had infinite budget and infinite 
manpower. But what you're asking for is A LOT of effort and / or A LOT of 
money, and you're assuming someone's going to step up and foot the bill, but 
there's no real reason to believe that's the case. 

 

In the mean time, everyone's spending hours replying to this thread that is 0% 
actionable. We would all have been objectively better off had everyone ignored 
this thread and just spent 10 minutes writing some section of the docs. So the 
next time I get the urge to reply, I'm just going to do that instead.

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-21 Thread Kenneth Brotman

Jon,

Very sorry that you don't see the value of the time I'm taking for this.  I 
don't have demands; I do have a stern warning and I'm right Jon.  Please be 
very careful not to mischaracterized my words Jon.

You suggest I put things in JIRA's, then seem to suggest that I'd be lucky if 
anyone looked at it and did anything. That's what I figured too.  

I don't appreciate the hostility.  You will understand more fully in the next 
post where I'm coming from.  Try to keep the conversation civilized.  I'm 
trying or at least so you understand I think what I'm doing is saving your gig 
and mine.  I really like a lot of people is this group.

I've come to a preliminary assessment on things.  Soon the cloud will clear or 
I'll be gone.  Don't worry.  I'm a very peaceful person and like you I am 
driven by real important projects that I feel compelled to work on for the good 
of others.  I don't have time for people to hand hold a database and I can't 
get stuck with my projects on the wrong stuff.  

Kenneth Brotman

-Original Message-
From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad
Sent: Wednesday, February 21, 2018 12:44 PM
To: u...@cassandra.apache.org
Cc: dev@cassandra.apache.org
Subject: Re: Cassandra Needs to Grow Up by Version Five!

Ken,

Maybe it’s not clear how open source projects work, so let me try to explain.  
There’s a bunch of us who either get paid by someone or volunteer on our free 
time.  The folks that get paid, (yay!) usually take direction on what the 
priorities are, and work on projects that directly affect our jobs.  That means 
that someone needs to care enough about the features you want to work on them, 
if you’re not going to do it yourself. 

Now as others have said already, please put your list of demands in JIRA, if 
someone is interested, they will work on it.  You may need to contribute a 
little more than you’ve done already, be prepared to get involved if you 
actually want to to see something get done.  Perhaps learning a little more 
about Cassandra’s internals and the people involved will reveal some of the 
design decisions and priorities of the project.  

Third, you seem to be a little obsessed with market share.  While market share 
is fun to talk about, *most* of us that are working on and contributing to 
Cassandra do so because it does actually solve a problem we have, and solves it 
reasonably well.  If some magic open source DB appears out of no where and does 
everything you want Cassandra to, and is bug free, keeps your data consistent, 
automatically does backups, comes with really nice cert management, ad hoc 
querying, amazing materialized views that are perfect, no caveats to secondary 
indexes, and somehow still gives you linear scalability without any mental 
overhead whatsoever then sure, people might start using it.  And that’s 
actually OK, because if that happens we’ll all be incredibly pumped out of our 
minds because we won’t have to work as hard.  If on the slim chance that 
doesn’t manifest, those of us that use Cassandra and are part of the community 
will keep working on the things we care about, iterating, and improving things. 
 Maybe someone will even take a look at your JIRA issues.  

Further filling the mailing list with your grievances will likely not help you 
progress towards your goal of a Cassandra that’s easier to use, so I encourage 
you to try to be a little more productive and try to help rather than just 
complain, which is not constructive.  I did a quick search for your name on the 
mailing list, and I’ve seen very little from you, so to everyone’s who’s been 
around for a while and trying to help you it looks like you’re just some random 
dude asking for people to work for free on the things you’re asking for, 
without offering anything back in return.

Jon

> On Feb 21, 2018, at 11:56 AM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> 
> wrote:
> 
> Josh,
> 
> To say nothing is indifference.  If you care about your community, sometimes 
> don't you have to bring up a subject even though you know it's also 
> temporarily adding some discomfort?  
> 
> As to opening a JIRA, I've got a very specific topic to try in mind now.  An 
> easy one I'll work on and then announce.  Someone else will have to do the 
> coding.  A year from now I would probably just knock it out to make sure it's 
> as easy as I expect it to be but to be honest, as I've been saying, I'm not 
> set up to do that right now.  I've barely looked at any Cassandra code; for 
> one; everyone on this list probably codes more than I do, secondly; and 
> lastly, it's a good one for someone that wants an easy one to start with: 
> vNodes.  I've already seen too many people seeking assistance with the vNode 
> setting.
> 
> And you can expect as others have been mentioning that there should be 
> similar ones on compaction, repair and backup. 
>

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-21 Thread Kenneth Brotman

 Josh, 

To say nothing is indifference.  If you care about your community, sometimes 
don't you have to bring up a subject even though you know it's also temporarily 
adding some discomfort?  

As to opening a JIRA, I've got a very specific topic to try in mind now.  An 
easy one I'll work on and then announce.  Someone else will have to do the 
coding.  A year from now I would probably just knock it out to make sure it's 
as easy as I expect it to be but to be honest, as I've been saying, I'm not set 
up to do that right now.  I've barely looked at any Cassandra code; for one; 
everyone on this list probably codes more than I do, secondly; and lastly, it's 
a good one for someone that wants an easy one to start with: vNodes.  I've 
already seen too many people seeking assistance with the vNode setting.

And you can expect as others have been mentioning that there should be similar 
ones on compaction, repair and backup. 

Microsoft knows poor usability gives them an easy market to take over. And they 
make it easy to switch.

Beginning at 4:17 in the video, it says the following:

"You don't need to worry about replica sets, quorum or read repair.  
You can focus on writing correct application logic."

At 4:42, it says:
"Hopefully this gives you a quick idea of how seamlessly you can bring 
your existing Cassandra applications to Azure Cosmos DB.  No code changes are 
required.  It works with your favorite Cassandra tools and drivers including 
for example native Cassandra driver for Spark. And it takes seconds to get 
going, and it's elastically and globally scalable."

More to come,

Kenneth Brotman

-Original Message-
From: Josh McKenzie [mailto:jmcken...@apache.org] 
Sent: Wednesday, February 21, 2018 8:28 AM
To: dev@cassandra.apache.org
Cc: User
Subject: Re: Cassandra Needs to Grow Up by Version Five!

There's a disheartening amount of "here's where Cassandra is bad, and here's 
what it needs to do for me for free" happening in this thread.

This is open-source software. Everyone is *strongly encouraged* to submit a 
patch to move the needle on *any* of these things being complained about in 
this thread.

For the Apache Way <https://www.apache.org/foundation/governance/> to work, 
people need to step up and meaningfully contribute to a project to scratch 
their own itch instead of just waiting for a random corporation-subsidized 
engineer to happen to have interests that align with them and contribute that 
to the project.

Beating a dead horse for things everyone on the project knows are serious pain 
points is not productive.

On Wed, Feb 21, 2018 at 5:45 AM, Oleksandr Shulgin < 
oleksandr.shul...@zalando.de> wrote:

> On Mon, Feb 19, 2018 at 10:01 AM, Kenneth Brotman < 
> kenbrot...@yahoo.com.invalid> wrote:
>
> >
> > >> Cluster wide management should be a big theme in any next major
> release.
> > >>
> > >Na. Stability and testing should be a big theme in the next major
> release.
> > >
> >
> > Double Na on that one Jeff.  I think you have a concern there about 
> > the need to test sufficiently to ensure the stability of the next 
> > major release.  That makes perfect sense.- for every release, 
> > especially the major ones.  Continuous improvement is not a phase of 
> > development for example.  CI should be in everything, in every 
> > phase.  Stability and testing a part of every release not just one.  
> > A major release should be
> a
> > nice step from the previous major release though.
> >
>
> I guess what Jeff refers to is the tick-tock release cycle experiment, 
> which has proven to be a complete disaster by popular opinion.
>
> There's also the "materialized views" feature which failed to 
> materialize in the end (pun intended) and had to be declared 
> experimental retroactively.
>
> Another prominent example is incremental repair which was introduced 
> as the default option in 2.2 and now is not recommended to use because 
> of so many corner cases where it can fail.  So again experimental as an 
> afterthought.
>
> Not to mention that even if you are aware of the default incremental 
> and go with full repair instead, you're still up for a sad surprise:
> anti-compaction will be triggered despite the "full" repair.  Because 
> anti-compaction is only disabled in case of sub-range repair (don't 
> ask why), so you need to use something advanced like Reaper if you 
> want to avoid that.  I don't think you'll ever find this in the documentation.
>
> Honestly, for an eventually-consistent system like Cassandra 
> anti-entropy repair is one of the most important pieces to get right.  
> And Cassandra fails really badly on that one: the feature is not 
> really well d

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-20 Thread Kenneth Brotman

If you watch this video through you'll see why usability is so important.  You 
can't ignore usability issues.  

Cassandra does not exist in a vacuum.  The competitors are world class.  

The video is on the New Cassandra API for Azure Cosmos DB:
https://www.youtube.com/watch?v=1Sf4McGN1AQ

Kenneth Brotman

-Original Message-
From: Daniel Hölbling-Inzko [mailto:daniel.hoelbling-in...@bitmovin.com] 
Sent: Tuesday, February 20, 2018 1:28 AM
To: u...@cassandra.apache.org; James Briggs
Cc: dev@cassandra.apache.org
Subject: Re: Cassandra Needs to Grow Up by Version Five!

Hi,

I have to add my own two cents here as the main thing that keeps me from really 
running Cassandra is the amount of pain running it incurs.
Not so much because it's actually painful but because the tools are so 
different and the documentation and best practices are scattered across a dozen 
outdated DataStax articles and this mailing list etc.. We've been hesitant 
(although our use case is perfect for using Cassandra) to deploy Cassandra to 
any critical systems as even after a year of running it we still don't have the 
operational experience to confidently run critical systems with it.

Simple things like a foolproof / safe cluster-wide S3 Backup (like 
Elasticsearch has it) would for example solve a TON of issues for new people. I 
don't need it auto-scheduled or something, but having to configure cron jobs 
across the whole cluster is a pain in the ass for small teams.
To be honest, even the way snapshots are done right now is already super 
painful. Every other system I operated so far will just create one backup 
folder I can export, in C* the Backup is scattered across a bunch of different 
Keyspace folders etc.. needless to say that it took a while until I trusted my 
backup scripts fully.

And especially for a Database I believe Backup/Restore needs to be a non-issue 
that's documented front and center. If not smaller teams just don't have the 
resources to dedicate to learning and building the tools around it.

Now that the team is getting larger we could spare the resources to operate 
these things, but switching from a well-understood RDBMs schema to Cassandra is 
now incredibly hard and will probably take years.

greetings Daniel

On Tue, 20 Feb 2018 at 05:56 James Briggs <james.bri...@yahoo.com.invalid>
wrote:

> Kenneth:
>
> What you said is not wrong.
>
> Vertica and Riak are examples of distributed databases that don't 
> require hand-holding.
>
> Cassandra is for Java-programmer DIYers, or more often Datastax 
> clients, at this point.
> Thanks, James.
>
> ------
> *From:* Kenneth Brotman <kenbrot...@yahoo.com.INVALID>
> *To:* u...@cassandra.apache.org
> *Cc:* dev@cassandra.apache.org
> *Sent:* Monday, February 19, 2018 4:56 PM
>
> *Subject:* RE: Cassandra Needs to Grow Up by Version Five!
>
> Jeff, you helped me figure out what I was missing.  It just took me a 
> day to digest what you wrote.  I’m coming over from another type of 
> engineering.  I didn’t know and it’s not really documented.  Cassandra 
> runs in a data center.  Now days that means the nodes are going to be 
> in managed containers, Docker containers, managed by Kerbernetes,  
> Meso or something, and for that reason anyone operating Cassandra in a 
> real world setting would not encounter the issues I raised in the way I 
> described.
>
> Shouldn’t the architectural diagrams people reference indicate that in 
> some way?  That would have help me.
>
> Kenneth Brotman
>
> *From:* Kenneth Brotman [mailto:kenbrot...@yahoo.com]
> *Sent:* Monday, February 19, 2018 10:43 AM
> *To:* 'u...@cassandra.apache.org'
> *Cc:* 'dev@cassandra.apache.org'
> *Subject:* RE: Cassandra Needs to Grow Up by Version Five!
>
> Well said.  Very fair.  I wouldn’t mind hearing from others still  
> You’re a good guy!
>
> Kenneth Brotman
>
> *From:* Jeff Jirsa [mailto:jji...@gmail.com <jji...@gmail.com>]
> *Sent:* Monday, February 19, 2018 9:10 AM
> *To:* cassandra
> *Cc:* Cassandra DEV
> *Subject:* Re: Cassandra Needs to Grow Up by Version Five!
>
> There's a lot of things below I disagree with, but it's ok. I 
> convinced myself not to nit-pick every point.
>
> https://issues.apache.org/jira/browse/CASSANDRA-13971 has some of 
> Stefan's work with cert management
>
> Beyond that, I encourage you to do what Michael suggested: open JIRAs 
> for things you care strongly about, work on them if you have time. 
> Sometime this year we'll schedule a NGCC (Next Generation Cassandra 
> Conference) where we talk about future project work and direction, I 
> encourage you to attend if you're able (I encourage anyone who cares 
> about the direction of Cassandra to attend, it's probably be either 
> free or very low cost, just to cover a venue and som

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-19 Thread Kenneth Brotman

Jeff, you helped me figure out what I was missing.  It just took me a day to 
digest what you wrote.  I’m coming over from another type of engineering.  I 
didn’t know and it’s not really documented.  Cassandra runs in a data center.  
Now days that means the nodes are going to be in managed containers, Docker 
containers, managed by Kerbernetes,  Meso or something, and for that reason 
anyone operating Cassandra in a real world setting would not encounter the 
issues I raised in the way I described.

Shouldn’t the architectural diagrams people reference indicate that in some 
way?  That would have help me.

Kenneth Brotman

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com] 
Sent: Monday, February 19, 2018 10:43 AM
To: 'u...@cassandra.apache.org'
Cc: 'dev@cassandra.apache.org'
Subject: RE: Cassandra Needs to Grow Up by Version Five!

Well said.  Very fair.  I wouldn’t mind hearing from others still.  You’re a 
good guy!

Kenneth Brotman

From: Jeff Jirsa [mailto:jji...@gmail.com] 
Sent: Monday, February 19, 2018 9:10 AM
To: cassandra
Cc: Cassandra DEV
Subject: Re: Cassandra Needs to Grow Up by Version Five!

There's a lot of things below I disagree with, but it's ok. I convinced myself 
not to nit-pick every point.

https://issues.apache.org/jira/browse/CASSANDRA-13971 has some of Stefan's work 
with cert management

Beyond that, I encourage you to do what Michael suggested: open JIRAs for 
things you care strongly about, work on them if you have time. Sometime this 
year we'll schedule a NGCC (Next Generation Cassandra Conference) where we talk 
about future project work and direction, I encourage you to attend if you're 
able (I encourage anyone who cares about the direction of Cassandra to attend, 
it's probably be either free or very low cost, just to cover a venue and some 
food). If nothing else, you'll meet some of the teams who are working on the 
project, and learn why they've selected the projects on which they're working. 
You'll have an opportunity to pitch your vision, and maybe you can talk some 
folks into helping out. 

- Jeff

On Mon, Feb 19, 2018 at 1:01 AM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
wrote:

Comments inline

>-Original Message-
>From: Jeff Jirsa [mailto:jji...@gmail.com]
>Sent: Sunday, February 18, 2018 10:58 PM
>To: u...@cassandra.apache.org
>Cc: dev@cassandra.apache.org
>Subject: Re: Cassandra Needs to Grow Up by Version Five!
>
>Comments inline
>
>
>> On Feb 18, 2018, at 9:39 PM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> 
>> wrote:
>>
> >Cassandra feels like an unfinished program to me. The problem is not that 
> >it’s open source or cutting edge.  It’s an open source cutting edge program 
> >that lacks some of its basic functionality.  We are all stuck addressing 
> >fundamental mechanical tasks for Cassandra because the basic code that would 
> >do that part has not been contributed yet.
>>
>There’s probably 2-3 reasons why here:
>
>1) Historically the pmc has tried to keep the scope of the project very 
>narrow. It’s a database. We don’t ship drivers. We don’t ship developer tools. 
>We don’t ship fancy UIs. We ship a database. I think for the most part the 
>narrow vision has been for the best, but maybe it’s time to reconsider some of 
>the scope.
>
>Postgres will autovacuum to prevent wraparound (hopefully),  but everyone I 
>know running Postgres uses flexible-freeze in cron - sometimes it’s ok to let 
>the database have its opinions and let third party tools fill in the gaps.
>

I can appreciate the desire to stay in scope.  I believe usability is the King. 
 When users have to learn the database, then learn what they have to automate, 
then learn an automation tool and then use the automation tool to do something 
that is as fundamental as the fundamental tasks I described, then something is 
missing from the database itself that is adversely affecting usability - and 
that is very bad.  Where those big companies need to calculate the ROI is in 
the cost of acquiring or training the next group of users.  Consider how steep 
the learning curve is for new users.  Consider the business case for improving 
ease of use.

>2) Cassandra is, by definition, a database for large scale problems. Most of 
>the companies working on/with it tend to be big companies. Big companies often 
>have pre-existing automation that solved the stuff you consider fundamental 
>tasks, so there’s probably nobody actively working on the solved problems that 
>you may consider missing features - for many people they’re already solved.
>

I could be wrong but it sounds like a lot of the code work is done, and if the 
companies would take the time to contribute more code, then the rest of the 
code needed could be generated easily.

>3) It’s not nearly as basic as you think it

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-19 Thread Kenneth Brotman

Well said.  Very fair.  I wouldn’t mind hearing from others still.  You’re a 
good guy!

Kenneth Brotman

From: Jeff Jirsa [mailto:jji...@gmail.com] 
Sent: Monday, February 19, 2018 9:10 AM
To: cassandra
Cc: Cassandra DEV
Subject: Re: Cassandra Needs to Grow Up by Version Five!

There's a lot of things below I disagree with, but it's ok. I convinced myself 
not to nit-pick every point.

https://issues.apache.org/jira/browse/CASSANDRA-13971 has some of Stefan's work 
with cert management

Beyond that, I encourage you to do what Michael suggested: open JIRAs for 
things you care strongly about, work on them if you have time. Sometime this 
year we'll schedule a NGCC (Next Generation Cassandra Conference) where we talk 
about future project work and direction, I encourage you to attend if you're 
able (I encourage anyone who cares about the direction of Cassandra to attend, 
it's probably be either free or very low cost, just to cover a venue and some 
food). If nothing else, you'll meet some of the teams who are working on the 
project, and learn why they've selected the projects on which they're working. 
You'll have an opportunity to pitch your vision, and maybe you can talk some 
folks into helping out. 

- Jeff

On Mon, Feb 19, 2018 at 1:01 AM, Kenneth Brotman <kenbrot...@yahoo.com.invalid> 
wrote:

Comments inline

>-Original Message-
>From: Jeff Jirsa [mailto:jji...@gmail.com]
>Sent: Sunday, February 18, 2018 10:58 PM
>To: u...@cassandra.apache.org
>Cc: dev@cassandra.apache.org
>Subject: Re: Cassandra Needs to Grow Up by Version Five!
>
>Comments inline
>
>
>> On Feb 18, 2018, at 9:39 PM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> 
>> wrote:
>>
> >Cassandra feels like an unfinished program to me. The problem is not that 
> >it’s open source or cutting edge.  It’s an open source cutting edge program 
> >that lacks some of its basic functionality.  We are all stuck addressing 
> >fundamental mechanical tasks for Cassandra because the basic code that would 
> >do that part has not been contributed yet.
>>
>There’s probably 2-3 reasons why here:
>
>1) Historically the pmc has tried to keep the scope of the project very 
>narrow. It’s a database. We don’t ship drivers. We don’t ship developer tools. 
>We don’t ship fancy UIs. We ship a database. I think for the most part the 
>narrow vision has been for the best, but maybe it’s time to reconsider some of 
>the scope.
>
>Postgres will autovacuum to prevent wraparound (hopefully),  but everyone I 
>know running Postgres uses flexible-freeze in cron - sometimes it’s ok to let 
>the database have its opinions and let third party tools fill in the gaps.
>

I can appreciate the desire to stay in scope.  I believe usability is the King. 
 When users have to learn the database, then learn what they have to automate, 
then learn an automation tool and then use the automation tool to do something 
that is as fundamental as the fundamental tasks I described, then something is 
missing from the database itself that is adversely affecting usability - and 
that is very bad.  Where those big companies need to calculate the ROI is in 
the cost of acquiring or training the next group of users.  Consider how steep 
the learning curve is for new users.  Consider the business case for improving 
ease of use.

>2) Cassandra is, by definition, a database for large scale problems. Most of 
>the companies working on/with it tend to be big companies. Big companies often 
>have pre-existing automation that solved the stuff you consider fundamental 
>tasks, so there’s probably nobody actively working on the solved problems that 
>you may consider missing features - for many people they’re already solved.
>

I could be wrong but it sounds like a lot of the code work is done, and if the 
companies would take the time to contribute more code, then the rest of the 
code needed could be generated easily.

>3) It’s not nearly as basic as you think it is. Datastax seemingly had a 
>multi-person team on opscenter, and while it was better than anything else 
>around last time I used it (before it stopped supporting the OSS version), it 
>left a lot to be desired. It’s probably 2-3 engineers working for a month  to 
>have any sort of meaningful, reliable, mostly trivial cluster-managing UI, and 
>I can think of about 10 JIRAs I’d rather see that time be spent on first.

How about 6-9 engineers working 12 months a year on it then.  I'm not kidding.  
For a big company with revenues in the tens of billions or more, and a heavy 
use of Cassandra nodes, it's easy to make a case for having a full time person 
or more that involved.  They aren't paying for using the open source code that 
is Cassandra.  Let's see what would the licensing fees be for a big company if 
the costs where like Micr

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-19 Thread Kenneth Brotman

Comments inline

>-Original Message-
>From: Jeff Jirsa [mailto:jji...@gmail.com] 
>Sent: Sunday, February 18, 2018 10:58 PM
>To: u...@cassandra.apache.org
>Cc: dev@cassandra.apache.org
>Subject: Re: Cassandra Needs to Grow Up by Version Five!
>
>Comments inline 
>
>
>> On Feb 18, 2018, at 9:39 PM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> 
>> wrote:
>>
> >Cassandra feels like an unfinished program to me. The problem is not that 
> >it’s open source or cutting edge.  It’s an open source cutting edge program 
> >that lacks some of its basic functionality.  We are all stuck addressing 
> >fundamental mechanical tasks for Cassandra because the basic code that would 
> >do that part has not been contributed yet.
>> 
>There’s probably 2-3 reasons why here:
>
>1) Historically the pmc has tried to keep the scope of the project very 
>narrow. It’s a database. We don’t ship drivers. We don’t ship developer tools. 
>We don’t ship fancy UIs. We ship a database. I think for the most part the 
>narrow vision has been for the best, but maybe it’s time to reconsider some of 
>the scope. 
>
>Postgres will autovacuum to prevent wraparound (hopefully),  but everyone I 
>know running Postgres uses flexible-freeze in cron - sometimes it’s ok to let 
>the database have its opinions and let third party tools fill in the gaps.
>

I can appreciate the desire to stay in scope.  I believe usability is the King. 
 When users have to learn the database, then learn what they have to automate, 
then learn an automation tool and then use the automation tool to do something 
that is as fundamental as the fundamental tasks I described, then something is 
missing from the database itself that is adversely affecting usability - and 
that is very bad.  Where those big companies need to calculate the ROI is in 
the cost of acquiring or training the next group of users.  Consider how steep 
the learning curve is for new users.  Consider the business case for improving 
ease of use. 

>2) Cassandra is, by definition, a database for large scale problems. Most of 
>the companies working on/with it tend to be big companies. Big companies often 
>have pre-existing automation that solved the stuff you consider fundamental 
>tasks, so there’s probably nobody actively working on the solved problems that 
>you may consider missing features - for many people they’re already solved.
>

I could be wrong but it sounds like a lot of the code work is done, and if the 
companies would take the time to contribute more code, then the rest of the 
code needed could be generated easily.

>3) It’s not nearly as basic as you think it is. Datastax seemingly had a 
>multi-person team on opscenter, and while it was better than anything else 
>around last time I used it (before it stopped supporting the OSS version), it 
>left a lot to be desired. It’s probably 2-3 engineers working for a month  to 
>have any sort of meaningful, reliable, mostly trivial cluster-managing UI, and 
>I can think of about 10 JIRAs I’d rather see that time be spent on first. 

How about 6-9 engineers working 12 months a year on it then.  I'm not kidding.  
For a big company with revenues in the tens of billions or more, and a heavy 
use of Cassandra nodes, it's easy to make a case for having a full time person 
or more that involved.  They aren't paying for using the open source code that 
is Cassandra.  Let's see what would the licensing fees be for a big company if 
the costs where like Microsoft or Oracle would charge for their enterprise 
level relational database?   What's the contribution of one or two people in 
comparison.

>> Ease of use issues need to be given much more attention.  For an 
>> administrator, the ease of use of Cassandra is very poor. 
>>
>>Furthermore, currently Cassandra is an idiot.  We have to do everything for 
>>Cassandra. Contrast that with the fact that we are in the dawn of artificial 
>>intelligence.
>> 
>
>And for everything you think is obvious, there’s a 50% chance someone else 
>will have already solved differently, and your obvious new solution will be 
>seen as an inconvenient assumption and complexity they won’t appreciate. Open 
>source projects get to walk a fine line of trying to be useful without making 
>too many assumptions, being “too” opinionated, or overstepping bounds. We may 
>be too conservative, but it’s very easy to go too far in the opposite 
>direction. 
>

I appreciate that but when such concerns result in inaction instead of 
resolution that is no good.

>> Software exists to automate tasks for humans, not mechanize humans to 
>> administer tasks for a database.  I’m an engineering type.  My job is to 
>> apply science and technology to solve real world problems.  And that’s

RE: Cassandra Needs to Grow Up by Version Five!

2018-02-18 Thread Kenneth Brotman

Hi Michael, actually I do very much like the database.  thanks for the 
thoughts... a few comments:

1) Lots of big companies like, let's see, Apple is a big one, probably could 
easily justify contributing resources to finish up the basic development of 
Cassandra. 
2) There are lots of big companies using Cassandra.  Each could contribute a 
tiny effort and everyone would benefit greatly.
3) A focused effort by a small group of talented people like there are in this 
group could knock it out easily.
4) Not everyone is a Cassandra coder.  It's not for me to do Michael.
5) I'm an individual.  I am not working at a big company at the moment Michael. 
 

Best,
Kenneth Brotman


-Original Message-
From: Michael Kjellman [mailto:kjell...@apple.com] 
Sent: Sunday, February 18, 2018 10:18 PM
To: dev@cassandra.apache.org
Subject: Re: Cassandra Needs to Grow Up by Version Five!

hi ken, sorry you don’t like the database. some thoughts:

1) please file actionable jiras for places you feel need to be improved in the 
database... this is the best way to make and encourage the change you’re 
looking for. it seems you have quite a few ideas from your post that could be 
broken down into individual actionable jiras.
2) please don’t cross post between mailing lists.
3) pull requests are always welcomed!

best,
kjellman

> On Feb 18, 2018, at 9:39 PM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> 
> wrote:
> 
> Cassandra feels like an unfinished program to me.  The problem is not 
> that it's open source or cutting edge.  It's an open source cutting 
> edge program that lacks some of its basic functionality.  We are all 
> stuck addressing fundamental mechanical tasks for Cassandra because 
> the basic code that would do that part has not been contributed yet.
> 
> Ease of use issues need to be given much more attention.  For an 
> administrator, the ease of use of Cassandra is very poor.
> 
> Furthermore, currently Cassandra is an idiot.  We have to do 
> everything for Cassandra. Contrast that with the fact that we are in 
> the dawn of artificial intelligence.
> 
> Software exists to automate tasks for humans, not mechanize humans to 
> administer tasks for a database.  I'm an engineering type.  My job is 
> to apply science and technology to solve real world problems.  And 
> that's where I need an organization's I.T. talent to focus; not in 
> crank starting an unfinished database.
> 
> For example, I should be able to go to any node, replace the 
> Cassandra.yaml file and have a prompt on the display ask me if I want 
> to update all the yaml files across the cluster.  I shouldn't have to 
> manually modify yaml files on each node or have to create a script for 
> some third party automation tool to do it.
> 
> I should not have to turn off service, clear directories, restart 
> service in coordination with the other nodes.  It's already a computer 
> system.  It can do those things on its own.
> 
> How about read repair.  First there is something wrong with the name.  
> Maybe it should be called Consistency Repair.  An administrator 
> shouldn't have to do anything.  It should be a behavior of Cassandra 
> that is programmed in. It should consider the GC setting of each node, 
> calculate how often it has to run repair, when it should run it so all 
> the nodes aren't trying at the same time and when other circumstances 
> indicate it should also run it.
> 
> Certificate management should be automated.
> 
> Cluster wide management should be a big theme in any next major release.
> What is a major release?  How many major releases could a program have 
> before all the coding for basic stuff like installation, configuration 
> and maintenance is included!
> 
> Finish the basic coding of Cassandra, make it easy to use for 
> administrators, make is smart, add cluster wide management.  Keep 
> Cassandra competitive or it will soon be the old Model T we all remember 
> fondly.
> 
> I ask the Committee to compile a list of all such items, make a plan, 
> and commit to including the completed and tested code as part of major 
> release 5.0.  I further ask that release 4.0 not be delayed and then 
> there be an unusually short skip to version 5.0.
> 
> Kenneth Brotman
> 

-
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

Cassandra Needs to Grow Up by Version Five!

2018-02-18 Thread Kenneth Brotman

Cassandra feels like an unfinished program to me.  The problem is not that
it's open source or cutting edge.  It's an open source cutting edge program
that lacks some of its basic functionality.  We are all stuck addressing
fundamental mechanical tasks for Cassandra because the basic code that would
do that part has not been contributed yet.

Ease of use issues need to be given much more attention.  For an
administrator, the ease of use of Cassandra is very poor.  

Furthermore, currently Cassandra is an idiot.  We have to do everything for
Cassandra. Contrast that with the fact that we are in the dawn of artificial
intelligence.

Software exists to automate tasks for humans, not mechanize humans to
administer tasks for a database.  I'm an engineering type.  My job is to
apply science and technology to solve real world problems.  And that's where
I need an organization's I.T. talent to focus; not in crank starting an
unfinished database.

For example, I should be able to go to any node, replace the Cassandra.yaml
file and have a prompt on the display ask me if I want to update all the
yaml files across the cluster.  I shouldn't have to manually modify yaml
files on each node or have to create a script for some third party
automation tool to do it.  

I should not have to turn off service, clear directories, restart service in
coordination with the other nodes.  It's already a computer system.  It can
do those things on its own.

How about read repair.  First there is something wrong with the name.  Maybe
it should be called Consistency Repair.  An administrator shouldn't have to
do anything.  It should be a behavior of Cassandra that is programmed in. It
should consider the GC setting of each node, calculate how often it has to
run repair, when it should run it so all the nodes aren't trying at the same
time and when other circumstances indicate it should also run it.

Certificate management should be automated.

Cluster wide management should be a big theme in any next major release.
What is a major release?  How many major releases could a program have
before all the coding for basic stuff like installation, configuration and
maintenance is included!

Finish the basic coding of Cassandra, make it easy to use for
administrators, make is smart, add cluster wide management.  Keep Cassandra
competitive or it will soon be the old Model T we all remember fondly.

I ask the Committee to compile a list of all such items, make a plan, and
commit to including the completed and tested code as part of major release
5.0.  I further ask that release 4.0 not be delayed and then there be an
unusually short skip to version 5.0. 

Kenneth Brotman

RE: Release votes

2018-02-15 Thread Kenneth Brotman

I'd like to help as well.  For me the issue is I have only my time to 
contribute.  The resources to test Cassandra extensively are beyond that of 
most individuals including me, aren't they?  If resources are made available 
and I can help, count me in.

Also, perhaps having a standard reference like Slender Cassandra (18 nodes 
total, two regions, three AZ's total, six nodes per AZ) would help.  I'll have 
it done very soon.

Kenneth Brotman

-Original Message-
From: kurt greaves [mailto:k...@instaclustr.com] 
Sent: Thursday, February 15, 2018 3:48 PM
To: dev@cassandra.apache.org
Subject: Re: Release votes

It seems there has been a bit of a slip in testing as of recently, mostly due 
to the fact that there's no canonical testing environment that isn't flaky. We 
probably need to come up with some ideas and a plan on how we're going to do 
testing in the future, and how we're going to make testing accessible for all 
contributors. I think this is the only way we're really going to change 
behaviour. Having an incredibly tedious process and then being aggressive about 
it only leads to resentment and workarounds.

I'm completely unsure of where dtests are at since the conversion to pytest, 
and there's a lot of failing dtests on the ASF jenkins jobs (which appear to be 
running pytest). As there's currently not a lot of visibility into what people 
are doing with CircleCI for this it's hard to say if things are better over 
there. I'd like to help here if anyone wants to fill me in.

On 15 February 2018 at 21:14, Josh McKenzie <jmcken...@apache.org> wrote:

> >
> > We’ve said in the past that we don’t release without green tests. 
> > The PMC gets to vote and enforce it. If you don’t vote yes without 
> > seeing the
> test
> > results, that enforces it.
>
> I think this is noble and ideal in theory. In practice, the tests take 
> long enough, hardware infra has proven flaky enough, and the tests 
> *themselves* flaky enough, that there's been a consistent low-level of 
> test failure noise that makes separating signal from noise in this 
> context very time consuming. Reference 3.11-test-all for example re:noise:
> https://builds.apache.org/view/A-D/view/Cassandra/job/
> Cassandra-3.11-test-all/test/?width=1024=768
>
> Having spearheaded burning test failures to 0 multiple times and have 
> them regress over time, my gut intuition is we should have one person 
> as our Source of Truth with a less-flaky source for release-vetting CI 
> (dedicated hardware, circle account, etc) we can use as a reference to 
> vote on release SHA's.
>
> We’ve declared this a requirement multiple times
>
> Declaring things != changed behavior, and thus != changed culture. The 
> culture on this project is one of having a constant low level of test 
> failure noise in our CI as a product of our working processes. Unless 
> we change those (actually block release w/out green board, actually 
> aggressively block merge w/any failing tests, aggressively 
> retroactively track down test failures on a daily basis and RCA), the 
> situation won't improve. Given that this is a volunteer organization / 
> project, that kind of daily time investment is a big ask.
>
> On Thu, Feb 15, 2018 at 1:10 PM, Jeff Jirsa <jji...@gmail.com> wrote:
>
> > Moving this to it’s own thread:
> >
> > We’ve declared this a requirement multiple times and then we 
> > occasionally get a critical issue and have to decide whether it’s 
> > worth the delay. I assume Jason’s earlier -1 on attempt 1 was an 
> > enforcement of that earlier stated goal.
> >
> > It’s up to the PMC. We’ve said in the past that we don’t release 
> > without green tests. The PMC gets to vote and enforce it. If you 
> > don’t vote yes without seeing the test results, that enforces it.
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Feb 15, 2018, at 9:49 AM, Josh McKenzie <jmcken...@apache.org>
> wrote:
> > >
> > > What would it take for us to get green utest/dtests as a blocking 
> > > part
> of
> > > the release process? i.e. "for any given SHA, here's a link to the
> tests
> > > that passed" in the release vote email?
> > >
> > > That being said, +1.
> > >
> > >> On Wed, Feb 14, 2018 at 4:33 PM, Nate McCall <zznat...@gmail.com>
> > wrote:
> > >>
> > >> +1
> > >>
> > >> On Thu, Feb 15, 2018 at 9:40 AM, Michael Shuler <
> mich...@pbandjelly.org
> > >
> > >> wrote:
> > >>> I propose the following artifacts for release as 3.0.16.
> > >>>
> > >>> sha1: 890f319142ddd3cf2692ff45ff28e71001365e96
> > >>> Git:
>

42 matches

Mail list logo