Uri Shachar

@giampaolo - Are you open to PRs for resolving this? (Asking since you rejected the PR for #765) It will have to be linux specific (since cgroups are a linux...

> I just quickly take a look the new design for cluster V2, and I need take sometime to consume it. But I have one question: it looks like no...

> @ushachar I reviewed all discussions and description of the cluster v2 spec. I have one concern (aka you could understand maybe this is a bonus for this design). Now...

> The strategy being that we fork when migrating a slot, we establish the new connection, and then iterate over the slot space and sent the restore commands. Once all...

> > > The strategy being that we fork when migrating a slot, we establish the new connection, and then iterate over the slot space and sent the restore commands....

> * Once we finished sending the data of a slot from the "snapshot" taken by the child process, we then need to flush the COB of that slot to...

> > I suggest preserving the current behavior of gossiping the intermediate state (marking slot X as being imported/migrated in the relevant shards) as it would make it easier for...

> > I agree it complicates the IPC between parent and child a bit, but not that much (since some IPC is needed anyways) > > @ushachar, would you be...

> @ushachar maybe we want a new "admin health command". That gives a simple summary of important parts of the cluster. Adding it to slots or shards seems wrong, as...

> > @madolson This information is already visible in the current SLOTS/SHARDS output, so keeping it there seems like the path of least resistance... but it's not a big issue...