Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Miklosovic, Stefan
, March 7, 2023 22:37 To: dev@cassandra.apache.org Subject: Re: Degradation of availability when using NTS and RF > number of racks I am forwarding the message Ben Slater wrote me personally and asked me to post it. He has some problems with the subscription to this mailing list with his email. V

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Miklosovic, Stefan
high RF on system auth was more about replicating to lots of nodes than distributing across racks Cheers Ben From: Paulo Motta Sent: Tuesday, March 7, 2023 21:43 To: dev@cassandra.apache.org Subject: Re: Degradation of availability when using NTS and RF &

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Paulo Motta
the saying goes there is no silver bullet. If we decide to >> implement that new strategy, we would probably emit warnings anyway on NTS >> but it would be already done so just new strategy would be provided. >> >> >> >>

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Jeff Jirsa
; Sent: Monday, March 6, 2023 17:48 >> To: dev@cassandra.apache.org >> Subject: Re: Degradation of availability when using NTS and RF > number of racks >> >> NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sen

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Miklosovic, Stefan
___ From: Jeremiah D Jordan Sent: Tuesday, March 7, 2023 19:31 To: dev@cassandra.apache.org Subject: Re: Degradation of availability when using NTS and RF > number of racks NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Jeremiah D Jordan
t; offered ones. As the saying goes there is no silver bullet. If we decide >> >> to implement that new strategy, we would probably emit warnings anyway on >> >> NTS but it would be already done so just new strategy would be provided. >> >> >> >> _

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Aaron Ploetz
>> 100% bullet proof solution over time we might choose some approach from the >> offered ones. As the saying goes there is no silver bullet. If we decide to >> implement that new strategy, we would probably emit warnings anyway on NTS >> but it would be already done so

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Derek Chen-Becker
______________ > >> From: Paulo Motta > >> Sent: Monday, March 6, 2023 17:48 > >> To: dev@cassandra.apache.org > >> Subject: Re: Degradation of availability when using NTS and RF > number > of racks > >> > >> NetApp Securit

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Jeremiah D Jordan
nt that new strategy, we would probably emit warnings anyway on NTS >> but it would be already done so just new strategy would be provided. >> >> >> From: Paulo Motta >> Sent: Monday, March 6, 2023 17:48 >> To: dev@cassandr

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Benedict
@cassandra.apache.org > Subject: Re: Degradation of availability when using NTS and RF > number of > racks > > NetApp Security WARNING: This is an external email. Do not click links or > open attachments unless you recognize the sender and know the content is safe. > > &g

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-07 Thread Miklosovic, Stefan
Subject: Re: Degradation of availability when using NTS and RF > number of racks NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. It's a bit unfortunate that NTS does not maintain the

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-06 Thread Paulo Motta
It's a bit unfortunate that NTS does not maintain the ability to lose a rack without loss of quorum for RF > #racks > 2, since this can be easily achieved by evenly placing replicas across all racks. Since RackAwareTopologyStrategy is a superset of NetworkTopologyStrategy, can't we just use the ne

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-06 Thread Jeff Jirsa
A huge number of people use this legal and unsafe combination - like anyone running RF=3 in AWS us-west-1 (or any other region with only 2 accessible AZs), and no patch is going to suddenly make that safe, and banning it hurts users a lot. If we're really going to ship a less-bad version of this,

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-06 Thread Derek Chen-Becker
1) It does seem a like a big footgun. I think it violates the principle of least surprise if someone has configured NTS thinking that they are improving availability 2) I don't know that we want to ban it outright, since maybe there's a case for someone to be using a different CL that would be OK w

Re: Degradation of availability when using NTS and RF > number of racks

2023-03-06 Thread C. Scott Andreas
Modifying NTS in place would not be possible if it changes rack placement in a way that breaks existing clusters on upgrade. A strategy introducing a change to placement like this would need a new name. A new strategy would be fine in trunk. Logging a warning seems appropriate if RF > rack coun