Default membership and actor persistence

[cmeiklejohn]

The default membership for partisan does not persist the actor for a given instance of the peer service manager: this is something we inherited from Helium's peer service. Because of the use of the ORSWOT, this doesn't necessarily cause a huge problem: each node could potentially be added and removed by two actors, doubling the size complexity. This is based on the original restriction placed on the Plumtree peer service where an actor could only remove itself.

It probably makes the most sense to have a node, when coming back online with it's original state, preserve it's actor identifier.

[aramallo]

We could use a UUIDv5 to get a deterministic but unique ID based on some data. A UUIDv5 takes another UUID and a binary as input.

We could for example identify the cluster with a UUIDv4 value cluster_id, provided via config (think of it as equivalent to the disterl cookie). We then call UUID.v5(cluster_id, partisan:node())

[mcesaro]

Would ULID https://github.com/savonarola/ulid work for this use case?

[aramallo]

@mcesaro ULIDs are like KSUIDs so they are not deterministic (they are based on a timestamp).

In this case, we would need to have the same actor ID as before, which would typically require some form of persistence. However, if we could use a deterministic ID based on some content, we could avoid the need for persistence. That's why UUIDv5 came to mind :-)