With the current implementation of singleton clustering service it providers two notification for a entity - instantiateServiceInstance() & closeServiceInstance(). So whenever an entity is unregistered, it will call the closeServiceInstance(), so that the application instance can do the cleanup. We encountered an issue with openflowplugin clustering that can't be solve using these existing two notifications. Assume a scenario, where a device is connected to only one controller, so that specific controller will register that device as an entity and get the ownership. If this controller dies, other nodes in the cluster won't get any notification about the status of that device entity , because they are not registered candidate. So all the data written by owner controller to data store will be remain there.
EntityOwnershipService do notify the non-candidate nodes if any entity don't have any owner (isOwner=false, wasOwner=false,hasOwner=false). To resolve the above mentioned issue i think singleton service should expose new notification (e.g noOwnerFound() or noOwnerElected()) that will get triggered in the scenario (isOwner=false, wasOwner=false,hasOwner=false), so that other controllers can do the required clean-up. Currently openflowplugin clustering is pretty much broken because we encountered two issue that can't be solve using singleton clustering without having a notification similar to what i mentioned above.
We are planning to explore on using EOS ownership change listener with singleton clustering service to resolve these issues, but if that doesn't work, this bug is pretty much a blocker bug for us.
Please let me know if you need more details to clearly understand the issue.
- relates to
-
OPNFLWPLUG-1072 ContextChainHolderImpl encroaches on Cluster Singleton Service internals
- Confirmed
-
MDSAL-465 Revise Cluster Singleton API
- Confirmed