diff API output #2028
Replies: 3 comments 7 replies
-
|
Yes, please provide the input and output in the old version and in the new version, please. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for getting back. The yang model is below: module pkm {
yang-version "1.1";
namespace "pkm";
prefix "pkm";
grouping nc-top {
container named-conditions {
list named-condition {
key name;
leaf name {
type string {
length 1..64;
}
}
leaf description {
type string;
}
list rules {
key position;
leaf position {
type uint32 {
range 1..max;
}
}
leaf description {
type string;
}
}
}
}
}
// data definition statements
uses nc-top;
}data1: {
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc0",
"description": "d2",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
},
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}data2: {
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc0",
"description": "d2-new",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}SO, if we look diff between data 1 and data 2, the changes are the following: I am using the diff API (lyd_diff_tree) to get the diff between data 1 and data 2, and I see inconsistencies in the output Sometimes it is in format1 as shown below: {
"pkm:named-conditions": {
"@": {
"yang:operation": "none"
},
"named-condition": [
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"description": "d2-new",
"@description": {
"yang:operation": "replace",
"yang:orig-default": false,
"yang:orig-value": "d2"
},
"rules": [
{
"@": {
"yang:operation": "delete"
},
"position": 10,
"description": "test gbp tcp allow rule"
}
]
}
]
}
}But sometimes it is format2 below: {
"pkm:named-conditions": {
"@": {
"yang:operation": "none"
},
"named-condition": [
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"description": "d2-new",
"@description": {
"yang:operation": "replace",
"yang:orig-default": false,
"yang:orig-value": "d2"
}
},
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"rules": [
{
"@": {
"yang:operation": "delete"
},
"position": 10,
"description": "test gbp tcp allow rule"
}
]
}
]
}
}In format1, there is only one dict block for "nc0" whereas in format2, there are two blocks for nc0 (instead of merging them into one) for each of the two changes. What is the correct format (format1?) and why is it in-consistent ? |
Beta Was this translation helpful? Give feedback.
-
You would need to be more specific and provide exact reproducible steps, nothing I can do with such a vague description. I have tested in in the current libyang v2.1.80 and got the output {
"pkm:named-conditions": {
"@": {
"yang:operation": "none"
},
"named-condition": [
{
"name": "nc0",
"description": "d2-new",
"@description": {
"yang:operation": "replace",
"yang:orig-default": false,
"yang:orig-value": "d2"
},
"rules": [
{
"@": {
"yang:operation": "delete"
},
"position": 10,
"description": "test gbp tcp allow rule"
}
]
}
]
}
}which is the most correct diff without an redundant operations. So unless you can actually get anything else with the latest libyang version, there is nothing to fix. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, please try the below inputs to reproduce. Originally, I thought the issue was with latest tag (2.1.55). But, later, realized that the problem is seen when we change the inputs data, a little bit (with both older and new versions). Please see below
{
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc1",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc2",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc3",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc4",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc0",
"description": "d2",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
},
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}data2: {
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc0",
"description": "d2-new",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}DIff: {
"pkm:named-conditions": {
"@": {
"yang:operation": "none"
},
"named-condition": [
{
"@": {
"yang:operation": "delete"
},
"name": "nc1",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "delete"
},
"name": "nc2",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "delete"
},
"name": "nc3",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "delete"
},
"name": "nc4",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"description": "d2-new",
"@description": {
"yang:operation": "replace",
"yang:orig-default": false,
"yang:orig-value": "d2"
}
},
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"rules": [
{
"@": {
"yang:operation": "delete"
},
"position": 10,
"description": "test gbp tcp allow rule"
}
]
}
]
}
}As you can see above the diff for "nc0" is not consolidated in one list. This is the problem. nc1 to nc4 has only block, but nc0 has two blocks. Now, if i slightly modify data1 (case 2 below), the diff for nc0 is consolidated.
Data1: {
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc1",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc2",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc3",
"description": "d1",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
}
]
},
{
"name":"nc0",
"description": "d2",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":10
},
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}Data2: {
"pkm:named-conditions":{
"named-condition":[
{
"name":"nc0",
"description": "d2-new",
"rules":[
{
"description":"test gbp tcp allow rule",
"position":20
}
]
}
]
}
}DIff: {
"pkm:named-conditions": {
"@": {
"yang:operation": "none"
},
"named-condition": [
{
"@": {
"yang:operation": "delete"
},
"name": "nc1",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "delete"
},
"name": "nc2",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "delete"
},
"name": "nc3",
"description": "d1",
"rules": [
{
"position": 10,
"description": "test gbp tcp allow rule"
}
]
},
{
"@": {
"yang:operation": "none"
},
"name": "nc0",
"description": "d2-new",
"@description": {
"yang:operation": "replace",
"yang:orig-default": false,
"yang:orig-value": "d2"
},
"rules": [
{
"@": {
"yang:operation": "delete"
},
"position": 10,
"description": "test gbp tcp allow rule"
}
]
}
]
}
}If you compare case 1 and case 2, the only change is the number of named conditions in data1. In case 1, there are 5, whereas in case 2, there is 4. The changes for nc0 is same in both cases, but the diff comes out different depending on the number of elements in the diff. Now, nc0 has only one block in the diff. Pls let me know if you need any further inputs. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot ! It works in devel. When the tag 2.1.82 is published, this fix should in right ? Any idea when it will be published ? |
Beta Was this translation helpful? Give feedback.
-
|
Not too soon as the previous release has been made 2 days ago. In maybe 2 months or so. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for getting back. One more issue I have noticed with libyang 2.1.55 is that lyd_validate_all takes about 8 seconds for each yang module. We have several yang modules and there is relationship between some of the modules in-terms of a leaf-ref and when conditions. Our data tree is like a forest and has the data trees for all the modules. In this scenario what would be the best way to validate. Currently, we call validate_all for each of the module separately. Instead, is there a way we can partition the modules into groups based on the leaf-ref/when conditions and then call validate_all for a representative module from each group. Pls let us know. Also, one more request. We use libyang extensively and for large configurations. So, we were wondering if it is possible to do a TOI session (with folks from my company) on some the libyang internals like diff/validation etc. This will help us to root-cause issues faster and also enable us to contribute to libyang source code as well. |
Beta Was this translation helpful? Give feedback.
-
|
8 seconds is a lot but it depends on the size of the data/YANG module you are validating, I could analyze whether there is some obvious inefficiency if you provide both (data and their YANG(s) with imports). It should not make a difference whether you validate for each module separately or all together. Not managed to find out what TOI stands for :) but I assume some hands-on explanation of the basic concepts. Please contact me on my private email and we will see what can be arranged. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, by TOI, I meant hands-on session :). I have emailed you. Thanks for getting back. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I am currently using libyang 2.0.194, and trying to migrate to latest (2.1.55). I noticed that the output of diff API is different between the two libyang versions, for same input trees. Specifically, the output of latest 2.1.55 seems to have separate blocks for each changed xpath, whereas, in 2.0.194, the output is consolidated based on the prefix/keys of the changed xpaths.
Is this is a known behavior ? What is the correct expected format ? I can provide input and output data if needed for clarity.
Thanks
Praveen
Beta Was this translation helpful? Give feedback.
All reactions