No need to zap on passive sync if we see the node has a different append log.
It comes from an older history of how Nomad worked before, where it was possible to bring in a stripe any node, and nomad changes had to be exactly the same on all the nodes, even uuids.
Removing this line will help speed up the server restart thanks to this removal of zap process, which is not really needed for a passive sync since DC does not change or interact with server or entity data, but just the node's config.
Let's say we were doing a restrictive activation, or we were starting nodes auto-activated.
The passive would sync and detect that its append log does not match the active one (even when having the same cluster config).
The passive would then reset its config, sync the one from the active, ZAP and restart.
The ZAP step is no necessary, because when we are repairing a node, this step would zap the data of a node restarting with a new config forced into it.
No need to zap on passive sync if we see the node has a different append log.
It comes from an older history of how Nomad worked before, where it was possible to bring in a stripe any node, and nomad changes had to be exactly the same on all the nodes, even uuids.
Note: this change is completely unrelated to this bug: https://github.com/Terracotta-OSS/terracotta-platform/pull/1103
Removing this line will help speed up the server restart thanks to this removal of zap process, which is not really needed for a passive sync since DC does not change or interact with server or entity data, but just the node's config.
Let's say we were doing a restrictive activation, or we were starting nodes auto-activated. The passive would sync and detect that its append log does not match the active one (even when having the same cluster config). The passive would then reset its config, sync the one from the active, ZAP and restart.
The ZAP step is no necessary, because when we are repairing a node, this step would zap the data of a node restarting with a new config forced into it.