[OPNFLWPLUG-1072] ContextChainHolderImpl encroaches on Cluster Singleton Service internals Created: 06/Jun/19 Updated: 05/Sep/19 |
|
| Status: | Confirmed |
| Project: | OpenFlowPlugin |
| Component/s: | clustering |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | High |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Description |
|
ever since https://git.opendaylight.org/gerrit/#/c/54304/3/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/lifecycle/ContextChainHolderImpl.java, OFP is is registering on internals of how Cluster Singleton Service is operating, without ever properly checking if the changes are really relevant to OFP, breaking encapsulation. I am not sure why this was even done, but the registration must be eliminated, i.e. OFP must not reference private static final String ASYNC_SERVICE_ENTITY_TYPE = "org.opendaylight.mdsal.AsyncServiceCloseEntityType"; |
| Comments |
| Comment by Anil Vishnoi [ 28/Jun/19 ] |
|
Main reason for this workaround is following two improvement/bugs that been reported to MDSAL for a while https://jira.opendaylight.org/browse/MDSAL-231 https://jira.opendaylight.org/browse/MDSAL-274 Because of these limitation of Cluster Singleton we had to live with this workaround. Given that most of the codebase was moved to Cluster Singleton at that time and we were registering each device with Cluster Singleton API, we had to hack into the internal to listen to the existing device cluster singleton entity, rather than creating parallel new EOS entity for the device and managing the nightmare of device status across Cluster Singleton and EOS. Now I am not really in an opinion that MDSAL-231 and MDSAL-274 are really limitation of Cluster Singleton, i believe these kind of imrovement should not be pushed to Cluster Singleton as it's being designed for applications where you assume that instance will run on single controller and not for the devices that actually can be connected to multiple controller (1 or more) in active/standby. So to fix these issues properly we will move back to EOS from Cluster Singleton and that will tentatively happen in Magnesium release. |