We are using vsn: 6.4.3
After I added a “ordered-by user” to a list, one of leaves started having a validation failure (continue reading). This are the leaves that are causing the trouble:
leaf a1 {
type boolean;
default true;
must ". = 'true' or (../b1 and ../c1)" {
error-message "b1 and c1 must be set when a1 is disabled.";
}
}
leaf b1 {
when "../a1 = 'false'";
type ethernet-speed;
}
leaf c1 {
when "../a1 = 'false'";
type duplex;
default "full";
}
This is the configuration state before the upgrade:
interface yyy
enabled
a1 false
b1 1G
c1 full
exit
Then I flash the updated confd. In the log I can see:
.
.
confd[1204]: - Loading file /etc/confd/1234/xxx-interfaces.fxs - module where leaves resides
.
.
confd[1204]: devel-cdb upgrade: processing data in module xxx-interfaces
confd[1204]: devel-cdb upgrade: revision: xxx-interfaces@2015-05-05
confd[1204]: devel-cdb upgrade: completed module xxx-interfaces
.
.
confd[1204]: - CDB load: processing file: /var/confd/init-xmls/xxx_init.xml - the inital values of leaves
This are the relevant lines from xxx_init.xml:
<avif:a1>false</avif:a1>
<avif:b1>1G</avif:b1>
<avif:c1>full</avif:c1>
.
.
confd[1204]: - CDB: Upgrade failed: Upgrade transaction failed to validate: /if:interfaces/interface{yyy}/a1 (value "false"): b1 and c1 must be set when a1 is disabled.
.
.
I reflashed the unit back to previous unmodified firmware.
Then I applied a modified firmware with changes, this time besides adding the “ordered-by user” I also commented out the must clause. The upgrade finishes without errors, but when I print out the CDB:
interface yyy
enabled
a1 false
exit
Another thing I tried was adding a default statement for b1. In this example I did not comment out the must statement. The upgrade was successful but again we only see a1 in the CDB. Also this overrides our must statement, leaving b1 and c1 “undefined” with a1 with false value.
Overall we see that the validation was failing because b1 and c1 did not exist. My question is why are they gone or why is only a1 present?
The data in your xxx_init.xml file is not used, since in a CDB upgrade, only data for elements that are new as of the upgrade will be considered. See 5.10 Using initialization files for upgrade in the User Guide.
This doesn’t explain why data in your list that existed before the upgrade would disappear though, and it doesn’t happen for me when I try your model and (only) add ordered-by user; to the list for the upgrade. Could it be that you are deleting (some data in) the list via MAAPI during the upgrade, and expect it to be re-created from the init file?
I changed the order of leaves to b1, c1, a1 and the same problem was present.
Then i also did the same with the elements in the xxx_init.xml and now the upgrade works.
There is some connection between upgrade and init.xml.
leaf b1 {
when “…/a1 = ‘false’”;
type ethernet-speed;
}
leaf c1 {
when “…/a1 = ‘false’”;
type duplex;
default “full”;
}
leaf a1 {
type boolean;
default true;
must “. = ‘true’ or (…/b1 and …/c1)” {
error-message “b1 and c1 must be set when a1 is disabled.”;
}
}
Great that you got it to work, but I’m afraid that I have to think that your description is inaccurate and/or incomplete. The CDB upgrade really, really - as I wrote, as documented, and as motivated in the documentation - doesn’t use any data in init files for nodes that existed prior to the upgrade, so it can’t possibly matter what the data for those nodes is, even less in what order it is (of course CDB still has to “load” and “process” the init files, to determine what the data is).
I can think of some reasons (which don’t match your description of your actions) for the problem you see/saw, but it doesn’t seem useful to speculate. In any case, ConfD shouldn’t, and doesn’t as far as I know, have any requirements on the order of leafs in your data model nor in the init files.
But I know from experience how easy it is to draw the wrong conclusions from trying out different things during debugging - e.g. due to not repeating the exact same procedure, or due to changing multiple things and assuming that a change other than the significant one was the “fix”.
I did some more test cases that trigger an upgrade. The changes where made on the same yang every time. So far I noticed that all test cases go through without errors, but when I add “ordered-by user” the configuration is missing leaves and the validation fails.
Maybe a relevant info is also that the validation effected leaves are a part of augmentation that is placed on the list item.
The data was not deleted. I guess confd creates somekind of abstraction of cdb where it does not see b1 and 2102272149.
Why are leaves sorted this way?
Please notice that b1 is represented by name and not number. Could that be an issue?
Thank you!
I figured it out.
Based on the order the leaves are stored in CDB it is obvious that b1’s and c1’s when clauses can not be resolved correctly because the a1 leaf is stored after them. When confd wants to resolve the when clauses the a1 leaf is not yet created.
One solution is to use tailf:sort-priority to reorder the leaves (not tested), the second is to change the when clauses to “not(…/a1) or …/a1 = ‘false’”. In my case a1’s must statement will properly validate the configuration.
br
