Re: Downgradability

[Jacek Lewandowski]

A bit of organization - I've created
https://issues.apache.org/jira/browse/CASSANDRA-18300 epic to track tickets
related to the downgradability. Please add the tickets you are aware of.

thanks
- - -- --- -  -
Jacek Lewandowski


czw., 23 lut 2023 o 17:47 Benedict  napisał(a):

> Either way, it feels like this has become much more of a big deal than it
> needed to.
>
> I would prefer the pending patches to avoid breaking compatibility, as I
> think they can do it easily. But, if we agree to block release until we can
> double back to fix it with versioned writing (which I agree with Jacek are
> LHF - I think we literally just need a method that chooses the descriptor
> version) then let’s not further agonise over this.
>
> Alternatively I’d be happy to work with the authors to get this done
> alongside their work, as I don’t think it would hold anything up. We just
> need something to pick a descriptor besides latest on write, everything
> else is basically there for these patches.
>
>
> On 23 Feb 2023, at 16:37, Henrik Ingo  wrote:
>
> 
> Right. So I'm speculating everyone else who worked on a patch that breaks
> compatibility has been working under the mindset "I'll just put this behind
> the same switch". Or something more vague / even less correct, such as
> assuming that tries would become the default immediately.
>
> At least in my mind when we talk about the "switch to enable tries" I do
> also consider things like "don't break streaming". So I guess whether one
> considers "a switch" to exist already or not, might be subjective in this
> case, because people have different assumptions on the definition of done
> of such a switch.
>
> henrik
>
> On Thu, Feb 23, 2023 at 2:53 PM Benedict  wrote:
>
>> I don’t think there’s anything about a new format that requires a version
>> bump, but I could be missing something.
>>
>> We have to have a switch to enable tries already don’t we? I’m pretty
>> sure we haven’t talked about switching the default format?
>>
>> On 23 Feb 2023, at 12:12, Henrik Ingo  wrote:
>>
>> 
>> On Thu, Feb 23, 2023 at 11:57 AM Benedict  wrote:
>>
>>> Can somebody explain to me why this is being fought tooth and nail, when
>>> the work involved is absolutely minimal?
>>>
>>>
>> I don't know how each individual has been thinking about this, but it
>> seems to me just looking at all the tasks that at least the introduction of
>> tries is a major format change anyway - since it's the whole point - and
>> therefore people working on other tasks may have assumed the format is
>> changing anyway and therefore something like a switch (is this what is
>> referred to as the C-8110 solution?) will take care of it for everyone.
>>
>> I'm not sure there's consensus that such a switch is a sufficient
>> resolution to this discussion, but if there were such a consensus, the next
>> question would be whether the patches that are otherwise ready now can
>> merge, or whether they will all be blocked waiting for the compatibility
>> solution first. And possibly better testing, etc. Letting them merge would
>> be justified by the desire to have more frequent and smaller increments of
>> work merged into trunk... well, I'm not going to repeat everything from
>> that discussion but the same pro's and con's apply.
>>
>> henrik
>> --
>>
>> Henrik Ingo
>>
>> c. +358 40 569 7354
>>
>> w. www.datastax.com
>>
>>
>> 
>> 
>> 
>> 
>>
>>
>
> --
>
> Henrik Ingo
>
> c. +358 40 569 7354
>
> w. www.datastax.com
>
>   
> 
> 
>
>

Re: [EXTERNAL] Re: [DISCUSS] Next release date

[Benjamin Lerer]

Sorry, I realized that when I started the discussion I probably did not
frame it enough as I see that it is now going into different directions.
The concerns I am seeing are:
1) A too small amount of time between releases  is inefficient from a
development perspective and from a user perspective. From a development
point of view because we are missing time to deliver some features. From a
user perspective because they cannot follow with the upgrade.
2) Some features are so anticipated (Accord being the one mentioned) that
people would prefer to delay the release to make sure that it is available
as soon as possible.
3) We do not know how long we need to go from the freeze to GA. We hope for
2 months but our last experience was 6 months. So delaying the release
could mean not releasing this year.
4) For people doing marketing it is really hard to promote a product when
you do not know when the release will come and what features might be there.

All those concerns are probably even made worse by the fact that we do not
have a clear visibility on where we are.

Should we clarify that part first by getting an idea of the status of the
different CEPs and other big pieces of work? From there we could agree on
some timeline for the freeze. We could then discuss how to make predictable
the time from freeze to GA.



Le sam. 4 mars 2023 à 18:14, Josh McKenzie  a écrit :

> (for convenience sake, I'm referring to both Major and Minor semver
> releases as "major" in this email)
>
> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
> would advocate to delay until this has sufficient quality to be in
> production.
>
> This approach can be pretty unpredictable in this domain; often unforeseen
> things come up in implementation that can give you a long tail on something
> being production ready. For the record - I don't intend to single Accord
> out *at all* on this front, quite the opposite given how much rigor's
> gone into the design and implementation. I'm just thinking from my personal
> experience: everything I've worked on, overseen, or followed closely on
> this codebase always has a few tricks up its sleeve along the way to having
> edge-cases stabilized.
>
> Much like on some other recent topics, I think there's a nuanced middle
> ground where we take things on a case-by-case basis. Some factors that have
> come up in this thread that resonated with me:
>
> For a given potential release date 'X':
> 1. How long has it been since the last release?
> 2. How long do we expect qualification to take from a "freeze" (i.e. no
> new improvement or features, branch) point?
> 3. What body of merged production ready work is available?
> 4. What body of new work do we have high confidence will be ready within Y
> time?
>
> I think it's worth defining a loose "minimum bound and upper bound" on
> release cycles we want to try and stick with barring extenuating
> circumstances. For instance: try not to release sooner than maybe 10 months
> out from a prior major, and try not to release later than 18 months out
> from a prior major. Make exceptions if truly exceptional things land, are
> about to land, or bugs are discovered around those boundaries.
>
> Applying the above framework to what we have in flight, our last release
> date, expectations on CI, etc - targeting an early fall freeze (pending CEP
> status) and mid to late fall or December release "feels right" to me.
>
> With the exception, of course, that if something merges earlier, is
> stable, and we feel is valuable enough to cut a major based on that, we do
> it.
>
> ~Josh
>
> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>
> Hi,
>
> We shouldn't release just for releases sake. Are there enough new features
> and are they working well enough (quality!).
>
> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I
> would advocate to delay until this has sufficient quality to be in
> production.
>
> Just because something is released doesn't mean anyone is gonna use it. To
> add some operator perspective: Every time there is a new release we need to
> decide
> 1) are we supporting it
> 2) which other release can we deprecate
>
> and potentially migrate people - which is also a tough sell if there are
> no significant features and/or breaking changes.  So from my perspective
> less frequent releases are better - after all we haven't gotten around to
> support 4.1 🙂
>
> The 5.0 release is also coupled with deprecating  3.11 which is what a
> significant amount of people are using - given 4.1 took longer I am not
> sure how many people are assuming that 5 will be delayed and haven't made
> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a bit
> more deliberate with releasing 5.0 and having a longer beta phase are all
> things we should consider.
>
> My 2cts,
> German
>
> *From:* Benedict 
> *Sent:* Wednesday, March 1, 2023 5:59 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [DISCUSS

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

[Miklosovic, Stefan]

Hi all,

some time ago we identified an issue with NetworkTopologyStrategy. The problem 
is that when RF > number of racks, it may happen that NTS places replicas in 
such a way that when whole rack is lost, we lose QUORUM and data are not 
available anymore if QUORUM CL is used.

To illustrate this problem, lets have this setup:

9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place 
replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in 
rack3. Hence, when rack1 is lost, we do not have QUORUM.

It seems to us that there is already some logic around this scenario (1) but 
the implementation is not entirely correct. This solution is not computing the 
replica placement correctly so the above problem would be addressed.

We created a draft here (2, 3) which fixes it.

There is also a test which simulates this scenario. When I assign 256 tokens to 
each node randomly (by same mean as generatetokens command uses) and I try to 
compute natural replicas for 1 billion random tokens and I compute how many 
cases there will be when 3 replicas out of 5 are inserted in the same rack (so 
by losing it we would lose quorum), for above setup I get around 6%.

For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10% cases.

To interpret this number, it basically means that with such topology, RF and 
CL, when a random rack fails completely, when doing a random read, there is 6% 
chance that data will not be available (or 10%, respectively).

One caveat here is that NTS is not compatible with this new strategy anymore 
because it will place replicas differently. So I guess that fixing this in NTS 
will not be possible because of upgrades. I think people would need to setup 
completely new keyspace and somehow migrate data if they wish or they just 
start from scratch with this strategy.

Questions:

1) do you think this is meaningful to fix and it might end up in trunk?

2) should not we just ban this scenario entirely? It might be possible to check 
the configuration upon keyspace creation (rf > num of racks) and if we see this 
is problematic we would just fail that query? Guardrail maybe?

3) people in the ticket mention writing "CEP" for this but I do not see any 
reason to do so. It is just a strategy as any other. What would that CEP would 
even be about? Is this necessary?

Regards

(1) 
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
(2) https://github.com/apache/cassandra/pull/2191
(3) https://issues.apache.org/jira/browse/CASSANDRA-16203

Re: [DISCUSS] Should separate snapshots with the same name be allowed in different tables?

[Brandon Williams]

On Sun, Mar 5, 2023 at 11:00 PM Paulo Motta  wrote:
> I found this a bit surprising, since I would expect a snapshot with the same 
> name on different tables to represent the same logical snapshot taken at the 
> same point-in-time.

I would expect this too, 100%.

> This affects the design of the snapshots virtual table schema on 
> CASSANDRA-18102[1] because the timestamp needs to be included in the primary 
> key to allow distinguishing between different snapshots with the same name, 
> which seems a bit counter-intuitive.
>
> I think we should disallow creating a snapshot if another snapshot already 
> exists with the same name in any other table, so snapshots with the same name 
> on different tables are guaranteed to belong to the same logical 
> point-in-time snapshot.

I agree.  Even if there is a use case for that behavior, it will
almost certainly mislead someone later.

Kind Regards,
Brandon

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

[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 count.

A discuss thread seems fine for this rather than a CEP to me.

— Scott

> On Mar 6, 2023, at 2:51 AM, Miklosovic, Stefan  
> wrote:
> 
> Hi all,
> 
> some time ago we identified an issue with NetworkTopologyStrategy. The 
> problem is that when RF > number of racks, it may happen that NTS places 
> replicas in such a way that when whole rack is lost, we lose QUORUM and data 
> are not available anymore if QUORUM CL is used.
> 
> To illustrate this problem, lets have this setup:
> 
> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place 
> replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in 
> rack3. Hence, when rack1 is lost, we do not have QUORUM.
> 
> It seems to us that there is already some logic around this scenario (1) but 
> the implementation is not entirely correct. This solution is not computing 
> the replica placement correctly so the above problem would be addressed.
> 
> We created a draft here (2, 3) which fixes it.
> 
> There is also a test which simulates this scenario. When I assign 256 tokens 
> to each node randomly (by same mean as generatetokens command uses) and I try 
> to compute natural replicas for 1 billion random tokens and I compute how 
> many cases there will be when 3 replicas out of 5 are inserted in the same 
> rack (so by losing it we would lose quorum), for above setup I get around 6%.
> 
> For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10% cases.
> 
> To interpret this number, it basically means that with such topology, RF and 
> CL, when a random rack fails completely, when doing a random read, there is 
> 6% chance that data will not be available (or 10%, respectively).
> 
> One caveat here is that NTS is not compatible with this new strategy anymore 
> because it will place replicas differently. So I guess that fixing this in 
> NTS will not be possible because of upgrades. I think people would need to 
> setup completely new keyspace and somehow migrate data if they wish or they 
> just start from scratch with this strategy.
> 
> Questions:
> 
> 1) do you think this is meaningful to fix and it might end up in trunk?
> 
> 2) should not we just ban this scenario entirely? It might be possible to 
> check the configuration upon keyspace creation (rf > num of racks) and if we 
> see this is problematic we would just fail that query? Guardrail maybe?
> 
> 3) people in the ticket mention writing "CEP" for this but I do not see any 
> reason to do so. It is just a strategy as any other. What would that CEP 
> would even be about? Is this necessary?
> 
> Regards
> 
> (1) 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
> (2) https://github.com/apache/cassandra/pull/2191
> (3) https://issues.apache.org/jira/browse/CASSANDRA-16203

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

[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 with the loss of a
majority of replicas (e.g. ONE). For example, we don't fail if someone uses
ALL or EACH_QUORUM with a problematic setup, do we? Would we warn on
keyspace creation with RF > racks or are you suggesting that the warning
would be at query time?
3) agreed, this doesn't seem like an enhancement as much as it is
identifying legal but likely incorrect configuration

Cheers,

Derek

On Mon, Mar 6, 2023 at 3:52 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi all,
>
> some time ago we identified an issue with NetworkTopologyStrategy. The
> problem is that when RF > number of racks, it may happen that NTS places
> replicas in such a way that when whole rack is lost, we lose QUORUM and
> data are not available anymore if QUORUM CL is used.
>
> To illustrate this problem, lets have this setup:
>
> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place
> replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in
> rack3. Hence, when rack1 is lost, we do not have QUORUM.
>
> It seems to us that there is already some logic around this scenario (1)
> but the implementation is not entirely correct. This solution is not
> computing the replica placement correctly so the above problem would be
> addressed.
>
> We created a draft here (2, 3) which fixes it.
>
> There is also a test which simulates this scenario. When I assign 256
> tokens to each node randomly (by same mean as generatetokens command uses)
> and I try to compute natural replicas for 1 billion random tokens and I
> compute how many cases there will be when 3 replicas out of 5 are inserted
> in the same rack (so by losing it we would lose quorum), for above setup I
> get around 6%.
>
> For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10% cases.
>
> To interpret this number, it basically means that with such topology, RF
> and CL, when a random rack fails completely, when doing a random read,
> there is 6% chance that data will not be available (or 10%, respectively).
>
> One caveat here is that NTS is not compatible with this new strategy
> anymore because it will place replicas differently. So I guess that fixing
> this in NTS will not be possible because of upgrades. I think people would
> need to setup completely new keyspace and somehow migrate data if they wish
> or they just start from scratch with this strategy.
>
> Questions:
>
> 1) do you think this is meaningful to fix and it might end up in trunk?
>
> 2) should not we just ban this scenario entirely? It might be possible to
> check the configuration upon keyspace creation (rf > num of racks) and if
> we see this is problematic we would just fail that query? Guardrail maybe?
>
> 3) people in the ticket mention writing "CEP" for this but I do not see
> any reason to do so. It is just a strategy as any other. What would that
> CEP would even be about? Is this necessary?
>
> Regards
>
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
> (2) https://github.com/apache/cassandra/pull/2191
> (3) https://issues.apache.org/jira/browse/CASSANDRA-16203



-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

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

[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, then that
less-bad version probably wants to reject invalid configs (like RF=3 with 2
racks), but again, it'll be approximately impossible for anyone to document
what it takes to move from the maybe-unsafe version to the definitely-safe
version without rewriting all of the data into the cluster, so most people
won't be able to use it anyway?





On Mon, Mar 6, 2023 at 8:31 AM Derek Chen-Becker 
wrote:

> 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 with the loss
> of a majority of replicas (e.g. ONE). For example, we don't fail if someone
> uses ALL or EACH_QUORUM with a problematic setup, do we? Would we warn on
> keyspace creation with RF > racks or are you suggesting that the warning
> would be at query time?
> 3) agreed, this doesn't seem like an enhancement as much as it is
> identifying legal but likely incorrect configuration
>
> Cheers,
>
> Derek
>
> On Mon, Mar 6, 2023 at 3:52 AM Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>> Hi all,
>>
>> some time ago we identified an issue with NetworkTopologyStrategy. The
>> problem is that when RF > number of racks, it may happen that NTS places
>> replicas in such a way that when whole rack is lost, we lose QUORUM and
>> data are not available anymore if QUORUM CL is used.
>>
>> To illustrate this problem, lets have this setup:
>>
>> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place
>> replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in
>> rack3. Hence, when rack1 is lost, we do not have QUORUM.
>>
>> It seems to us that there is already some logic around this scenario (1)
>> but the implementation is not entirely correct. This solution is not
>> computing the replica placement correctly so the above problem would be
>> addressed.
>>
>> We created a draft here (2, 3) which fixes it.
>>
>> There is also a test which simulates this scenario. When I assign 256
>> tokens to each node randomly (by same mean as generatetokens command uses)
>> and I try to compute natural replicas for 1 billion random tokens and I
>> compute how many cases there will be when 3 replicas out of 5 are inserted
>> in the same rack (so by losing it we would lose quorum), for above setup I
>> get around 6%.
>>
>> For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10%
>> cases.
>>
>> To interpret this number, it basically means that with such topology, RF
>> and CL, when a random rack fails completely, when doing a random read,
>> there is 6% chance that data will not be available (or 10%, respectively).
>>
>> One caveat here is that NTS is not compatible with this new strategy
>> anymore because it will place replicas differently. So I guess that fixing
>> this in NTS will not be possible because of upgrades. I think people would
>> need to setup completely new keyspace and somehow migrate data if they wish
>> or they just start from scratch with this strategy.
>>
>> Questions:
>>
>> 1) do you think this is meaningful to fix and it might end up in trunk?
>>
>> 2) should not we just ban this scenario entirely? It might be possible to
>> check the configuration upon keyspace creation (rf > num of racks) and if
>> we see this is problematic we would just fail that query? Guardrail maybe?
>>
>> 3) people in the ticket mention writing "CEP" for this but I do not see
>> any reason to do so. It is just a strategy as any other. What would that
>> CEP would even be about? Is this necessary?
>>
>> Regards
>>
>> (1)
>> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
>> (2) https://github.com/apache/cassandra/pull/2191
>> (3) https://issues.apache.org/jira/browse/CASSANDRA-16203
>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

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

[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 new correct placement logic for newly created
keyspaces instead of having a new strategy?

The placement logic would be backwards-compatible for RF <= #racks. On
upgrade, we could mark existing keyspaces with RF > #racks with
use_legacy_replica_placement=true to maintain backwards compatibility and
log a warning that the rack loss guarantee is not maintained for keyspaces
created before the fix. Old keyspaces with RF <=#racks would still work
with the new replica placement. The downside is that we would need to keep
the old NTS logic around, or we could eventually deprecate it and require
users to migrate keyspaces using the legacy placement strategy.

Alternatively we could have RackAwareTopologyStrategy and fail NTS keyspace
creation for RF > #racks and indicate users to
use RackAwareTopologyStrategy to maintain the quorum guarantee on rack loss
or set an override flag "support_quorum_on_rack_loss=false". This feels a
bit iffy though since it could potentially confuse users about when to use
each strategy.

On Mon, Mar 6, 2023 at 5:51 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Hi all,
>
> some time ago we identified an issue with NetworkTopologyStrategy. The
> problem is that when RF > number of racks, it may happen that NTS places
> replicas in such a way that when whole rack is lost, we lose QUORUM and
> data are not available anymore if QUORUM CL is used.
>
> To illustrate this problem, lets have this setup:
>
> 9 nodes in 1 DC, 3 racks, 3 nodes per rack. RF = 5. Then, NTS could place
> replicas like this: 3 replicas in rack1, 1 replica in rack2, 1 replica in
> rack3. Hence, when rack1 is lost, we do not have QUORUM.
>
> It seems to us that there is already some logic around this scenario (1)
> but the implementation is not entirely correct. This solution is not
> computing the replica placement correctly so the above problem would be
> addressed.
>
> We created a draft here (2, 3) which fixes it.
>
> There is also a test which simulates this scenario. When I assign 256
> tokens to each node randomly (by same mean as generatetokens command uses)
> and I try to compute natural replicas for 1 billion random tokens and I
> compute how many cases there will be when 3 replicas out of 5 are inserted
> in the same rack (so by losing it we would lose quorum), for above setup I
> get around 6%.
>
> For 12 nodes, 3 racks, 4 nodes per rack, rf = 5, this happens in 10% cases.
>
> To interpret this number, it basically means that with such topology, RF
> and CL, when a random rack fails completely, when doing a random read,
> there is 6% chance that data will not be available (or 10%, respectively).
>
> One caveat here is that NTS is not compatible with this new strategy
> anymore because it will place replicas differently. So I guess that fixing
> this in NTS will not be possible because of upgrades. I think people would
> need to setup completely new keyspace and somehow migrate data if they wish
> or they just start from scratch with this strategy.
>
> Questions:
>
> 1) do you think this is meaningful to fix and it might end up in trunk?
>
> 2) should not we just ban this scenario entirely? It might be possible to
> check the configuration upon keyspace creation (rf > num of racks) and if
> we see this is problematic we would just fail that query? Guardrail maybe?
>
> 3) people in the ticket mention writing "CEP" for this but I do not see
> any reason to do so. It is just a strategy as any other. What would that
> CEP would even be about? Is this necessary?
>
> Regards
>
> (1)
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L126-L128
> (2) https://github.com/apache/cassandra/pull/2191
> (3) https://issues.apache.org/jira/browse/CASSANDRA-16203