Re: Proposing an Apache Cassandra Management process

[Mick Semb Wever]

I've gone through it in more detail. LGTM.


On Wed, 14 Nov 2018, at 00:50, Sankalp Kohli wrote:
> Hi Mick,
>   Any feedback? 
> Also pinging this thread after a week for others to give feedback 
> 
> > On Nov 6, 2018, at 1:40 AM, Dinesh Joshi  
> > wrote:
> > 
> > Hi all,
> > 
> > Joey, Vinay & I have fleshed out the Management process proposal as the 
> > very first CIP document (with Jason’s inputs). It is available on the cwiki 
> > - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
> > 
> > Please comment on it and provide us any input that you may have. We want to 
> > ideally time-box the period to 2 weeks so we avoid waiting indefinitely.
> > 
> > Thanks,
> > 
> > Dinesh
> > 
> >> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID" 
> >>  wrote:
> >> 
> >> Thanks for starting this, Mick. I will flesh it out.
> >> Dinesh 
> >> 
> >>   On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever 
> >>  wrote:  
> >> 
> >> 
> >>> But I'll try to put together a strawman proposal for the doc(s) over the 
> >>> weekend. 
> >> 
> >> 
> >> I've thrown something quickly together here:
> >> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> >> - 
> >> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process
> >> 
> >> The former is a blatant rip-off from the Kafka and Spark design proposal 
> >> pages that Dinesh previously mentioned. I'd hoped to do more of an 
> >> analysis of the existing C* habits and precedence on design proposals 
> >> (implicit in jira tickets), but in lei of that this is a strawman to start 
> >> the discussion.
> >> 
> >> The latter still needs to be fleshed out. Dinesh, can you do this? I can 
> >> add a subpage/section that describes the alternative/consuming third-party 
> >> tools out there.
> >> 
> >> regards,
> >> Mick
> >> 
> >> -
> >> 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: Proposing an Apache Cassandra Management process

[Stefan Podkowinski]

My goal for a side car would be to enable more people to contribute to
the project, by making it more accessible for anyone who’s not familiar
with the Cassandra code base, or not familiar with Java development in
general. Although most of the functionality described in the proposal
sounds useful to have, I’d already be happy to have a solid REST API for
the existing nodetool and JMX functionality. If an official side car,
installed separately on each node, would provide that, I’m sure we’d see
lots of new tools created by the community (web UIs, cli tools, ..)
based on that. This would also be a good foundation for other existing
tool to converge upon, e.g. by calling the REST APIs for repair
scheduling and progress tracking instead of JMX, or by continually
integrating and sharing useful helper calls. This would also give
Cassandra devs more leeway to replace some of the existing tooling
related code in Cassandra, e.g. by migrating to virtual tables, while at
the same time keep providing a stable API through the side car.

What I’d also like to point out here is that implementing such a project
as an *official* side car, also implies to me having the same standards
when it comes to release quality. I’d also really prefer having feature
sets matching between Cassandra and the side car, e.g. authentication
and SSL should also be supported in the side car from the beginning,
ideally without any additional configuration.


On 06.11.18 10:40, Dinesh Joshi wrote:
> Hi all,
>
> Joey, Vinay & I have fleshed out the Management process proposal as the very 
> first CIP document (with Jason’s inputs). It is available on the cwiki - 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
>
> Please comment on it and provide us any input that you may have. We want to 
> ideally time-box the period to 2 weeks so we avoid waiting indefinitely.
>
> Thanks,
>
> Dinesh
>
>> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID" 
>>  wrote:
>>
>> Thanks for starting this, Mick. I will flesh it out.
>> Dinesh 
>>
>>On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever 
>>  wrote:  
>>
>>
>>> But I'll try to put together a strawman proposal for the doc(s) over the 
>>> weekend. 
>>
>> I've thrown something quickly together here:
>> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>> - 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process
>>
>> The former is a blatant rip-off from the Kafka and Spark design proposal 
>> pages that Dinesh previously mentioned. I'd hoped to do more of an analysis 
>> of the existing C* habits and precedence on design proposals (implicit in 
>> jira tickets), but in lei of that this is a strawman to start the discussion.
>>
>> The latter still needs to be fleshed out. Dinesh, can you do this? I can add 
>> a subpage/section that describes the alternative/consuming third-party tools 
>> out there.
>>
>> regards,
>> Mick
>>
>> -
>> 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: Proposing an Apache Cassandra Management process

[dinesh.jo...@yahoo.com.INVALID]

Thanks, Mick & Stefan for your inputs. What should we do as next steps to move 
this proposal forward?
Dinesh 

On Sunday, November 18, 2018, 11:57:54 AM PST, Stefan Podkowinski 
 wrote:  
 
 My goal for a side car would be to enable more people to contribute to
the project, by making it more accessible for anyone who’s not familiar
with the Cassandra code base, or not familiar with Java development in
general. Although most of the functionality described in the proposal
sounds useful to have, I’d already be happy to have a solid REST API for
the existing nodetool and JMX functionality. If an official side car,
installed separately on each node, would provide that, I’m sure we’d see
lots of new tools created by the community (web UIs, cli tools, ..)
based on that. This would also be a good foundation for other existing
tool to converge upon, e.g. by calling the REST APIs for repair
scheduling and progress tracking instead of JMX, or by continually
integrating and sharing useful helper calls. This would also give
Cassandra devs more leeway to replace some of the existing tooling
related code in Cassandra, e.g. by migrating to virtual tables, while at
the same time keep providing a stable API through the side car.

What I’d also like to point out here is that implementing such a project
as an *official* side car, also implies to me having the same standards
when it comes to release quality. I’d also really prefer having feature
sets matching between Cassandra and the side car, e.g. authentication
and SSL should also be supported in the side car from the beginning,
ideally without any additional configuration.


On 06.11.18 10:40, Dinesh Joshi wrote:
> Hi all,
>
> Joey, Vinay & I have fleshed out the Management process proposal as the very 
> first CIP document (with Jason’s inputs). It is available on the cwiki - 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224
>
> Please comment on it and provide us any input that you may have. We want to 
> ideally time-box the period to 2 weeks so we avoid waiting indefinitely.
>
> Thanks,
>
> Dinesh
>
>> On Oct 22, 2018, at 7:30 AM, "dinesh.jo...@yahoo.com.INVALID" 
>>  wrote:
>>
>> Thanks for starting this, Mick. I will flesh it out.
>> Dinesh 
>>
>>    On Sunday, October 21, 2018, 1:52:10 AM PDT, Mick Semb Wever 
>> wrote:  
>>
>>
>>> But I'll try to put together a strawman proposal for the doc(s) over the 
>>> weekend. 
>>
>> I've thrown something quickly together here:
>> - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
>> - 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CIP-1%3A+Proposing+an+Apache+Cassandra+Management+process
>>
>> The former is a blatant rip-off from the Kafka and Spark design proposal 
>> pages that Dinesh previously mentioned. I'd hoped to do more of an analysis 
>> of the existing C* habits and precedence on design proposals (implicit in 
>> jira tickets), but in lei of that this is a strawman to start the discussion.
>>
>> The latter still needs to be fleshed out. Dinesh, can you do this? I can add 
>> a subpage/section that describes the alternative/consuming third-party tools 
>> out there.
>>
>> regards,
>> Mick
>>
>> -
>> 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

  

JIRA Reports in Confluence

[Scott Andreas]

Hi everyone,

I’ve created several new JIRA reports in Confluence organized under this 
top-level page:
https://cwiki.apache.org/confluence/display/CASSANDRA/Jira+reports

These pages report open issues by Component and fix version. My aims in 
creating them are to:

– Represent what’s currently screened into each upcoming release milestone.
– Break releases down by component to assess health/outstanding work in each.
– Make it easier to identify what’s scoped where (and to gauge release size).
– Create pages that can be used as queues for screening and for patches 
awaiting review.

They may also help structure discussions on release scope and what’s in / 
what’s out. I’ve refrained from updating the “fix version” field on tickets 
this weekend, but hope that these pages can become useful toward doing so as a 
dev community. Additional JIRA grooming is needed before these can support 
scope / timeline discussions on a per-release basis (esp. getting all active 
and planned testing work represented) – but representing the current state of 
things seemed like a prerequisite.

The current reports are:

– 4.0: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0%3A+Open+Issues+by+Component

– 4.0.x: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.0.x%3A+Open+Issues+by+Component

– 4.x: Open Issues by Component
https://cwiki.apache.org/confluence/display/CASSANDRA/4.x%3A+Open+Issues+by+Component

– Open Issues by Component (Unscreened)
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97550493

– Patch Available
https://cwiki.apache.org/confluence/display/CASSANDRA/Patch+Available

If you’ve got cabin fever from poor air quality (or just really love screening 
bugs), I’d love help adding components to tickets on the "Open Issues by 
Component - Unscreened” page.

Cheers,

– Scott


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

Request to review feature-freeze proposed tickets

[Vinay Chella]

Hi,

We still have 15 Patch Available/ open tickets which were requested for
reviews before the Sep 1, 2018 freeze. I am starting this email thread to
resurface and request a review of community tickets as most of these
tickets address vital correctness, performance, and usability bugs that
help avoid critical production issues. I tried to provide context on why we
feel these tickets are important to get into 4.0. If you would like to
discuss the technical details of a particular ticket, let's try to do that
in JIRA.

CASSANDRA-14525: Cluster enters an inconsistent state after bootstrap
failures. (Correctness bug, Production impact, Ready to Commit)

CASSANDRA-14459: DES sends requests to the wrong nodes routinely. (SLA
breaking latencies, Production impact, Review in progress)

CASSANDRA-14303 and CASSANDRA-14557: Currently production 3.0+ clusters
cannot be rebuilt after node failure due to 3.0’s introduction of the
system_auth keyspace with rf of 1. These tickets both fix the regression
introduced in 3.0 by letting operators configure rf=3 and prevent future
outages (Usability bug, Production impact, Patch Available).

CASSANDRA-14096: Cassandra 3.11.1 Repair Causes Out of Memory. We believe
this may also impact 3.0 (Title says it all, Production impact, Patch
Available)

CASSANDRA-10023: It is impossible to accurately determine local read/write
calls on C*. This patch allows users to detect when they are choosing
incorrect coordinators. (Usability bug (troubleshoot), Review in progress)

CASSANDRA-10789: There is no way to safely stop bad clients bringing down
C* nodes. This patch would give operators a very important tool to use
during production incidents to mitigate impact. (Usability bug, Production
Impact (recovery), Patch Available)

CASSANDRA-13010: No visibility into which disk is being compacted to.
(Usability bug, Production Impact (troubleshoot), Review in progress)

CASSANDRA-12783 - Break up large MV mutations to prevent OOMs (Title says
it all, Production Impact, Patch InProgress/ Awaiting Feedback)

CASSANDRA-14319 - nodetool rebuild from DC lets you pass invalid
datacenters (Usability bug, Production impact, Patch available)

CASSANDRA-13841 - Smarter nodetool rebuild. Kind of a bug but would be nice
to get it in 4.0. (Production Impact (recovery), Patch Available)

CASSANDRA-9452: Cleanup of old configuration, confusing to new C*
operators. (Cleanup, Patch Available)

CASSANDRA-14309: Hint window persistence across the record. This way hints
that are accumulated over a period of time when nodes are creating are less
likely to take down the entire cluster. (Potential Production Impact, Patch
Available)

CASSANDRA-14291: Bug from CASSANDRA-11163? (Usability Bug, Patch Available)

CASSANDRA-10540: RangeAware compaction. 256 vnode clusters really need this
to be able to do basic things like repair. The patch needs some rework
after transient replication (Production impact, needs contributor time)

URL for all the tickets: JIRA



Let me know.
Thanks,
Vinay Chella