BTW, even when this is a bug fix, the moment it changes the REST API in a non backwards compatible way, I think it needs some talk. As a minimum whether this change is reasonable for a Service Release

OK, int/test changes are merged now.

3 integration/test patches for OpenFlow Plugin are ready for review (submitted one more to address an EOS test

In addition to the integration/test change 98642, we need some additional changes for OpenFlow Plugin tests to support the stricter URL requirements & status code change (204 for RPC with empty

Okay, so BGPCEP should be all clear, the RESTCONF regression blocking OFP perf tests is resolved. One of the OVSDB failures has a controller tracker, but we won't be able to fix it for SR1. Th eonly

On the OFP side, we have a RESTCONF regression: https://jira.opendaylight.org/browse/NETCONF-834 I have the fix and will be rolling it out as soon as possible. Regards, Robert

On the BGPCEP side, this seems to be a problem with in RFC8040 request URI format: http://10.30.170.109:8181/rests/data/odl-data-change-counter-config:data-change-counter-config/data-change-counter

it seems that there are still BGPCEP, OVSDB and OFP issues https://jenkins.opendaylight.org/releng/view/autorelease/job/integration-distribution-test-phosphorus/228/

Alright, so BGPCEP-988 is confirmed passing in a Sulfur, thanks to Marek and Olivier for tracking it down and fixing it. With bgpcep-0.16.11 we are back to passing completely here:

Confirmed on Sulfur here: https://jenkins.opendaylight.org/releng/job/daexim-csit-3node-clustering-basic-only-sulfur/ Thanks, Robert

Hi, I removed references to prefix-shard module in daexim's tests https://git.opendaylight.org/gerrit/c/integration/test/+/98613 CSIT seems to pass on sandbox

Richard, is this something you can help with ? Thanks -- Daniel de la Rosa ODL Release Manager

The next LFN Developer & Testing Forum is scheduled for January 10-13, 2022. Once again we will be virtually gathering the LFN project technical communities to progress our releases; discuss project

Nope, those two are related to the new EOS implementation. Regards, Robert

Right, but prefix shards have been removed in https://jira.opendaylight.org/browse/CONTROLLER-1977, so daexim should not rely on them... Regards, Robert

Ok, thanks for the clarification.. so @Robert Varga this is not part of the controller tickets that you and @Tomáš Cére are working on? CONTROLLER-2025 and CONTROLLER-2026 right?

Hi Daniel, I don't think this has anything to do with daexim, it can't import data into an operational datastore because the offending module (shard-prefix) is not loaded. The Module seems to belong

Hello everyone, This is a reminder that we have a Slack channel available for open ODL discussion here: https://join.slack.com/t/lfntech/shared_invite/zt-xzd50vsy-ap53baNIVSxDyunb9zB6jA Best, Casey

Thanks Robert and all... Richard, we are having some issues with Daexim, is that something you can help

Yes there is and there is quite a bit of history attached to that. Our governance clearly states that each project is independent, which in this context means is free to release whenever as well as