Hi, Following up on the OAK-3672 discussion again, and taking a step back, I see three possible classes of solutions:
a) the (cluster)id is always defined by discovery-lite, be it cluster or singlevm b) the (cluster)id is entirely removed and it is up to discovery.oak (in sling) to define it c) the (cluster)id is only set by discovery-lite when feasible, eg only for the cluster case I'm in favour of c) with the following arguments: * a) requires tarMk (!) to store this id somewhere. It can either store it in the filesystem (which makes failover support harder), store it as a hidden property in the node store (which is not manageable as it's hidden) or store it as a normal property in the repository (which sounds hacky, as discovery-lite is in the NodeStore layer while this would require it to simulate writing a JCR property) * removing the id altogether (b) would be going too far imv: the logical unit that defines the cluster view (its members) is the best place to also define an id for that unit. And that logical unit is discovery-lite in this case. * what speaks for returning null for the singleVm case (c) is the fact that it is a special case (it is not a cluster). So treating the special case separately doesn't break the separation of concern rule in my view. (c) would imply that the id is set when we're in a cluster case, and not otherwise (but that would not be a hard requirement, the specification would just be that the id *can* be null). So long story short: I suggest to change the definition of this id so that it *can* be null - in which case upper layers must define their own id. Which means Sling's discovery.oak would then store a clusterId under /var/discovery/oak. That would automatically support cold-standby/failover - fix the original bug - and simplify cleaning this property up for the clone case (as that would correspond to how this case was dealt with in discovery.impl times already). WDYT? Cheers, Stefan On 26/11/15 11:32, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote: >On Thu, Nov 26, 2015 at 3:56 PM, Stefan Egli <e...@adobe.com> wrote: >> which would >> then be on the Sling level thus could more simply use the slingId. > >That also sounds good. While we are at it also have a look at OAK-3529 >where system needs to know a clusterId. Looks like some overlap so >keep that usecase also in mind > > >Chetan Mehrotra
