Hi TSC members, Please vote on the following page: "Vote for Projects Under TSC Purview" (if you cannot see the link - please use https://wiki.lfnetworking.org/x/TQCkAQ). This vote is for the TSC

Hi Eric, I recall the old sonar system has the "ODL Sonar Way" or something profile. Can we not redo that profile in SonarCloud? I believe that profile was crafted by the community over the years of

cc the dev list as this is open to anybody.

Hi all, Following is the time availability for different TZs https://www.timeanddate.com/worldclock/meetingtime.html?iso=20191209&p1=438&p2=283&p3=735 Here is a doodle poll we can use to cite your

To gain access, you'll need to log into Sonarcloud.io using a Github account. If your Github account is already a member of the github.com/opendaylight org, you'll immediately have access to the

Okay, so what is the process to gain access? We have the controller being analyzed and the number of utterly false positives is not funny and I have no way to close them down. Two

Yup, exactly. Thanks, Robert

OK guys, back to the issue, I figured out that 2 things are adding: one is the -all- test, the other one is the JVM monitoring (the JMX collector is bundle getting stuck). So I think we can disable

Next TSC meeting is tomorrow Dec 5, 2019 at 9 am Pacific Time. Agenda for this meeting is at: https://wiki.lfnetworking.org/x/HQeDAQ If you need to add anything, please let me know or feel free to add

Do you guys want this on tomorrow's TSC call or do you want to continue over email?

I think it's this easy: https://git.opendaylight.org/gerrit/c/releng/builder/+/86191 I think we made these decisions to run jobs with -all- so we can just accidentally get the extra coverage without

Yeah, that depends on how easy it is to achieve in RF (if it were Java, it would be a simple superclass/subclass with specialized step). The problem is two-fold: 1) it does not make sense for

is it worth the overhead? We can easily do that, but we just end up with duplicate jobs taking resources. I think we sort of quickly started to narrow this problem down with just the jobs we

Agreed. Can we fork/subclass (sorry, I am an RF n00b) the test, so that we have two test suites to run against autorelease: 1) controller-only, which does the wiping & all 2) everything, which uses

Yes, it is better to let it finish and look at the logs before getting into any conclusion. Also there is a timeout of 5 mins to boot up that can be expanded if we do not find useful information.

It actually works with only controller features: https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-3node-clustering-ask-all-neon/416/ I guess the -all- was set to detect

Actually: would seem to indicate OFP... Regards, Robert

Can you try running it with org.opendaylight.ovsdb=DEBUG to see if anything crops up? Thanks, Robert

Thinking about this a bit more, this test suite was designed to test controller.git only, i.e. not with all features (it does not integrate with ready service for example). I also think 'Restart Odl

That is what I tried with this patch: https://git.opendaylight.org/gerrit/#/c/integration/test/+/86190/ And this