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/OPNFLWPLUG-1072 OpenFlowPlugin <p>ever since <a href="https://git.opendaylight.org/gerrit/#/c/54304/3/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/lifecycle/ContextChainHolderImpl.java" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/54304/3/openflowplugin-impl/src/main/java/org/opendaylight/openflowplugin/impl/lifecycle/ContextChainHolderImpl.java</a>, 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.</p> <p>I am not sure why this was even done, but the registration must be eliminated, i.e. OFP must not reference</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">private</span> <span class="code-keyword">static</span> <span class="code-keyword">final</span> <span class="code-object">String</span> ASYNC_SERVICE_ENTITY_TYPE = <span class="code-quote">"org.opendaylight.mdsal.AsyncServiceCloseEntityType"</span>; </pre> </div></div> OPNFLWPLUG-1072

ContextChainHolderImpl encroaches on Cluster Singleton Service internals

Bug High Confirmed Unresolved Unassigned Robert Varga Thu, 6 Jun 2019 15:02:48 +0000 Thu, 5 Sep 2019 16:27:56 +0000 clustering 0 3 <p>Main reason for this workaround is following two improvement/bugs that been reported to MDSAL for a while </p> <p><a href="https://jira.opendaylight.org/browse/MDSAL-231" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/MDSAL-231</a></p> <p><a href="https://jira.opendaylight.org/browse/MDSAL-274" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/MDSAL-274</a></p> <p>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.</p> <p>Now I am not really in an opinion that <a href="https://jira.opendaylight.org/browse/MDSAL-231" title="Singleton Clustering : No notification to cluster nodes if the entity don&#39;t have any owner" class="issue-link" data-issue-key="MDSAL-231">MDSAL-231</a> and <a href="https://jira.opendaylight.org/browse/MDSAL-274" title="Singleton Clustering : No way for non-candidate to check if ServiceInstance in other member is active" class="issue-link" data-issue-key="MDSAL-274">MDSAL-274</a> 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.</p> Blocks MDSAL-274 Relates CONTROLLER-1900 MDSAL-231 Development Rank 0|i03o4v: