A source job currently maintains a single set of zrepl ZFS abstractions and does not encode the client identity of the pulling side into these abstractions.

Multiple concurrent pull jobs would thus be data-racing on these ZFS abstractions.

Analysis / Design

• Encode the client identity in the zrepl ZFS abstractions. This must be done
  • optionally because not all jobs need to do this / have a client identity at hand
  • in a backwards-compatible way
• zrepl zfs-abstraction subcommand needs a flag to select by client identity
  • deleting a client identity by that flag should be fairly easy
  • How do we deal with renaming of a client identity? Probably ok to tell the user they need to run a replication with the new client identity, then manually delete the old one?

Impl Notes / Ideas

With regards to encoding the client identity into the ZFS abstraction name:

• most code that currently deals with (JobID, Filesystem) will have to be expanded to (JobID, Filesystem, Option<ClientIdentity>)
• job's that don't have the client identity would always set the latter to None
• "" is not a valid client identity anyway (check that we assert that somewhere!)
• => declare "" to be the empty client identity
• encoding in the varios names: zrepl_ABSTRACTIONKIND_G_<GUID>_J_<JOBNAME>(_C_<CLIENTIDENTITY>)?
  • consideration 1: max name length? => zfs entity namecheck
  • consideration 2: unambiguous parsing of previous abstractions possible? JOBNAME could contain _C_
    • prohibit _C_ in JOBNAME?
    • use an already forbidden character instead of _C_ as a separator?
    • if we decide to limit ourselves again, maybe directly jump to requiring dns-name compatiblity or sth equally restrictive