Conflict on org.opendaylight.yangtools.yang.model.ri.stmt.impl.eff.RegularLeafEffectiveStatement #YANGtools


 

Hello everyone,

I am trying to add the T-API notification YANG model to transport-pce project. However, I get the following error caused by yangtools:

[ERROR] Failed to execute goal org.opendaylight.yangtools:yang-maven-plugin:7.0.8:generate-sources (binding) on project transportpce-tapimodels: Execution binding of goal org.opendaylight.yangtools:yang-maven-plugin:7.0.8:generate-sources failed: Conflict on org.opendaylight.yangtools.yang.model.ri.stmt.impl.eff.RegularLeafEffectiveStatement@452a32f2 between LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2018-12-10)uuid, addedByUses} and LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2018-12-10)uuid, addedByUses}

I have read the latest impacts of Yangtools after phosphorus release, and I dont know whether the section "Strictly-compliant leafref path interpretation" has something to do with it or not. Is there anything Im missing or doing wrong?? I have only placed the YANG model in the corresponding module and tried to build the project to generate the corresponding java classes...

Thanks in advance!!
Javier


 
Edited

Just found out the root of the error, however, I do not understand well why it is happening.
In the following snippet of the YANG file, when the line uses tapi-common:resource-spec is commented out, the error disappears. Just as a reminder the models are for the revisionn date 2018-12-10 (T-API version 2.1.1).

Hope you can give me a hand :)

grouping notification {
leaf notification-type {
type notification-type;
description "none";
}
leaf target-object-type {
type object-type;
description "none";
}
leaf target-object-identifier {
type tapi-common:uuid;
description "none";
}
list target-object-name {
key 'value-name';
min-elements 1;
uses tapi-common:name-and-value;
description "none";
}
leaf event-time-stamp {
type tapi-common:date-and-time;
description "none";
}
leaf sequence-number {
type uint64;
config false;
description "A monotonous increasing sequence number associated with the notification.
The exact semantics of how this sequence number is assigned (per channel or subscription or source or system) is left undefined.";
}
leaf source-indicator {
type source-indicator;
description "none";
}
leaf layer-protocol-name {
type tapi-common:layer-protocol-name;
description "none";
}
list changed-attributes {
key 'value-name';
uses name-and-value-change;
description "none";
}
list additional-info {
key 'value-name';
uses tapi-common:name-and-value;
description "none";
}
leaf additional-text {
type string;
description "none";
}
container tca-info {
uses tca-info;
description "none";
}
container alarm-info {
uses alarm-info;
description "none";
}
uses tapi-common:resource-spec;
description "none";
}


 

Just FYI, it seems to be a problem with the model itself and not with YANGTOOLS. I have created an issue in the github repository of T-API with the fix I propose. Here I leave  the link the the issue. Sorry for the confusion I may have caused...

https://github.com/OpenNetworkingFoundation/TAPI/issues/517

All the best!!
Javier


 

On 12/10/2021 10:17, Javier Errea wrote:
Hello everyone,
Hello Javier,

I am trying to add the *T-API notification* YANG model to transport-pce project. However, I get the following error caused by yangtools:
[ERROR] Failed to execute goal org.opendaylight.yangtools:yang-maven-plugin:7.0.8:generate-sources (binding) on project transportpce-tapimodels: Execution binding of goal org.opendaylight.yangtools:yang-maven-plugin:7.0.8:generate-sources failed: Conflict on org.opendaylight.yangtools.yang.model.ri.stmt.impl.eff.RegularLeafEffectiveStatement@452a32f2 between LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2018-12-10)uuid, addedByUses} and LeafGenerator{argument=(urn:onf:otcc:yang:tapi-notification?revision=2018-12-10)uuid, addedByUses}
I have read the latest impacts of Yangtools after phosphorus release, and I dont know whether the section "/Strictly-compliant leafref//path interpretation/" has something to do with it or not. Is there anything Im missing or doing wrong?? I have only placed the YANG model in the corresponding module and tried to build the project to generate the corresponding java classes...
Right, and this seems to be a problem in MD-SAL's codegen core, definitely not in yangtools. If we get to this point, YANG parser has done its job and the model should be (mostly) valid.

Can you share the stack trace of that error, as reported by 'mvn -e', please?

I'll try to dig into the model and the other messages you have posted.

Thanks,
Robert


 

On 12/10/2021 18:47, Javier Errea wrote:
Just FYI, it seems to be a problem with the model itself and not with YANGTOOLS. I have created an issue in the github repository of T-API with the fix I propose. Here I leave  the link the the issue. Sorry for the confusion I may have caused...
Ah, no worries at all.

You were on the money with a hunch around leafrefs, except it's in a rather different area :)

You are hitting a corner case I thought was not possible, but will be becoming the norm in the world of (upcoming) yangtools-8.

Anyway, long story short ...

https://github.com/OpenNetworkingFoundation/TAPI/issues/517 <https://github.com/OpenNetworkingFoundation/TAPI/issues/517>
... I think this should be closed down, as it is not a problem with the model as such, but rather an issue with mdsal-binding-generator's logic. Can you file an issue for MD-SAL in jira.opendaylight.org with the 'mvn -e' stack trace, please?

Thanks,
Robert


 

Thanks for the reply Robert. Definately, I will close the issue in Github and create a jira ticket in the MD-SAL project.

Br,
Javier


 

Here you can find the link of the issue I created inn the JIRA of MD-SAL
https://jira.opendaylight.org/browse/MDSAL-694

Javier