I think it would be much more natural to write tests for the deterministic runtime if we allowed for creating "sub-instances" that were seen by applications as an independent instance (but still driven by a shared task queue for determinism).
This would allow for giving each instance its own IP (right now the same IP is shared by all: #2344), the same storage partition is shared by all (need to explicitly manage partitioning when handing to applications), and metrics are lumped together (need to ensure each instance has namespaced tasks).
If we do this right, it should allow for unblocking #2061 by allowing us to define link latency between IPs rather than peer identities. This would also unblock instance-specific storage performance #156.
TL;DR have an option to instantiate a "deterministic runtime manager" that can return "deterministic runtimes".
I think it would be much more natural to write tests for the deterministic runtime if we allowed for creating "sub-instances" that were seen by applications as an independent instance (but still driven by a shared task queue for determinism).
This would allow for giving each instance its own IP (right now the same IP is shared by all: #2344), the same storage partition is shared by all (need to explicitly manage partitioning when handing to applications), and metrics are lumped together (need to ensure each instance has namespaced tasks).
If we do this right, it should allow for unblocking #2061 by allowing us to define link latency between IPs rather than peer identities. This would also unblock instance-specific storage performance #156.
TL;DR have an option to instantiate a "deterministic runtime manager" that can return "deterministic runtimes".