augment “/interfaces/interface” {
container tag-ip{
leaf tag-ip {
must “(count(/interfaces/interface/tag-ip[bit-is-set(tag-ip, ‘inband’)]) = 1)”;
type bits {
bit inband {
position 0;
}
}
}
}
My assumption is that the count statement inside the must condition will always ensure the interface with bit ‘inband’ set is always 1. It is restricting the creation of more than one entry with bit ‘inband’ set but not restricting the deletion of an entry.
I want deletion should be allowed only when deletion and creation of an interface (with inband bit set ) are done in a single commit.
Please let me know if i am missing anything or any other possible solution for this problem.
As explained in the Semantic validation chapter of the User Guide, validation doesn’t validate the changes to the configuration, but the configuration that would result from those changes. And only the nodes that actually exist in that resulting configuration are validated - thus, since your must expression specifies a constraint on the tag-ip leaf, it won’t be evaluated if there are no tag-ip leafs in the resulting configuration.
The solution is to put the constraint on a “higher level” in the configuration - if you want it to be enforced when at least one element of the interface list exists, but not if there are no entries in that list, you can put the constraint on interface. If you want it to always be enforced, effectively requiring that there is at least one entry in the interface list, you can put the constraint on the interfaces container.
In your particular case, you can’t add the must expression to either interface or interfaces via augment, since must is not allowed as a direct substatement to augment - but you can do it via tailf:annotate or deviation. However this, as well as your original attempt, is a bad idea - while it isn’t formally forbidden by the YANG spec, it violates the “spirit” of this paragraph in https://tools.ietf.org/html/rfc7950#section-7.17 -
If the augmentation adds mandatory nodes (see Section 3) that
represent configuration to a target node in another module, the
augmentation MUST be made conditional with a "when" statement. Care
must be taken when defining the "when" expression so that clients
that do not know about the augmenting module do not break.
You aren’t adding a mandatory node, but adding a node that is required to exist due to a must expression is effectively the same - clients that don’t know about your augmentation + must-addition may break, since they are not aware that they must make sure that there is a tag-ip leaf with the inband bit set.