The appeal to 'perfect is the enemy...' is appreciated. But I (we) have seen from experiences that this is about what is good rather than what is perfect.
I'm not suggesting we create a fool proof system, just one that is safe against what we know happens all too often in production systems. I believe there is some further analysis and testing happening, so I'm only asking that we take a bit of patience so that our definition of what is "good" (vs perfect) is grounded. On Wed., 19 Feb. 2020, 1:35 pm Jeremiah Jordan, <jerem...@datastax.com> wrote: > If you don’t know what you are doing you will have one rack which will > also be safe. If you are setting up racks then you most likely read > something about doing that, and should also be fine. > This discussion has gone off the rails 100 times with what ifs that are > “letting perfect be the enemy of good”. The setting doesn’t need to be > perfect. It just needs to be “good enough“. > > > On Feb 19, 2020, at 1:44 AM, Mick Semb Wever <m...@thelastpickle.com> > wrote: > > > > Why do we have to assume random assignment? > > > > > > > > Because token allocation only works once you have a node in RF racks. If > > you don't bootstrap nodes in alternating racks, or just never have RF > racks > > setup (but more than one rack) it's going to be random. > > > > Whatever default we choose should be a safe choice, not the best for > > experts. Making it safe (4 as the default would be great) shouldn't be > > difficult, and I thought Joey was building a list of related issues? > > > > Seeing these issues put together summarised would really help build the > > consensus IMHO. > > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
