Re: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti]

Another note about 14557 - this also lets us fix 3.0 regression where we
cannot bootstrap new nodes until system_auth keyspace (that comes up with
RF=1) is "altered" to a higher RF. Instead, with 14557, one can set yaml
property minimum_keyspace_rf to, say, 3 and system keyspaces would honor it
(more in the JIRA).

Thanks,
Sumanth

On Tue, Jan 15, 2019 at 8:46 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:

> With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
> it makes it further easy to create keyspaces (without having to always
> mention RF) and provides a way to ensure keyspaces are created with a
> minimum required RF.
>
> Thanks,
> Sumanth
>
> On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella 
> wrote:
>
>> Thanks for the responses, I think the summary so far is: committers and
>> reviewers are positive on reviewing the community tickets mentioned in
>> this
>> email except for a couple of them that Joshua mentioned, with the caution
>> of
>> not disrupting the current testing efforts.
>>
>> Thank you, Ariel, for understanding the concerns and helping with reviews.
>>
>> Thank you, Jon, for picking up CASSANDRA-14303.
>>
>> @Joshua, if you can comment on the tickets that concern you that would be
>> helpful, and I will take them off from my list to track for 4.0.
>>
>> I would like to help drive these tickets to their completion in 4.0
>> (either
>> deferred or committed) unless someone has concerns.
>>
>> Thanks,
>> Vinay
>>
>>
>> On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli 
>> wrote:
>>
>> > We already should be taking correctness and perf changes and I am +1 on
>> > taking operational tickets. Agree with Josh that the only exception
>> will be
>> > if it causes disruption in testing.
>> >
>> > I think as a project we should be more open to operational issues as
>> > having a fork is not ideal.
>> >
>> > Regarding time it is taking to review things, I think we should not
>> start
>> > doing big features post 4.0 but instead review all possible JIRAs first.
>> > Once we are out of this debt, we should define a  process so that we
>> don’t
>> > end up in this state. I think this item deserves a separate thread
>> which we
>> > can start closer to 4.0 being cut.
>> >
>> > > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie 
>> > wrote:
>> > >
>> > > Strong +1 on prioritizing community engagement 1st and caution second,
>> > > though still prioritizing it. I think the right metric for us to
>> > calibrate
>> > > around is that "disrupt in-flight testing cycles", i.e. if changes
>> cause
>> > > significant rework for people that have already begun testing 4.0,
>> > probably
>> > > ok to review and get it in but target 4.0.x.
>> > >
>> > > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
>> > bened...@apache.org>
>> > > wrote:
>> > >
>> > >>> I assume it's obvious to everyone that this should be taken on a
>> > >>> case-by-case basis. There's at least 2 that were in that list (one
>> of
>> > >> which
>> > >>> Marcus bumped off PA) that are potentially big and hairy changes
>> that
>> > >> would
>> > >>> disrupt in-flight testing cycles.
>> > >>
>> > >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
>> > >>
>> > >>
>> > >> -
>> > >> 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: Request to review feature-freeze proposed tickets

[Sumanth Pasupuleti]

With 14303 in (thanks to Jon), wanted to see if I can get help on 14557 -
it makes it further easy to create keyspaces (without having to always
mention RF) and provides a way to ensure keyspaces are created with a
minimum required RF.

Thanks,
Sumanth

On Wed, Dec 5, 2018 at 5:35 PM Vinay Chella  wrote:

> Thanks for the responses, I think the summary so far is: committers and
> reviewers are positive on reviewing the community tickets mentioned in this
> email except for a couple of them that Joshua mentioned, with the caution
> of
> not disrupting the current testing efforts.
>
> Thank you, Ariel, for understanding the concerns and helping with reviews.
>
> Thank you, Jon, for picking up CASSANDRA-14303.
>
> @Joshua, if you can comment on the tickets that concern you that would be
> helpful, and I will take them off from my list to track for 4.0.
>
> I would like to help drive these tickets to their completion in 4.0 (either
> deferred or committed) unless someone has concerns.
>
> Thanks,
> Vinay
>
>
> On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli 
> wrote:
>
> > We already should be taking correctness and perf changes and I am +1 on
> > taking operational tickets. Agree with Josh that the only exception will
> be
> > if it causes disruption in testing.
> >
> > I think as a project we should be more open to operational issues as
> > having a fork is not ideal.
> >
> > Regarding time it is taking to review things, I think we should not start
> > doing big features post 4.0 but instead review all possible JIRAs first.
> > Once we are out of this debt, we should define a  process so that we
> don’t
> > end up in this state. I think this item deserves a separate thread which
> we
> > can start closer to 4.0 being cut.
> >
> > > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie 
> > wrote:
> > >
> > > Strong +1 on prioritizing community engagement 1st and caution second,
> > > though still prioritizing it. I think the right metric for us to
> > calibrate
> > > around is that "disrupt in-flight testing cycles", i.e. if changes
> cause
> > > significant rework for people that have already begun testing 4.0,
> > probably
> > > ok to review and get it in but target 4.0.x.
> > >
> > > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> > bened...@apache.org>
> > > wrote:
> > >
> > >>> I assume it's obvious to everyone that this should be taken on a
> > >>> case-by-case basis. There's at least 2 that were in that list (one of
> > >> which
> > >>> Marcus bumped off PA) that are potentially big and hairy changes that
> > >> would
> > >>> disrupt in-flight testing cycles.
> > >>
> > >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> > >>
> > >>
> > >> -
> > >> 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: Request to review feature-freeze proposed tickets

[Vinay Chella]

Thanks for the responses, I think the summary so far is: committers and
reviewers are positive on reviewing the community tickets mentioned in this
email except for a couple of them that Joshua mentioned, with the caution of
not disrupting the current testing efforts.

Thank you, Ariel, for understanding the concerns and helping with reviews.

Thank you, Jon, for picking up CASSANDRA-14303.

@Joshua, if you can comment on the tickets that concern you that would be
helpful, and I will take them off from my list to track for 4.0.

I would like to help drive these tickets to their completion in 4.0 (either
deferred or committed) unless someone has concerns.

Thanks,
Vinay


On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli 
wrote:

> We already should be taking correctness and perf changes and I am +1 on
> taking operational tickets. Agree with Josh that the only exception will be
> if it causes disruption in testing.
>
> I think as a project we should be more open to operational issues as
> having a fork is not ideal.
>
> Regarding time it is taking to review things, I think we should not start
> doing big features post 4.0 but instead review all possible JIRAs first.
> Once we are out of this debt, we should define a  process so that we don’t
> end up in this state. I think this item deserves a separate thread which we
> can start closer to 4.0 being cut.
>
> > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie 
> wrote:
> >
> > Strong +1 on prioritizing community engagement 1st and caution second,
> > though still prioritizing it. I think the right metric for us to
> calibrate
> > around is that "disrupt in-flight testing cycles", i.e. if changes cause
> > significant rework for people that have already begun testing 4.0,
> probably
> > ok to review and get it in but target 4.0.x.
> >
> > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >>> I assume it's obvious to everyone that this should be taken on a
> >>> case-by-case basis. There's at least 2 that were in that list (one of
> >> which
> >>> Marcus bumped off PA) that are potentially big and hairy changes that
> >> would
> >>> disrupt in-flight testing cycles.
> >>
> >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> >>
> >>
> >> -
> >> 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: Request to review feature-freeze proposed tickets

[Sankalp Kohli]

We already should be taking correctness and perf changes and I am +1 on taking 
operational tickets. Agree with Josh that the only exception will be if it 
causes disruption in testing.

I think as a project we should be more open to operational issues as having a 
fork is not ideal. 

Regarding time it is taking to review things, I think we should not start doing 
big features post 4.0 but instead review all possible JIRAs first. Once we are 
out of this debt, we should define a  process so that we don’t end up in this 
state. I think this item deserves a separate thread which we can start closer 
to 4.0 being cut. 

> On Nov 23, 2018, at 12:17 AM, Joshua McKenzie  wrote:
> 
> Strong +1 on prioritizing community engagement 1st and caution second,
> though still prioritizing it. I think the right metric for us to calibrate
> around is that "disrupt in-flight testing cycles", i.e. if changes cause
> significant rework for people that have already begun testing 4.0, probably
> ok to review and get it in but target 4.0.x.
> 
> On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith 
> wrote:
> 
>>> I assume it's obvious to everyone that this should be taken on a
>>> case-by-case basis. There's at least 2 that were in that list (one of
>> which
>>> Marcus bumped off PA) that are potentially big and hairy changes that
>> would
>>> disrupt in-flight testing cycles.
>> 
>> Agreed.  I’d prefer we aim to be as permissive as practical, though.
>> 
>> 
>> -
>> 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: Request to review feature-freeze proposed tickets

[Joshua McKenzie]

Strong +1 on prioritizing community engagement 1st and caution second,
though still prioritizing it. I think the right metric for us to calibrate
around is that "disrupt in-flight testing cycles", i.e. if changes cause
significant rework for people that have already begun testing 4.0, probably
ok to review and get it in but target 4.0.x.

On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith 
wrote:

> > I assume it's obvious to everyone that this should be taken on a
> > case-by-case basis. There's at least 2 that were in that list (one of
> which
> > Marcus bumped off PA) that are potentially big and hairy changes that
> would
> > disrupt in-flight testing cycles.
>
> Agreed.  I’d prefer we aim to be as permissive as practical, though.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Request to review feature-freeze proposed tickets

[Benedict Elliott Smith]

> I assume it's obvious to everyone that this should be taken on a
> case-by-case basis. There's at least 2 that were in that list (one of which
> Marcus bumped off PA) that are potentially big and hairy changes that would
> disrupt in-flight testing cycles.

Agreed.  I’d prefer we aim to be as permissive as practical, though.


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

Re: Request to review feature-freeze proposed tickets

[Joshua McKenzie]

> If those tickets were sitting in patch available state prior to the
freeze they *should* get in.
I assume it's obvious to everyone that this should be taken on a
case-by-case basis. There's at least 2 that were in that list (one of which
Marcus bumped off PA) that are potentially big and hairy changes that would
disrupt in-flight testing cycles.

On Wed, Nov 21, 2018 at 3:43 AM dinesh.jo...@yahoo.com.INVALID
 wrote:

> Kurt, I don't believe this should be subject of "heated debate". If those
> tickets were sitting in patch available state prior to the freeze they
> *should* get in.
> Vinay, I can help review the tickets.
> Dinesh
>
> On Tuesday, November 20, 2018, 2:59:18 PM PST, kurt greaves <
> k...@instaclustr.com> wrote:
>
>  Thanks Vinay. While I suspect this will be subject to heated debate, I'm
> also for this. The time to review for this project is incredibly
> demotivating, and it stems from a lack of contributors that are interested
> in the general health of the project. I think this can be quite easily
> remedied by making more committers/PMC, however there is a catch-22 that to
> achieve this our existing set of committers needs to be dedicated to
> reviewing contributions from non-committers.
>
> If we can get dedicated reviewers for the listed tickets I'll take on some
> of the work to get the tickets up to scratch.
>
> On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > I would like to get as many of these as is feasible in. Before the
> feature
> > freeze started 1 out of 17 JIRAs that were patch available were reviewed
> > and committed.
> >
> > If you didn’t have access reviewers and committers, as the one out of the
> > 17 did, it has been essentially impossible to get your problems with
> > Cassandra fixed in 4.0.
> >
> > This is basically the same as saying that despite the fact Cassandra is
> > open source it does you no good because it will be years before the
> issues
> > impacting you get fixed even if you contribute the fixes yourself.
> >
> > Pulling up the ladder after getting “your own” fixes in is a sure fire
> way
> > to fracture the community into a collection of private forks containing
> the
> > fixes people can’t live without, and pushing people to look at
> alternatives.
> >
> > Private forks are a serious threat to the project. The people on them are
> > at risk of getting left behind and Cassandra stagnates for them and
> becomes
> > uncompetitive. Those with the resources to maintain a seriously diverged
> > fork are also the ones better positioned to be active contributors.
> >
> > Regards,
> > Ariel
> >
> > > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> > wrote:
> > >
> > > 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 Fee

Re: Request to review feature-freeze proposed tickets

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

Kurt, I don't believe this should be subject of "heated debate". If those 
tickets were sitting in patch available state prior to the freeze they *should* 
get in.
Vinay, I can help review the tickets.
Dinesh 

On Tuesday, November 20, 2018, 2:59:18 PM PST, kurt greaves 
 wrote:  
 
 Thanks Vinay. While I suspect this will be subject to heated debate, I'm
also for this. The time to review for this project is incredibly
demotivating, and it stems from a lack of contributors that are interested
in the general health of the project. I think this can be quite easily
remedied by making more committers/PMC, however there is a catch-22 that to
achieve this our existing set of committers needs to be dedicated to
reviewing contributions from non-committers.

If we can get dedicated reviewers for the listed tickets I'll take on some
of the work to get the tickets up to scratch.

On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:

> Hi,
>
> I would like to get as many of these as is feasible in. Before the feature
> freeze started 1 out of 17 JIRAs that were patch available were reviewed
> and committed.
>
> If you didn’t have access reviewers and committers, as the one out of the
> 17 did, it has been essentially impossible to get your problems with
> Cassandra fixed in 4.0.
>
> This is basically the same as saying that despite the fact Cassandra is
> open source it does you no good because it will be years before the issues
> impacting you get fixed even if you contribute the fixes yourself.
>
> Pulling up the ladder after getting “your own” fixes in is a sure fire way
> to fracture the community into a collection of private forks containing the
> fixes people can’t live without, and pushing people to look at alternatives.
>
> Private forks are a serious threat to the project. The people on them are
> at risk of getting left behind and Cassandra stagnates for them and becomes
> uncompetitive. Those with the resources to maintain a seriously diverged
> fork are also the ones better positioned to be active contributors.
>
> Regards,
> Ariel
>
> > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> wrote:
> >
> > 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 I

Re: Request to review feature-freeze proposed tickets

[Jonathan Haddad]

If nobody has any objections to CASSANDRA-14303 (default RF) being merged
in I can take care of it.  It's a significant usability improvement, looks
well tested and will prevent a number of headaches.

I'll try to get to it tomorrow.

Thanks for bringing these up, Vinay.

Jon

On Tue, Nov 20, 2018 at 5:59 PM kurt greaves  wrote:

> Thanks Vinay. While I suspect this will be subject to heated debate, I'm
> also for this. The time to review for this project is incredibly
> demotivating, and it stems from a lack of contributors that are interested
> in the general health of the project. I think this can be quite easily
> remedied by making more committers/PMC, however there is a catch-22 that to
> achieve this our existing set of committers needs to be dedicated to
> reviewing contributions from non-committers.
>
> If we can get dedicated reviewers for the listed tickets I'll take on some
> of the work to get the tickets up to scratch.
>
> On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:
>
> > Hi,
> >
> > I would like to get as many of these as is feasible in. Before the
> feature
> > freeze started 1 out of 17 JIRAs that were patch available were reviewed
> > and committed.
> >
> > If you didn’t have access reviewers and committers, as the one out of the
> > 17 did, it has been essentially impossible to get your problems with
> > Cassandra fixed in 4.0.
> >
> > This is basically the same as saying that despite the fact Cassandra is
> > open source it does you no good because it will be years before the
> issues
> > impacting you get fixed even if you contribute the fixes yourself.
> >
> > Pulling up the ladder after getting “your own” fixes in is a sure fire
> way
> > to fracture the community into a collection of private forks containing
> the
> > fixes people can’t live without, and pushing people to look at
> alternatives.
> >
> > Private forks are a serious threat to the project. The people on them are
> > at risk of getting left behind and Cassandra stagnates for them and
> becomes
> > uncompetitive. Those with the resources to maintain a seriously diverged
> > fork are also the ones better positioned to be active contributors.
> >
> > Regards,
> > Ariel
> >
> > > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> > wrote:
> > >
> > > 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.

Re: Request to review feature-freeze proposed tickets

[kurt greaves]

Thanks Vinay. While I suspect this will be subject to heated debate, I'm
also for this. The time to review for this project is incredibly
demotivating, and it stems from a lack of contributors that are interested
in the general health of the project. I think this can be quite easily
remedied by making more committers/PMC, however there is a catch-22 that to
achieve this our existing set of committers needs to be dedicated to
reviewing contributions from non-committers.

If we can get dedicated reviewers for the listed tickets I'll take on some
of the work to get the tickets up to scratch.

On Wed, 21 Nov 2018 at 02:12, Ariel Weisberg  wrote:

> Hi,
>
> I would like to get as many of these as is feasible in. Before the feature
> freeze started 1 out of 17 JIRAs that were patch available were reviewed
> and committed.
>
> If you didn’t have access reviewers and committers, as the one out of the
> 17 did, it has been essentially impossible to get your problems with
> Cassandra fixed in 4.0.
>
> This is basically the same as saying that despite the fact Cassandra is
> open source it does you no good because it will be years before the issues
> impacting you get fixed even if you contribute the fixes yourself.
>
> Pulling up the ladder after getting “your own” fixes in is a sure fire way
> to fracture the community into a collection of private forks containing the
> fixes people can’t live without, and pushing people to look at alternatives.
>
> Private forks are a serious threat to the project. The people on them are
> at risk of getting left behind and Cassandra stagnates for them and becomes
> uncompetitive. Those with the resources to maintain a seriously diverged
> fork are also the ones better positioned to be active contributors.
>
> Regards,
> Ariel
>
> > On Nov 18, 2018, at 9:18 PM, Vinay Chella 
> wrote:
> >
> > 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 tr

Re: Request to review feature-freeze proposed tickets

[Ariel Weisberg]

Hi,

I would like to get as many of these as is feasible in. Before the feature 
freeze started 1 out of 17 JIRAs that were patch available were reviewed and 
committed.

If you didn’t have access reviewers and committers, as the one out of the 17 
did, it has been essentially impossible to get your problems with Cassandra 
fixed in 4.0.

This is basically the same as saying that despite the fact Cassandra is open 
source it does you no good because it will be years before the issues impacting 
you get fixed even if you contribute the fixes yourself.

Pulling up the ladder after getting “your own” fixes in is a sure fire way to 
fracture the community into a collection of private forks containing the fixes 
people can’t live without, and pushing people to look at alternatives.

Private forks are a serious threat to the project. The people on them are at 
risk of getting left behind and Cassandra stagnates for them and becomes 
uncompetitive. Those with the resources to maintain a seriously diverged fork 
are also the ones better positioned to be active contributors.

Regards,
Ariel

> On Nov 18, 2018, at 9:18 PM, Vinay Chella  wrote:
> 
> 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


-
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