https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1492 controller <p>Our current deployment model assumes symmetric clusters, where all services are activated on all nodes and application developers have to deal with deciding which service is actually alive especially in the (common) scenario, where centralized data processing is required.</p> <p>A typical example is OpenFlow Topology Manager, which needs to talk to all OF switches connected to a cluster and make sense of how they are connected. Such a service typically needs only a failover capability, e.g. ensuring the service runs in the cluster (or its surviving partition).</p> <p>Forcing all such applications to interact with EOS is an overkill, as they will end up producing essentially-equivalent code all over the ecosystem, with each copy having different issues (because reliable clustering is hard).</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1492

Milestone: Cluster-wide service management

Bug Resolved Done Vaclav Demcak Robert Varga Wed, 24 Feb 2016 17:23:42 +0000 Tue, 25 Jul 2023 08:24:07 +0000 Mon, 25 Jul 2016 11:51:39 +0000 clustering Thu, 2 Jun 2016 00:00:00 +0000 0 3 <p><a href="https://git.opendaylight.org/gerrit/#/c/37957" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/37957</a></p> <p>I had following clarifications from the applications developer perspective</p> <p>1. If a clusterwide singleton app has a DataTreeChangeListener for a specific data-path and the app is located in a non-shard leader node, how DTCNs (DataTreeChangeNotification) would be delivered ? Or is it mandatory that singleton apps are recommended to use ClusteredDataTreeChangeListener in official 3-node cluster configuration ?</p> <p>2. Since apps can "move" around in cluster (to ensure one instance is incarnated in new node when erstwhile residential node of app goes down), it would become imperative that the apps must not store any "local" state of its own. One exclusion could be the case rebuilding state from datastore (but (1) above must be taken care of). Of course, this cannot be enforced by framework. But this must be a recommendation for app developers using this service. </p> <p>3. In principle, can singletons expose service RPCs which can be "remotely" accessed from other nodes ? This pattern could pose scale challenges. But, would this support be there at all ?</p> <p>Attachment Cluster-wideServiceMng.pdf has been added with description: adoc in pdf (adoc is a part of commit)</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/40858/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/40858/</a><br/> <a href="https://git.opendaylight.org/gerrit/#/c/40859/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/40859/</a><br/> <a href="https://git.opendaylight.org/gerrit/#/c/37957/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/37957/</a></p> <p>(In reply to Muthukumaran Kothandaraman from comment #2)<br/> &gt; I had following clarifications from the applications developer perspective<br/> &gt; <br/> &gt; 1. If a clusterwide singleton app has a DataTreeChangeListener for a<br/> &gt; specific data-path and the app is located in a non-shard leader node, how<br/> &gt; DTCNs (DataTreeChangeNotification) would be delivered ? Or is it mandatory<br/> &gt; that singleton apps are recommended to use ClusteredDataTreeChangeListener<br/> &gt; in official 3-node cluster configuration ?<br/> Yes, ClusteredDataTreeChangeListener is recommended to use with ClusterSingletonServiceProvider for apps.<br/> &gt; <br/> &gt; 2. Since apps can "move" around in cluster (to ensure one instance is<br/> &gt; incarnated in new node when erstwhile residential node of app goes down), it<br/> &gt; would become imperative that the apps must not store any "local" state of<br/> &gt; its own. One exclusion could be the case rebuilding state from datastore<br/> &gt; (but (1) above must be taken care of). Of course, this cannot be enforced by<br/> &gt; framework. But this must be a recommendation for app developers using this<br/> &gt; service. <br/> I'm not sure what scenario you are talking about. Local state is app's problem. We can talk about Distributed state only. Lost cluster node connection in cluster is a base scenario which could bring more lights to your mind.<br/> &gt; <br/> &gt; 3. In principle, can singletons expose service RPCs which can be "remotely"<br/> &gt; accessed from other nodes ? This pattern could pose scale challenges. But,<br/> &gt; would this support be there at all ?<br/> Please look at org.opendaylight.controller.sal.binding.api.RpcProviderRegistry#addRoutedRpcImplementation API contract.</p> <p>(In reply to Vaclav Demcak from comment #5)<br/> &gt; (In reply to Muthukumaran Kothandaraman from comment #2)<br/> &gt; &gt; I had following clarifications from the applications developer perspective<br/> &gt; &gt; <br/> &gt; &gt; 1. If a clusterwide singleton app has a DataTreeChangeListener for a<br/> &gt; &gt; specific data-path and the app is located in a non-shard leader node, how<br/> &gt; &gt; DTCNs (DataTreeChangeNotification) would be delivered ? Or is it mandatory<br/> &gt; &gt; that singleton apps are recommended to use ClusteredDataTreeChangeListener<br/> &gt; &gt; in official 3-node cluster configuration ?<br/> &gt; Yes, ClusteredDataTreeChangeListener is recommended to use with<br/> &gt; ClusterSingletonServiceProvider for apps.<br/> &gt; &gt; <br/> &gt; &gt; 2. Since apps can "move" around in cluster (to ensure one instance is<br/> &gt; &gt; incarnated in new node when erstwhile residential node of app goes down), it<br/> &gt; &gt; would become imperative that the apps must not store any "local" state of<br/> &gt; &gt; its own. One exclusion could be the case rebuilding state from datastore<br/> &gt; &gt; (but (1) above must be taken care of). Of course, this cannot be enforced by<br/> &gt; &gt; framework. But this must be a recommendation for app developers using this<br/> &gt; &gt; service. <br/> &gt; I'm not sure what scenario you are talking about. Local state is app's<br/> &gt; problem. We can talk about Distributed state only. Lost cluster node<br/> &gt; connection in cluster is a base scenario which could bring more lights to<br/> &gt; your mind.<br/> &gt; &gt; <br/> &gt; &gt; 3. In principle, can singletons expose service RPCs which can be "remotely"<br/> &gt; &gt; accessed from other nodes ? This pattern could pose scale challenges. But,<br/> &gt; &gt; would this support be there at all ?<br/> &gt; Please look at<br/> &gt; org.opendaylight.controller.sal.binding.api.<br/> &gt; RpcProviderRegistry#addRoutedRpcImplementation API contract.</p> <p>Hi Vaclav, </p> <p>Regarding point (3), what would be the route-key in case of clusterwide singletons ?</p> <p>Regards<br/> Muthu</p> Blocks BGPCEP-429 OPNFLWPLUG-659 OPNFLWPLUG-725 CONTROLLER-1488 Development External issue ID 5421 External issue URL ODL SR Target Milestone Rank 0|i02qwn: