[CONTROLLER-1492] Milestone: Cluster-wide service management Created: 24/Feb/16  Updated: 25/Jul/23  Due: 02/Jun/16  Resolved: 25/Jul/16

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Robert Varga Assignee: Vaclav Demcak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: PDF File Cluster-wideServiceMng.pdf    
Issue Links:
Blocks
blocks BGPCEP-429 BGP clustering: singleton app deployment Resolved
blocks OPNFLWPLUG-659 Milestone: integrate with Singleton a... Resolved
blocks OPNFLWPLUG-725 FRsync – integrate with single cluste... Resolved
is blocked by CONTROLLER-1488 EntityOwnershipListener missing owner... Resolved
External issue ID: 5421

 Description   

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.

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).

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).

 Comments   
Comment by Vaclav Demcak [ 25/Apr/16 ]

https://git.opendaylight.org/gerrit/#/c/37957

Comment by Muthukumaran Kothandaraman [ 04/May/16 ]

I had following clarifications from the applications developer perspective

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 ?

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.

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 ?

Comment by Vaclav Demcak [ 28/Jun/16 ]

Attachment Cluster-wideServiceMng.pdf has been added with description: adoc in pdf (adoc is a part of commit)

Comment by Vaclav Demcak [ 30/Jun/16 ]

https://git.opendaylight.org/gerrit/#/c/40858/
https://git.opendaylight.org/gerrit/#/c/40859/
https://git.opendaylight.org/gerrit/#/c/37957/

Comment by Vaclav Demcak [ 01/Jul/16 ]

(In reply to Muthukumaran Kothandaraman from comment #2)
> I had following clarifications from the applications developer perspective
>
> 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 ?
Yes, ClusteredDataTreeChangeListener is recommended to use with ClusterSingletonServiceProvider for apps.
>
> 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.
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.
>
> 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 ?
Please look at org.opendaylight.controller.sal.binding.api.RpcProviderRegistry#addRoutedRpcImplementation API contract.

Comment by Muthukumaran Kothandaraman [ 12/Jul/16 ]

(In reply to Vaclav Demcak from comment #5)
> (In reply to Muthukumaran Kothandaraman from comment #2)
> > I had following clarifications from the applications developer perspective
> >
> > 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 ?
> Yes, ClusteredDataTreeChangeListener is recommended to use with
> ClusterSingletonServiceProvider for apps.
> >
> > 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.
> 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.
> >
> > 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 ?
> Please look at
> org.opendaylight.controller.sal.binding.api.
> RpcProviderRegistry#addRoutedRpcImplementation API contract.

Hi Vaclav,

Regarding point (3), what would be the route-key in case of clusterwide singletons ?

Regards
Muthu

Generated at Wed Feb 07 19:55:41 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.