Storage Syncer

The Syncer service runs (typically) in the cloud and is responsible for ensuring that all storages assigned to each container are in-sync. This can sometimes be referred to as the "Storage Invariant" in the docs.

Syncer is expected to be a specific example of a "forest machinery", i.e. a cloud service which mounts and operates on a user forest.

It is expected that the user encrypts their container manifests in such a way, that the Syncer is not able to read anything beyond the storage backend sections, such as e.g. container paths, content encryption keys, and other metadata information.

In a typical scenario, we envision that the CargoLib will setup proper encryption for the Syncer process(es), obtaining a dedicated Syncer key.

Changes compared to the Legacy Wildland

• Legacy core had not been designed with the assumption that syncing could be done externally to the (full) client instance,
• Legacy core implemented syncing within the core itself, not as an external module,
• The non-modular nature of the legacy core prevented convenient deployment of the core within the cloud (e.g. due to FUSE requiring a privileged docker),
• Legacy core has no provision to encrypt the metadata-carrying part of the manifest in a way inaccessible to the syncer.