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

Actually, we do, but let's first take a look, this instance was started here: so it was given less than five minutes to boot up before it was terminated. It is a pity, too, because the system just

yeah, you're right. I was looking at the timestamp when it gave up checking if it was stopped. here's the call to

The stop started before: 2019-12-04T16:15:57,404 | INFO | Karaf Shutdown Socket Thread | ShutdownSocketThread | - - | Karaf shutdown socket: received shutdown command. Stopping

On 12/4/19 10:11 AM, Robert Varga wrote: I think it took like 30m to finally stop. here's the karaf.log:

Looks like stopping Karaf is

I am not sure if anyone realized but it seems there is some issue stopping nodes in cluster after last MRI

Hi all, I think we are losing some momentum to get something done in this release. Let me comment on the questions that are blocking this project: 1) Relationship with other projects I do not

Congratulations Abhijit. George