[OAK-4006] Enable cloning of repo for shared data store and discovery-lite

• Type: Improvement
• Status: Closed
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 1.3.15
• Fix Version/s: 1.3.16, 1.4
• Component/s: core
• Assignee: Stefan Egli
• Reporter: Stefan Egli
• Created: 11/Feb/16 16:59
• Updated: 08/Oct/19 15:21
• Resolved: 15/Feb/16 15:46

Description

Here is a suggestion how to 'officially' provide a clusterId in oak for all the various use cases that popped up recently: this would avoid OAK-3980, solve OAK-3935 via oak-run, move clusterId from Sling's discovery.oak down (back) to oak (for both tarMk and mongoMk) and make the clusterId available right when the repository is created. The details are suggested as follows:

• ClusterRepositoryInfo.getOrCreateId(NodeStore) is the one guy responsible in oak for storing and reading the clusterId as a hidden property under /:clusterConfig/:clusterId. Being a hidden property makes this not only hidden but also not editable/changeable by admins, thus no special permission setup is needed and no support for it to change must be implemented (thus avoids problems)
• ClusterRepositoryInfo.resetId(NodeStore) deletes the clusterId if it was set and stores a new one (the only way to ever modify the clusterId)
• oak-run will get a new offline tool that invokes this resetId - and it is this mechanism that will have to be used after cloning a repository to reset the clusterId, there's no other mechanism (as doing it at runtime is critical at many levels). This oak-run offline tool is handled via a separate jira-ticket (so that it can come after 1.3.16).
• in the shared dataStore case ClusterRepositoryInfo.getOrCreateId would be used to get the clusterId. The clusterId is available immediately (as this is invoked when the NodeStore is available). This would avoid the concern with OAK-3935 that discovery's clusterId is not immediately available. It would also avoid the trick that would be necessary when doing OAK-3980.
• ContentRepositoryImpl.createDescriptors adds a new descriptor 'oak.clusterId' by invoking same ClusterRepositoryInfo.getOrCreateId. This will be a new API that allows the clusterId to be used for clients that don't want to go via discovery API and it would be never null (which discovery API doesn't guarantee as it might wait for the first sync/vote before it can send TOPOLOGY_INIT).
• discovery-lite (namely DocumentDiscoveryLiteService and SegmentDiscoveryLiteService) both also use this clusterId (via ClusterRepositoryInfo.getOrCreateId) and expose this in their own repository descriptor 'oak.discoverylite.clusterview'. This results in discovery.oak (which sits in Sling) to also use this new clusterId of oak as the discovery API clusterId. Which allows discovery.oak to not store a clusterId under /var/discovery/oak.

As a result we'll have one clusterId in both oak and discovery, it will be immediately available internally in oak(-core) plus via a repository descriptor, it can only be reset offline via a dedicated oak-run tool and it will be reused in discovery-lite thus also discovery.oak. Its semantics are: it is persistent, unique as long as you reset it via oak-run if you ever fork a repository.

Issue Links

• is related to: OAK-4007 "reset clusterId tool" in oak-run