|
Can you provide the corresponding XML payloads, please?
|
|
You mean the payload of the PUT call above? It's like this:
|
|
Sorry, I mistook the stack trace for an inbound message. ENOCOFFEE.
|
|
Hmm, is it happening in a single-node or is the request made to one node and the exception is on the other?
Because it looks as though the NormalizedNode structure was created without the deviate and is being interpreted with the deviate, leading to a mismatch.
|
|
In the NormalizedNode, the YangInstanceIdentifier for the AugmentationNode has both augmented leaf nodes, baz, removed by deviate.yang, as well as qux.
Also, AugmentEffectiveStatement has both baz & qux leaf nodes in dataChildren but not in the schemaTree of EffectiveStatement for container foo.
So when trying to set aug, the process of creating EffectiveAugmentationSchema fails because AugmentationSchemaNode has both baz & qux but its parent DataNodeContainer does not have baz.
|
|
I strongly believe this has to do with how NETCONF topology operates, hence we need to investigate it there.
|
|
By the time effective statements are generated from the models, augmented effective statements include the 'not-supported' node but schema tree does not. And when creating EffectiveAugmentationSchema it enforces that all the children in the AugemntationSchema exist in its parent container. Both of these are done by yangtools, so I'm not sure how this can be addressed with NETCONF topology.
|
|
Well, the thing is we parsed the payload without the deviation, hence the AugmentationIdentifier containing 'baz', but then we arrive at the mount point primary and try to send it out – and that primary does not see 'baz'.
This related to yang-data treating augmentations specially, which is also an upgrade concern, tracked in some yangtools issue (sorry, takes to long to loot it up), but in a consistent cluster this should not be an issue and we need to understand what netconf-topology-singleton is doing before assigning blame.
|
|
The problem is reproducible in single node deployment. We are afraid that the problem can be that #fromInstanceId method returns data with identifier including also deviated leaf. Thus we need to first get rid of #fromInstanceId to be sure where the problem is. Lets wait for YANGTOOLS-1392.
|
|
That is interesting. I strongly suspect this is related to the area YANGTOOLS-1403 is touching – yang.model.util.EffectiveAugmentationSchema. There is a (not very) subtle difference between an AugmentationSchemaNode (and EffectiveAugmentStatement) produced by the parser and what needs to be considered when codecs come into play.
The former reflects closely how the augment was declared, e.g. it is without effects of deviate/augment statements further targeting the augment target node. The latter is a a view corresponding to how the target sees the augmentation – and includes the effects of deviate.
All codec paths should be working on top of the latter, really. I suggest looking at code paths to see whether there is a disconnect involving one side using EffectiveAgumentationSchema and the other not. Note this may mean that AugmentationIdentifiers can get out of whack as well – the EffectiveAugmentationSchema view can have fewer children, so cross-referencing them back to the model may be challenging.
What is suspect is this bit:
final class AugmentationContextNode extends DataContainerContextNode<AugmentationIdentifier> {
AugmentationContextNode(final AugmentationSchemaNode augmentation, final DataNodeContainer schema) {
super(augmentationIdentifierFrom(augmentation), EffectiveAugmentationSchema.create(augmentation, schema), null);
}
so we are deriving the identifier from the declared view, but pass down the effective view – and therefore emit AugmentationIdentifier with leaf which was deviated away.
|
|
sangwookha can you give https://git.opendaylight.org/gerrit/c/yangtools/+/99930 a try, please?
|
|
Yes, the patch works.
The following request generated config data as expected:
|
Generated at Wed Feb 07 20:56:03 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.
Steps to reproduce.odt