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-1111 OpenFlowPlugin <p>curl -u admin:admin <a href="http://192.168.0.5:8181/diagstatus" class="external-link" target="_blank" rel="nofollow noopener">http://192.168.0.5:8181/diagstatus</a> shows openflowplugin wasn't up successfully, here are some error information.</p> <p>"statusSummary": [</p> { "serviceName": "OPENFLOW", "effectiveStatus": "ERROR", "reportedStatusDescription": "OF::PORTS:: 6653 and 6633 are not up yet", "statusTimestamp": "2019-03-04T01:54:44.411Z", "errorCause": "" } <p>,</p> <p>Opendaylight Fluorine SR1 + Openstack Rocky</p> OPNFLWPLUG-1111

controller (openflowplugin) failed to initialize because of dependency issue

Bug High Open Unresolved Unassigned Yi Yang csit:3node Sun, 5 May 2019 00:09:06 +0000 Mon, 19 Jul 2021 15:54:38 +0000 clustering 0 2 <p>Please refer to <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-1065" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/OPNFLWPLUG-1065</a> for more info.</p> <p>I am not sure what I should be looking for: the cluster seems not to have been bootstrapped correctly, i.e. the first node joined on self. How is the cluster being bootstrapped?</p> <p>Robert, sorry, I re-assigned it to you, it is indeed controller clustering issue, let me recap it here.</p> <p>This is a cluster setup, it is ok at the beginning, l2.robot in <a href="https://git.opendaylight.org/gerrit/p/integration/test.git" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/p/integration/test.git</a> test can reproduce this issue very easily because it is torturing it (stop member 1, write data store, start member 1, stop member 2, write data store, start member 2, the issue is there), it is data sync issue I think, so yes, member 2 can't be restarted because of this.</p> <p>Can you explain why it isn't clustering issue? Or you can reassign it to Abhijit, let TSC chairman assign it to somebody.</p> <p>Sam, Jamo and Tom have explained this issue to me, please draft a detailed guide about how one application should use MDSAL APIs to strictly follow clustering requirements if you think it is application-related issue, otherwise I don't think one application can result in such issue, can we have a tool/script to check if all MDSAL applications in ODL have strictly followed clustering requirements? I believe this is an critical issue, please don't ignore it, nobody knows about clustering more clearly than you. I know applications need to use some strict APIs to make sure clustering can work correctly per Tom's explanation, but please do let us know which APIs applications can use and which APIs applications can't use for cluster.</p> <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=yangyi01" class="user-hover" rel="yangyi01">yangyi01</a> I do not see answer to question raised here: <a href="https://jira.opendaylight.org/browse/OPNFLWPLUG-1065?focusedCommentId=66521&amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-66521" class="external-link" rel="nofollow">https://jira.opendaylight.org/browse/OPNFLWPLUG-1065?focusedCommentId=66521&amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-66521</a></p> <p>I am sorry, but I just cannot analyze the entire application stack, but certainly timeouts waiting for a service and giving up on them in some bounded time, without ever going back are a problem.</p> <p> </p> <p>At the end of the day, this boils down to reproducing the issue, with all three nodes, with exact knowledge of what actions were made at which precise moments in the environment. I know next to nothing about RF, nor netvirt, hence a pointer to robot is just not enough to send me after a wild goose chase across the entire stack to pin down who is doing what.</p> Development Epic Link NETVIRT-996 Priority Rank 0|i03nnj: