Alexandre Dutra
Alexandre Dutra
Hey team! Please [add your planning poker estimate](https://app.zenhub.com/workspaces/K8ssandra-60a54d01d464160012441e2f/issues/k8ssandra/cass-operator/381?planning-poker) with ZenHub @burmanm @adejanovski @Miles-Garnsey
A few data points to document what I'm seeing and what I'm going to modify: The distribution of pods in racks is deterministic and balanced already. It's deterministic because the...
> since rack names cannot be changed on a live datacenter, but the ordering in the manifest could be changed, using names would probably be more "deterministic". I'm not sure...
Hey team! Please [add your planning poker estimate](https://app.zenhub.com/workspaces/K8ssandra-60a54d01d464160012441e2f/issues/k8ssandra/cass-operator/393?planning-poker) with ZenHub @adejanovski @burmanm @Miles-Garnsey
It does look from your example that it is deterministic already. @bradfordcp can we close this? Asking since the issue was originally brought up by you.
So I actually think we need to change a few things, similar to what I did in #403 . The way we decommission does not take into account the actual...
You are right but my point is still valid I think, let's consider another example: * rack1 3 replicas: node1a, node1b, node1c * rack2 4 replicas: node2a, node2b, node2c, node2d...
Oh OK you were right all along. In my last example, node2d would go first since currentSize = 10, targetSize = 9. I opened #407 in the meantime, but we...
The only thing it does is reverse the rack order to be the opposite of declaration order.