<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:33:32 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[OPNFLWPLUG-848] controllers with no connectivity with the switch gets device ownership</title>
                <link>https://jira.opendaylight.org/browse/OPNFLWPLUG-848</link>
                <project id="10155" key="OPNFLWPLUG">OpenFlowPlugin</project>
                    <description>&lt;p&gt;When a switch connects to a controller, it register a register cluster singleton service and MDSAL clustering gives ownership to one of the controllers.&lt;/p&gt;

&lt;p&gt;All controllers are registered as candidates, so if all controllers that contains a valid connections to the switch are rebooted, then another controller which does not have a connection gets the ownerships.&lt;/p&gt;

&lt;p&gt;Reproducing this error is very straight forward. &lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;create a 3 nodes BSC cluster (node A, node B, node C)&lt;/li&gt;
	&lt;li&gt;connect a Openflow switch only to 2 controllers (node A, node B)&lt;/li&gt;
	&lt;li&gt;restart node A and node B&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;The ownership of the switch will move to node C. When node A and/or node B are active again with valid Openflow sessions, the ownership does not move to one of the controllers with an active connection.&lt;/p&gt;


&lt;p&gt;Making a HTTP GET to clustering service http://&lt;tt&gt;bsc&lt;/tt&gt;:8181/restconf/operational/entity-owners:entity-owners before restarting a any controller will show that all 3 controllers are &quot;candidates&quot; for the switch even though only two have valid connections.&lt;/p&gt;


&lt;p&gt;For example,&lt;/p&gt;

&lt;p&gt;        {&lt;br/&gt;
            &quot;id&quot;: &quot;/odl-general-entity:entity&lt;span class=&quot;error&quot;&gt;&amp;#91;odl-general-entity:name=&amp;#39;openflow:100&amp;#39;&amp;#93;&lt;/span&gt;&quot;,&lt;br/&gt;
            &quot;candidate&quot;: [&lt;br/&gt;
              &lt;/p&gt;
{
                &quot;name&quot;: &quot;member-3&quot;
              }
&lt;p&gt;,&lt;br/&gt;
              &lt;/p&gt;
{
                &quot;name&quot;: &quot;member-1&quot;
              }
&lt;p&gt;,&lt;/p&gt;
              {
                &quot;name&quot;: &quot;member-2&quot;
              }
&lt;p&gt;            ],&lt;br/&gt;
            &quot;owner&quot;: &quot;member-1&quot;&lt;br/&gt;
          }&lt;/p&gt;


&lt;p&gt;Probably, the source of the problem is that in this example &quot;member-3&quot; is shown as valid candidate but it does not hold any active openflow connection to the switch.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="28116">OPNFLWPLUG-848</key>
            <summary>controllers with no connectivity with the switch gets device ownership</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10000">Done</resolution>
                                        <assignee username="Avishnoi">Anil Vishnoi</assignee>
                                    <reporter username="castro.jon@gmail.com">Jon Castro</reporter>
                        <labels>
                    </labels>
                <created>Sun, 5 Feb 2017 22:19:48 +0000</created>
                <updated>Mon, 27 Sep 2021 09:01:59 +0000</updated>
                            <resolved>Thu, 23 Mar 2017 17:48:31 +0000</resolved>
                                                                    <component>General</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                                                                <comments>
                            <comment id="58629" author="castro.jon@gmail.com" created="Mon, 6 Feb 2017 02:05:15 +0000"  >&lt;p&gt;Openflow plugin consumes clustering singleton service. It seems, MDSAL clustering singleton service adds all controllers as candidates, independently if controllers registers to the service or not. So, if just one controller creates a service all controllers will appear as candidate.&lt;/p&gt;</comment>
                            <comment id="58630" author="castro.jon@gmail.com" created="Mon, 6 Feb 2017 03:14:07 +0000"  >&lt;p&gt;(In reply to Jon Castro from comment #1)&lt;br/&gt;
&amp;gt; Openflow plugin consumes clustering singleton service. It seems, MDSAL&lt;br/&gt;
&amp;gt; clustering singleton service adds all controllers as candidates,&lt;br/&gt;
&amp;gt; independently if controllers registers to the service or not. So, if just&lt;br/&gt;
&amp;gt; one controller creates a service all controllers will appear as candidate.&lt;/p&gt;

&lt;p&gt;discard my previous comment. The source of the problem is that there are two classes that register the cluster singleton service.&lt;/p&gt;

&lt;ul class=&quot;alternate&quot; type=&quot;square&quot;&gt;
	&lt;li&gt;DeviceMastership&lt;/li&gt;
	&lt;li&gt;LifecycleServiceImpl&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;My first guess is that DeviceMastership class should not register the clustering singleton service because LifecycleServiceImpl is the one that knows when the connection to the switch is opened or closed.&lt;/p&gt;</comment>
                            <comment id="58631" author="castro.jon@gmail.com" created="Mon, 6 Feb 2017 23:45:02 +0000"  >&lt;p&gt;Gerrit proposed change:&lt;/p&gt;

&lt;p&gt;Both DeviceMastership and LifecycleServiceImpl cannot use the same cluster singleton name. In the following change we change the cluster singleton name used by DeviceMastership to openflow:&amp;lt;id&amp;gt;:frm&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/51489/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/51489/&lt;/a&gt;&lt;/p&gt;


&lt;p&gt;If the intent of forwarding rules manager is to be mounted in the same controller is that contains mastership to the switch, then, it will require more changes like tracking cluster status for the switch.&lt;/p&gt;</comment>
                            <comment id="58632" author="vishnoianil@gmail.com" created="Sat, 11 Feb 2017 00:01:44 +0000"  >&lt;p&gt;Using the same cluster singleton id is intention, because we want FRM to run locally on the same controller instance that owns the device. It&apos;s been done in this way to use the local rpc registration and avoid routing of the rpc call to other controller. Although this patch fixes the problem, but it enables the routing of rpc call from the frm owner instance to device owner instance (when frm and device owner is different). Routed rpc&apos;s adds the latency in flow installation and will create performance issue in the clustered environment. The root cause of this problem lies in FRM clustering registration. Currently FRM does the clustering registration based on the data store change event of the node addition, but this notification goes to all the controller instances and FRM on all the controller nodes ends up registering for the ownership. Ideally FRM should only register on the instance where device is connected. In my personal opinion, this is a bug in the singleton clustering implementation. It should throw the error while registration if they see the registration is happening on the node where other services didn&apos;t register. I also see that it&apos;s not easy to implement this at the clustering service level. We need to fix the FRM registration to get the correct behavior. I will push a patch with the correct fix.&lt;/p&gt;</comment>
                            <comment id="58633" author="abhijit2511" created="Thu, 23 Feb 2017 16:52:53 +0000"  >&lt;p&gt;Anil to move the patch to master and then close it.&lt;/p&gt;</comment>
                            <comment id="58634" author="ecelgp" created="Thu, 23 Feb 2017 18:10:13 +0000"  >&lt;p&gt;Let me know when this is in master so I can adjust the system test for Boron/Carbon at once.&lt;/p&gt;</comment>
                            <comment id="58635" author="vishnoianil@gmail.com" created="Thu, 23 Feb 2017 19:49:25 +0000"  >&lt;p&gt;Master : &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/52225/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/52225/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Luis above patch is for master branch, so now you can fix the CSIT tests.&lt;/p&gt;</comment>
                            <comment id="58636" author="vishnoianil@gmail.com" created="Thu, 23 Feb 2017 19:49:51 +0000"  >&lt;p&gt;Stable/boron : &lt;a href=&quot;https://git.opendaylight.org/gerrit/#/c/51489/7&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://git.opendaylight.org/gerrit/#/c/51489/7&lt;/a&gt;&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7736</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=7736]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10206" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Issue Type</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10300"><![CDATA[Bug]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i033on:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>