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 <vinaykumar...@gmail.com> > 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 <kohlisank...@gmail.com> >> 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 <jmcken...@apache.org> >> > 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 >> > >> > >> >
