Date   

Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 29/03/2022 01:13, Robert Varga wrote:
On 28/03/2022 00:10, Robert Varga wrote:
On 24/03/2022 01:24, Daniel de la Rosa wrote:


On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release
A quick update here. We are on the home stretch now, with 31 callsites still being bad. About a third are duplicate (e.g. they are the same weirdness across bierman20/rfc8040). They will need some amount of TLC, which I am not in position to give right now, sorry :(
Okay, so I am down to 3 call sites, which fall into two categories:
1. old RESTCONF's URI parser leafref support. I think I can perform sufficient surgery to make this work without having to rewrite that thing (as was done for new RESTCONF, where this is a breeze)
2. two instances of a weird interaction with XML codec. It is not that weird, I understand what is going on, it just needs a bit of more work.
I will need another day to deal with them and, fingers crossed, UTs should agree.
This is now cleared, netconf-3.0.0 is out there. Most of the MSI update patches are done -- except openflowplugin.

Upgraded spotbugs is finding some badness which was introduced in https://git.opendaylight.org/gerrit/c/openflowplugin/+/91313 and I need to figure out how to fix it.

BGPCEP still has a four contributions left for review, I will take care of that tomorrow.

Regards,
Robert


netconf-3.0.0 released

Robert Varga
 

Hello,

netconf-3.0.0, has been released.

Release notes are available here:
https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10142&version=12915

The following issues have been resolved:

Improvement
[NETCONF-864] - Convert WadlTemplate.xtend to Java
[NETCONF-866] - Do not tolerate malformed RPC/action references in requests URL
Task
[NETCONF-815] - Eliminate use of SchemaNode.getPath()
[NETCONF-839] - Do not install odl-restconf-nb-bierman02 by default
[NETCONF-846] - Set call-home SSH port to 4334
[NETCONF-865] - Remove deprecated NodeContainerProxy
[NETCONF-867] - Reject consecutive slashes in RFC8040 URLs
Bug
[NETCONF-707] - Netconf TestTool: Validation for invalid file in "schemas-dir" argument
[NETCONF-713] - Stackoverflow in sal-rest-docgen
[NETCONF-848] - Netconf notifications processing failing for odl-leaf-nodes-only
[NETCONF-868] - Missing anydata support in ParameterAwareNormalizedNodeWriter.java
Sub-task
[NETCONF-817] - Eliminate use of SchemaNode.getPath() in sal-netconf-connector
[NETCONF-818] - Eliminate use of SchemaNode.getPath() in RESTCONF northbound
[NETCONF-819] - Eliminate use of SchemaNode.getPath() in sal-rest-docgen
This release also integrates odlparent-10.0.0, infrautils-3.0.0,
yangtools-8.0.2, mdsal-9.0.1, controller-5.0.1 and aaa-0.16.1.

Enjoy,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 28/03/2022 00:10, Robert Varga wrote:
On 24/03/2022 01:24, Daniel de la Rosa wrote:


On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release
A quick update here. We are on the home stretch now, with 31 callsites still being bad. About a third are duplicate (e.g. they are the same weirdness across bierman20/rfc8040). They will need some amount of TLC, which I am not in position to give right now, sorry :(
Okay, so I am down to 3 call sites, which fall into two categories:

1. old RESTCONF's URI parser leafref support. I think I can perform sufficient surgery to make this work without having to rewrite that thing (as was done for new RESTCONF, where this is a breeze)

2. two instances of a weird interaction with XML codec. It is not that weird, I understand what is going on, it just needs a bit of more work.

I will need another day to deal with them and, fingers crossed, UTs should agree.

Regards,
Robert


netconf-2.0.14 released

Robert Varga
 

Hello,

netconf-2.0.14, has been released back on Feb 14, 2022. The only difference was a fix to misalignment of yangtools versions. I missed sending out an announcement, sorry about that.

Enjoy,
Robert


aaa-0.15.1 released

Robert Varga
 

Hello everyone,

aaa-0.15.1 has been released. There is nothing explicit in this release, just adoption of upstream versions: yangtools-9.0.2, controller-5.0.1, mdsal-9.0.1.

Enjoy,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 24/03/2022 01:24, Daniel de la Rosa wrote:
On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release
A quick update here. We are on the home stretch now, with 31 callsites still being bad. About a third are duplicate (e.g. they are the same weirdness across bierman20/rfc8040). They will need some amount of TLC, which I am not in position to give right now, sorry :(

I expect to have them cleared tomorrow, Tuesday the latest, at which point I'll activate the supercommitter rights and roll things out.

The upgrade guide will come right after that, e.g. Tue or Wed.

Regards,
Robert


controller-5.0.1 released

Robert Varga
 

Hello everyone,

controller-5.0.1 has been released. There are only upstream bumps in this release:
- akka-2.6.19
- yangtools-8.0.2
- mdsal-9.0.1

Enjoy,
Robert


mdsal-9.0.1 released

Robert Varga
 

Hello everyone,

mdsal-9.0.1 has been released, the release notes are here:
https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10137&version=13201.

The following issues were addressed relative to mdsal-9.0.0:

New Feature
[MDSAL-684] - Package RFC8819 Module Tags models
This release also picks up yangtools-8.0.2.

Enjoy,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Olivier Dugeon
 

Hello Robert, all,

Le 21/03/2022 à 15:17, Robert Varga a écrit :
On 21/03/2022 14:45, Olivier Dugeon via lists.opendaylight.org wrote:

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

Not yet for BGPCEP. I discover some late bugs on new PCE server last week. Patch is ready. I'll submit it this afternoon, just right after last verification.

Latest patches have been submitted:

The first two have been reviewed and are ready to be merged. Latest one needs to be reviewed.

The only point that is remaining for BGPCEP, is to clean the compilation from various warning message. I don't know if we include these now or wait for Sulfur SR1.

Regards

Olivier


Alright, anyway it's going to take a couple of days to sort out the RESTCONF stuff, so that (and the javadoc jobs) are the real blockers.

Regards,
Robert
--
Orange logo

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@...
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


yangtools-8.0.2 released

Robert Varga
 

Hello everyone,

yangtools-8.0.2 has been released. The release notes are at
https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10188&version=13305.

There are 5 issues resolved in this release:

Bug
[YANGTOOLS-1407] - Attempted access to undeclared case statement
[YANGTOOLS-1408] - Deviation of augmented case node fails
[YANGTOOLS-1410] - 'choice' not allowed in 'choice' with yang-version 1.1
[YANGTOOLS-1411] - JSON codec fails to decode instance-identifier to a choice/case/choice item
[YANGTOOLS-1412] - Add DataSchemaContextTree/SchemaInferenceStack integration
Enjoy,
Robert


yangtools-7.0.15 released

Robert Varga
 

Hello everyone,

yangtools-7.0.15 has been released. Release notes are available here: https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10188&version=13202

Following issues have been resolved:

Bug
[YANGTOOLS-1404] - Deviation of augmented node causes NPE
[YANGTOOLS-1408] - Deviation of augmented case node fails
[YANGTOOLS-1410] - 'choice' not allowed in 'choice' with yang-version 1.1
[YANGTOOLS-1411] - JSON codec fails to decode instance-identifier to a choice/case/choice item
[YANGTOOLS-1412] - Add DataSchemaContextTree/SchemaInferenceStack integration

Enjoy,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Daniel de la Rosa
 



On Wed, Mar 23, 2022 at 3:47 PM Robert Varga <nite@...> wrote:
On 21/03/2022 14:24, Robert Varga wrote:
> On 20/03/2022 19:50, Robert Varga wrote:
>> On 19/03/2022 16:37, Daniel de la Rosa wrote:
>>>
>>>     Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more
>>> diagnosable
>>>     -- I plan to squash that today.
>>>
>>>
>>> It looks like all issues have been resolved. So are we ready to pick
>>> the next AR as RC?
>>
>> I am still working through netconf/bgpcep, plus the bump to MSI
>> projects. I'll keep you posted.
>
> bgpcep is ready for integration, but netconf is not -- as it turns the
> vast majority of patches dealing with SchemaNode.getPath() caller
> removal had to be reverted because ... let's say they were naive.

So fixing RESTCONF here is going to require a yangtools-8.0.2 release.
The problem is that we lost a DataSchemaContextTree capability which was
provided indirectly via SchemaNode.getPath() -- the details are in
YANGTOOLS-1412.

I expect to have that fixed today and finish the RESTCONF integration
tomorrow, so that the MRI bump should (fingers crossed) over the weekend.

It is way later than planned, expected or hoped, but unfortunately it is
what it is. There is silver lining here, though: this effort found two
bugs that have been squashed after lurking around for 7 years.

That’s impressive. Ok thanks and it is all good. We will have a very solid sulfur release 




I'll keep you posted,
Robert
--
Daniel de la Rosa
ODL Release Manager


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 21/03/2022 14:24, Robert Varga wrote:
On 20/03/2022 19:50, Robert Varga wrote:
On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?
I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.
bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.
So fixing RESTCONF here is going to require a yangtools-8.0.2 release. The problem is that we lost a DataSchemaContextTree capability which was provided indirectly via SchemaNode.getPath() -- the details are in YANGTOOLS-1412.

I expect to have that fixed today and finish the RESTCONF integration tomorrow, so that the MRI bump should (fingers crossed) over the weekend.

It is way later than planned, expected or hoped, but unfortunately it is what it is. There is silver lining here, though: this effort found two bugs that have been squashed after lurking around for 7 years.

I'll keep you posted,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 21/03/2022 14:45, Olivier Dugeon via lists.opendaylight.org wrote:

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.
Not yet for BGPCEP. I discover some late bugs on new PCE server last week. Patch is ready. I'll submit it this afternoon, just right after last verification.
Alright, anyway it's going to take a couple of days to sort out the RESTCONF stuff, so that (and the javadoc jobs) are the real blockers.

Regards,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Olivier Dugeon
 

Hello Robert,

Le 21/03/2022 à 14:24, Robert Varga a écrit :
On 20/03/2022 19:50, Robert Varga wrote:
On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?

I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

Not yet for BGPCEP. I discover some late bugs on new PCE server last week. Patch is ready. I'll submit it this afternoon, just right after last verification.

Regards

Olivier


serviceutils is also ready to integrate, but there's a problem needing action in global-jjb: javadocs jobs are using mvn35 and thus end up exploding like here: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/32/

Even when we tell the job to use mvn38, it will unpack the correct maven, but will attempt to use mvn35: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/33/console

Regards,
Robert





--
Orange logo

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dugeon@...
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 20/03/2022 19:50, Robert Varga wrote:
On 19/03/2022 16:37, Daniel de la Rosa wrote:

    Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
    -- I plan to squash that today.


It looks like all issues have been resolved. So are we ready to pick the next AR as RC?
I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.
bgpcep is ready for integration, but netconf is not -- as it turns the vast majority of patches dealing with SchemaNode.getPath() caller removal had to be reverted because ... let's say they were naive.

serviceutils is also ready to integrate, but there's a problem needing action in global-jjb: javadocs jobs are using mvn35 and thus end up exploding like here: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/32/

Even when we tell the job to use mvn38, it will unpack the correct maven, but will attempt to use mvn35: https://jenkins.opendaylight.org/releng/job/serviceutils-maven-javadoc-verify-sulfur-openjdk11/33/console

Regards,
Robert


Re: [OpenDaylight TSC] [release] Sulfur code freeze

Robert Varga
 

On 19/03/2022 16:37, Daniel de la Rosa wrote:
Alright, so MDSAL-731 is fixed and it makes MDSAL-735 more diagnosable
-- I plan to squash that today.
It looks like all issues have been resolved. So are we ready to pick the next AR as RC?
I am still working through netconf/bgpcep, plus the bump to MSI projects. I'll keep you posted.

Regards,
Robert


aaa-0.15.0 released

Robert Varga
 

Hello everyone,

aaa-0.15.0 has been released. There is nothing explicit in this release, just adoption of upstream versions: odlparent-10.0.0, yangtools-9.0.1, infrautils-3.0.0, controller-5.0.0, mdsal-9.0.0.

Enjoy,
Robert


controller-5.0.0 released

Robert Varga
 

Hello everyone,

controller-5.0.0 has been released, the release notes are here:
https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10113&version=12202.

The following issues were addressed relative to 4.0.7:

Task
[CONTROLLER-2006] - Do not pull odl-controller-blueprint into odl-mdsal-broker
Bug
[CONTROLLER-1983] - Akka artery fails with java.lang.OutOfMemoryError: Direct buffer memory

This release also integrates odlparent-10.0.0, yangtools-8.0.1 and
mdsal-9.0.0.

The most notable change is the switch to using Tell-based protocol by default.

Enjoy,
Robert


mdsal-9.0.0 released

Robert Varga
 

Hello everyone,

mdsal-9.0.0 has been released, the release notes are here:
https://jira.opendaylight.org/secure/ReleaseNote.jspa?projectId=10137&version=12005.

The following issues were addressed relative to mdsal-8.0.11:

Story
[MDSAL-563] - Eliminate use of Xtend in unified-html-generator
Improvement
[MDSAL-690] - Do not reference concepts.Builder in builders
[MDSAL-695] - Do not use AugmentationSchemaNode.getOriginalDefinition()
[MDSAL-696] - Do not use DerivableSchemaNode
[MDSAL-719] - Take supported features into account
[MDSAL-722] - Map system-ordered leaf-lists to java.util.Set
[MDSAL-724] - Reject invalid InstanceIdentifiers
[MDSAL-730] - Clean up InstanceIdentifier semantics
Task
[MDSAL-676] - Package ietf-restconf and ietf-yang-patch in mdsal
[MDSAL-685] - Do not reference SchemaNode.getPath()
[MDSAL-688] - Remove unified-html-generator
[MDSAL-705] - Remove RFC7277 models
[MDSAL-706] - Upgrade iana-if-type to 2021-06-21
[MDSAL-707] - Upgrade iana-routing-types to 2021-10-19
[MDSAL-708] - Remove RFC7223 models
[MDSAL-717] - Remove AssertDataObjects
[MDSAL-720] - Do not package rfc7895 ietf-yang-library
[MDSAL-729] - Always genenerate module DataRoot
Bug
[MDSAL-712] - Action(Provider)Service translates grouping Action path incorrectly
[MDSAL-715] - Binding generator fails on resolution of augment whose path contains nodes augmented from another namespace
[MDSAL-718] - Augments fail to resolve
[MDSAL-721] - ActionSpec.build() does not handle KeyedListActions
[MDSAL-723] - ActionProviderService.registerImplementation() does not handle KeyedListActions
[MDSAL-726] - ActionService does not handle KeyedListActions
[MDSAL-731] - Failure to start Binding/DOM codec
[MDSAL-732] - Binding generator generates uncompilable code for leafref chain with identityref at the end
[MDSAL-735] - StackOverflowError with bgp-linkstate
Sub-task
[MDSAL-565] - Convert DocumentationTemplate.xtend to Java
[MDSAL-686] - Do not reference SchemaNode.getPath() in BindingRuntimeTypes
[MDSAL-687] - Do not reference SchemaNode.getPath() in mdsal-binding-generator

This release adopts odlparent-10.0.0 and yangtools-8.0.1.

There are four major changes with impacts on downstreams:

- 'ordered-by system' leaf-lists are now mapped to java.util.Set instead of a List.

- 'decimal64' is now mapped to org.opendaylight.yangtools.yang.common.Decimal64 instead of java.math.BigDecimal

- the old, RFC7223, version of ietf-interfaces has been removed

- the old, RFC7895, version of ietf-yang-library has been removed

Aside from these, the runtime part of Binding Spec implementation has been rewritten to a large extent, as required by the removal of SchemaNode.getPath().


Enjoy,
Robert