Opendaylight Fluorine SR1 + Openstack Rocky

Please refer to https://jira.opendaylight.org/browse/OPNFLWPLUG-1065 for more info.

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?

Robert, sorry, I re-assigned it to you, it is indeed controller clustering issue, let me recap it here.

This is a cluster setup, it is ok at the beginning, l2.robot in https://git.opendaylight.org/gerrit/p/integration/test.git 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.

Can you explain why it isn't clustering issue? Or you can reassign it to Abhijit, let TSC chairman assign it to somebody.

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.

yangyi01 I do not see answer to question raised here: https://jira.opendaylight.org/browse/OPNFLWPLUG-1065?focusedCommentId=66521&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-66521

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.

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.