> It really isn't necessary that the new owner stays the same
For some applications it does not matter. For other applications (such as openflow) each owner change means the old owner has to disconnect from the device and the new owner has to connect. That can be expensive, and in worst case it can lead to data loss. > I'm not sure if it's guaranteed the owner won't change after > re-join I know this test happened to work when we developed it, but that behavior might depend on timing details of an underlying algorithm implementation. For curiosity, I looked at unit tests. I have not found anything conclusive, but I found one comment [0] related to timing. Vratko. [0] https://github.com/opendaylight/controller/blob/9bce68c4712d00951d121be68b09578bc6e09151/opendaylight/md-sal/sal-distributed-datastore/src/test/java/org/opendaylight/controller/cluster/datastore/entityownership/DistributedEntityOwnershipIntegrationTest.java#L224-L226 ________________________________ From: Jamo Luhrsen <jluhr...@gmail.com> Sent: Thursday, September 20, 2018 7:45:12 AM To: Tom Pantelis Cc: controller-dev; pgup...@cisco.com; Vratko Polák Subject: Re: owner changed failure On 09/19/2018 02:36 PM, Tom Pantelis wrote: > > > On Wed, Sep 19, 2018 at 4:46 PM Jamo Luhrsen <jluhr...@gmail.com > <mailto:jluhr...@gmail.com>> wrote: > > \ > > Anyway we'll need to enable debug for > org.opendaylight.controller.cluster.datastore.entityownership. I would > suggest to > > pull out that test on its own like you've done before (run it > standalone in sandbox I guess). Also delete the log > files > > in between each run. This will make debugging much easier. > > Is there not enough info in the existing logs? > > > No - not with the default INFO logging. In order to dig deeper we need to > enable targeted debug, in this > case org.opendaylight.controller.cluster.datastore.entityownership. I don't think it worked. Here is what the logger config lines looked like: 22:38:53 log4j2.logger.org_opendaylight_org_opendaylight_controller_cluster_datastore_entityownership.name = org.opendaylight.org.opendaylight.controller.cluster.datastore.entityownership 22:38:53 log4j2.logger.org_opendaylight_org_opendaylight_controller_cluster_datastore_entityownership.level = DEBUG you can see the whole org.ops4j.pax.logging.cfg file here: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-ask-all-oxygen/3/console-timestamp.log.gz but, I don't see any DEBUG messages showing up in these karaf logs: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-ask-all-oxygen/3/odl_1/odl1_karaf.log.gz https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-ask-all-oxygen/3/odl_2/odl2_karaf.log.gz https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/controller-csit-3node-clustering-ask-all-oxygen/3/odl_3/odl3_karaf.log.gz > You can easily trim the > karaf logs based on the test cases. We are logging the start of every > suite and test case. > > > I think it's much easier and faster to debug a failing test if it's > isolated. Of course the logs are much smaller and > don't require trimming. Enabling debug can result in huge logs even just > running one test, let alone the whole batch of > them. Also I assume this test fails sporadically which means it needs to be > run over and over. Doing that with the > entire job will take a long time. But if it's too much of a pain to isolate > the test, then OK. The suite takes aprox 90 from start to finish and it's just a matter of adding a single string to the parameters when we start the build. This failure has happened 2 of the 3 jobs we ran. That's easiest for now, and splitting up the karaf logs after the fact shouldn't be too bad. Thanks, JamO
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
