Merge configuration diff error after the yang modules have been changed. about sysrepo HOT 8 OPEN

You are using an ancient sysrepo version and you should most definitely update it. And to silently ignore unknown data, call lyd_parse_data() without LYD_PARSE_STRICT (which should be the default).

from sysrepo.

Hi team,

1. We have updated the sysrepo version and the libyang version, and call lyd_parse_data() without LYD_PARSE_STRICT which will resolve the issue that the error "Node "" not found as a child of "" node " in "lydxml_subtree_r" API if we delete the yang leaf node in the new version, and we have changed this node's value before.
2. But other issues still here.
   (1) We met the error "Node "" to be created already exists" in "sr_edit_apply_r" API if we modify the default value of the node in the new version, and we have created the same node value before.
   

(2) We met the error "Node "" to be deleted does not exist" in "sr_edit_apply_r" API if we delete the yang list node's default value in the new version, and we have modified this node's value before.

(3) We met the error "Node "" does not exist" in "sr_edit_apply_r" API if we delete the yang list node's key default value in the new version, and we have modified the node with this key before.

(4) We met the error "Unsatisfied range - value "" is out of the allowed range." in "lyplg type validate range" API if we change the value range in the new version, and we have modified the node with this key before.

You can check the attached file for example which generated from the old device version, and we want to merge this diff file to the new device version which we will change the yang node or default value of yang node.

3. So here I still have several questions need you help to confirm
   (1) Why we will meet the issue that the sysrepo merge configuration diff failed? The method we used to update configuration diff is right?
   (2) Are there some release document introducing how to update configuration diff after the yang modules have been changed?

libyang: v2.1.111
sysrepo: v2.2.105

BR,
Cecilia Zhong

from sysrepo.

Hi team,

1. We have updated the sysrepo version and the libyang version, and call lyd_parse_data() without LYD_PARSE_STRICT which will resolve the issue that the error "Node "" not found as a child of "" node " in "lydxml_subtree_r" API if we delete the yang leaf node in the new version, and we have changed this node's value before.
2. But other issues still here.
   (1) We met the error "Node "" to be created already exists" in "sr_edit_apply_r" API if we modify the default value of the node in the new version, and we have created the same node value before.
   

(2) We met the error "Node "" to be deleted does not exist" in "sr_edit_apply_r" API if we delete the yang list node's default value in the new version, and we have modified this node's value before.

(3) We met the error "Node "" does not exist" in "sr_edit_apply_r" API if we delete the yang list node's key default value in the new version, and we have modified the node with this key before.

(4) We met the error "Unsatisfied range - value "" is out of the allowed range." in "lyplg type validate range" API if we change the value range in the new version, and we have modified the node with this key before.

You can check the attached file for example which generated from the old device version, and we want to merge this diff file to the new device version which we will change the yang node or default value of yang node.

3. So here I still have several questions need you help to confirm
   (1) Why we will meet the issue that the sysrepo merge configuration diff failed? The method we used to update configuration diff is right?
   (2) Are there some release document introducing how to update configuration diff after the yang modules have been changed?

libyang: v2.1.111
sysrepo: v2.2.105

BR,
Cecilia Zhong

from sysrepo.

Only point 1) is supported as part of "data update" and only accidentally. So, strictly speaking, data update is not a use-case directly supported by libyang and you will have to implement it yourself somehow if you want this feature.

from sysrepo.

Hi team,

For the point 1) you said is that call lyd_parse_data() without LYD_PARSE_STRICT?
And we have resolved the problem as below. Maybe we can share with your team, Are there any suggestion?
(1) We met the error "Node "" to be created already exists" in "sr_edit_apply_r" API if we modify the default value of the node in the new version, and we have created the same node value before.
The solution: we change the EDIT_CREATE to EDIT_MERGE when error.

(2) We met the error "Node "" to be deleted does not exist" in "sr_edit_apply_r" API if we delete the yang list node's default value in the new version, and we have modified this node's value before.
The solution: we "return NULL" directly but not "goto op_error" when error.

(3) We met the error "Node "" does not exist" in "sr_edit_apply_r" API if we delete the yang list node's key default value in the new version, and we have modified the node with this key before.
The solution: we "return NULL" directly but not "goto op_error" when error.

(4) We met the error "Node "" instance to insert next to not found" in "sr_edit_find_userord_predicate" API if we modify the default value of the ordered-by node in the new version, and we have modified this node before.
The solution: we do nothing but not "return err_info" when sr_edit_find_userord_predicate return error.

BR,
Cecilia Zhong

from sysrepo.

You are directly modifying sysrepo code? I do not think that is a good solution but it is up to you. And yes, if you parse the data without the strict flag, it should automatically ignore any unknown nodes, which are those that were removed in the new YANG version.

from sysrepo.

Hi,

But the fact is that we also meet those issues even if we parse the data without the strict flag, so we think there are some problem in sysrepo opensource code. So we share our solution with the team and want to submit the code to sysrepo's svn git. So I want to know how can we submit?
And if you do not think that is a good solution, can you share the solution with us? Thanks!

BR,
Cecilia Zhong

from sysrepo.

But the fact is that we also meet those issues even if we parse the data without the strict flag, so we think there are some problem in sysrepo opensource code.

Your use-case is not supported, like I said, so I do not think you call it a problem in the code, it is intentional. And your changes will certainly not be merged because they remove all the errors that should actually be generated for the normal cases when the YANG module has not been updated.

Implementing this properly is not trivial and I would think about a solution involving getting an exact difference of the 2 YANG modules and then using it for adjusting the data. I doubt you will implement something like that so I guess you are left with whatever solution you want just do not expect it to be merged into our repositories.

We may need to solve this use-case in the near future and ten implement some proper mechanism for it.

from sysrepo.