libyang3 schema default value not honored ... randomly ... bug #2350
Comments
|
That is weird indeed and it would be great if I could reproduce it somehow. What could perhaps affect this is the forced ordering of nodes in newer libyang when they are always following the order in the YANG module. Some functions may create nodes "before" your pointer to the data tree, which may one not always expect and it can result in some "missing" nodes. But no idea whether this can really be an issue or how this is handled in the Python bindings. |
|
I don't see how this could be python-specific, since the bindings on these functions are pretty minimal. I've got to imagine its in the C libyang itself, that said, I can't say if maybe its in print_mem() not emitting the default values somehow or in the parsed data tree. Once I finish up the SONiC porting and get the other PRs accepted here in libyang we depend on I can probably spend some time to write up a test case for this in C (though I'll probably include the entire yang schema and json config in the test case unless I can fairly quickly come up with a reduced set that reproduces the issue). |
|
That would be great, no problem with including a YANG schema and a data file, even if large. |
|
I'm encountering a similar issue with the default values not being reported in a stack using these software (trying to upgrade from older versions): netopeer2-server-2.2.35 In my case, a netconf client perform a get but and is missing a default-value leaf when previous to the upgrade it was returned. See schema here, and notably the leaf maximum-number-of-transport-flows: What was sent before in an edit config: Then what is fetched using a get rpc on the processing-elements module: Note that in my example, using sysrepocfg to dump the content of the operational datastore with Returns nothing with new versions but was returning the default values before. I will try to have a repro step in a small and controlled environment to facilitate investigation as well ! |
|
On my end this is reproduceable using the attached yang model (I used the processing-element one but removed external dependencies) and this script (uses sysrepoctl to load it and get with defaults) With previous stack running I have this result: With new stack running : |
|
Okay, thanks for the reproducer and files, based on which I have learned that you are talking about a |
michalvasko
added
the
status:invalid
Ok, thanks for the reply, then I will make adaptations on my end ! Note that @bradh352 case might not be the same, sorry If I hijacked this thread and his issue is still not addressed but it seemed similar. |
|
Yeah, my issue I'm pretty sure is different. Finishing up porting the last SONiC module to libyang3 (GOlang using |
|
Ok, I finally had time to write a test case. I haven't had a chance to try to mess with the yang to minimize it at all, I just took all the SONiC yang models. See attached issue-2350.tar.gz Extract and compile with something like: cc -Wall -W -I/usr/local/include -L/usr/local/bin -Wl,-rpath=/usr/local/lib -o issue_2350 issue_2350.c -lyangI've embedded both good and bad YANG models, with the diff as previously mentioned which shows just a reorder of nodes: diff -ruN yang-models-bad yang-models-goodIt does one pass on the good yang model and one pass on the bad yang model to extract the json then compares them, output of running the command looks like: Notice how the |
|
@michalvasko now that I've provided a test case to reproduce, at least please remove the status:invalid tag :) |
|
Thanks for the example. So it is just as I thought, only a misunderstanding of the expected behavior. When the it prints all the default values just in a different order. But the flag |
|
I'm honestly not sure why the original author wrote the tests with that xpath, I agree it is odd : https://github.com/sonic-net/sonic-buildimage/blob/master/src/sonic-yang-models/tests/yang_model_tests/tests/device_metadata.json looks like in libyang1 it would print all siblings with the LYP_WITHSIBLINGS flag, not just ones after that point. Didn't realize there was a behavior change. |
It is (unfortunately) not mentioned in the transition docs, but it seems it did change. The expectation is, though, that you either print all the siblings and use the first one (why would you use another?) or print only a specific subtree. |
While porting SONiC from libyang 1.0.73 to 3.7.8, I ran across a peculiar issue. Unless I'm evaluating it wrong, it looks like a bug in libyang's handling of default values but simply reordering the leaf nodes in the container magically fixes it. I've only found a single instance of this in all of SONiC's schema.
If I reorder the leaf nodes in the schema, then the default value shows up and works.
I have a commit here showing the schema reorder I made to make the tests pass:
sonic-net/sonic-buildimage@dd1dddb
The schema leafs impacted are:
both tests do an xpath query for
/sonic-device_metadata:sonic-device_metadata/DEVICE_METADATA/localhost/hostnamethen load the child nodes into a dictionary, and validate the keys ofsonic-device_metadata:default_bgp_statusandsonic-device_metadata:docker_routing_config_modeexist and are of the expected values.This is happening in libyang-python with code similar to this:
I'm not sure what the underlying cause is so I don't know how to submit a reduced test case.
The text was updated successfully, but these errors were encountered: