This issue originated from this discussion ThinkParQ/beegfs#70.

When storage nodes start with a new target, they generate a string ID that is stored in a file <storeStorageDirectory>/targetID and sent with the initial and all subsequent RegisterTarget requests. With the introduction of aliases in BeeGFS 8 this string ID is no longer used and ignored by the mgmtd, but we left it in the network messages in case we wanted to repurpose it later without breaking the network protocol.

The proposal is to rename/repurpose the targetID field sent with the RegisterTargetMsg as a new registrationToken field that is recorded in the mgmtd database and checked when nodes (re)register targets, so we can detect and prevent misconfigurations where the same numeric ID is accidentally reused for multiple storage targets.

We can also implement a similar check to prevent duplicate node (re)registrations. The RegisterNodeMsg has a similar unused nodeID field that could be renamed/repurposed as a registrationToken field. We just need to update the meta and storage nodes to generate a similar token stored on-disk and sent with the RegisterNodeMsg.

All this can be done in a backwards compatible way since the registration messages don't need to change. If the registrationToken is not present it is simply ignored by the mgmtd, otherwise it is recorded and enforced from that point onwards.