Nim-libp2p partition scenario in regression : deploy the bootstrap after the split is applied

[radiken]

Nodes no longer wait for COLDSTARTDELAY before dialling, so the partition scenario's halves could mesh through the bootstrap before the network policies existed. The partition now deploys the bootstrap after the split, so no node finds a peer before it.

related to #321

[AlbertoSoutullo]

I don't know if I am following this.

1. If we are doing a change in the partition experiment, why this change is not in partition.py?
2. Why are we deploying the bootstrap after the split? If we are doing the split and we don't want the nodes to re-discover each other after the split, we could theoretically just kill the bootstrap node, and then apply the partition. Why do we need to deploy a bootstrap node afterwards?

[radiken]

1. If we are doing a change in the partition experiment, why this change is not in partition.py?

The deploy order lives in NimLibp2pExperiment._run, so partition.py cannot reorder it without overriding the whole sequence, so I think it would be better to set a flag there only.

2. Why are we deploying the bootstrap after the split? If we are doing the split and we don't want the nodes to re-discover each other after the split, we could theoretically just kill the bootstrap node, and then apply the partition. Why do we need to deploy a bootstrap node afterwards?

This scenario's name is now a bit confusing, there is no spliting, we are just trying to start two networks and join them. That's because I didn't find a way to unconnect two networks ones they are connected.

And the problem now is that, the 1000 pods rollout takes about 2 minutes, so by the time the pods exist and we can label them, they have already found each other. Killing the bootstrap would not unconnect them here as well.

I agree this is not the best code, but at the moment I don't have a better way to implement this test case...

[radiken]

Putting this on hold to find a better way to implement this scenario