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

["Davide Giannella (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davide Giannella closed OAK-4006.
---------------------------------

Bulk close for 1.3.16

> Enable cloning of repo for shared data store and discovery-lite
> ---------------------------------------------------------------
>
>                 Key: OAK-4006
>                 URL: https://issues.apache.org/jira/browse/OAK-4006
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.3.15
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>            Priority: Blocker
>             Fix For: 1.3.16
>
>         Attachments: OAK-4006.patch.v1.txt, OAK-4006.patch.v2.txt
>
>
> 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|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/identifier/ClusterRepositoryInfo.java].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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)