Same goes for 4c-16g slaves: https://jenkins.opendaylight.org/releng/label/centos7-autorelease-4c-16g/load-statistics which means autorelease-sodium-openjdk11 #40 has been sitting there for more

Same goes for 4c-16g slaves: https://jenkins.opendaylight.org/releng/label/centos7-autorelease-4c-16g/load-statistics which means autorelease-sodium-openjdk11 #40 has been sitting there for more

Hello, it seems our cloud is experiencing issues: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-maven-verify-sodium-mvn35-openjdk8/30/console.log.gz: Furthermore: 1) we do not

Doh, https://git.opendaylight.org/gerrit/80810 Regards, Robert

With this, Hema will be the new PTL for Genius. Congrats Hema! I will update the wiki accordingly. FYI, TSC. Thanks, Faseela

FYI I also opened this bug, it does not seem to impact functionality but it floods the log when there many RIB entries (e.g. scale test): https://jira.opendaylight.org/browse/BGPCEP-869 BR/Luis

Great. Thanks for the info.

I think so, AR #55 should be good to go AFAICT. Bye, Robert

So we're down to these two issues: I don't think this is a blocker, as it should not affect real functionality -- extra EOR is a NOOP if I remember correctly. We can punt this to SR1. As mentioned

So - are we good to go from BGPCEP side?

Yes, issue #4 is fixed by https://git.opendaylight.org/gerrit/#/c/80796/, as that shortens the capability sufficiently to fit into 255 bytes. Long-term fix is tracked here:

According to this: https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/bgpcep-csit-1node-gate-userfeatures-all-neon/14/robot-plugin/log.html.gz#s1-s16 Patch

Sure I just triggered CSIT for the unmerged patches.

Alright, I think we have all the patches lined up, some (https://git.opendaylight.org/gerrit/#/q/status:merged+project:bgpcep+branch:stable/neon) are already merged. Luis, can you give

Nevermind that, the calculation is right, but the length actually works out to be greater than 255 (note how the OPEN message is 336 bytes) and hence "51" really wants to say

That is odd, I cannot quite wrap my mind around where we are losing those three bytes. Can you re-run with org.opendaylight.protocol.bgp.parser.impl.message.open set to TRACE, please? Thanks, Robert

Yeah, after looking at the wire trace I think ODL is setting the wrong length: - Optional parameters length should be 54 vs 51 - Capability parameter length should be 52 vs 49 BR/Luis

This is the log on the ExaBGP side, I also attach wireshark trace (.1 is controller, .20 is ExaBGP): Tue, 12 Mar 2019 02:53:05 | DEBUG | 4819 | wire | Attempting connection to

Yeah, this is one the test does not store the ExaBGP output so I will have to try manually in my setup. I will do that today.

[snip] This one is beyond my robot-fu. Where can I find the exabgp output? is it stored somewhere in robot? Thanks, Robert