Augmenting to a conditional augment statement

YANG
1

I have three YANG files:

Main YANG file:
module A {
container interfaces {
list interface {
leaf type {
mandatory true;
}
}
}
}

1st Augment YANG:
module B {
augment “/if:interfaces/if:interface” {
container ethernet {
when “…/if:type = ‘ethernet’”;
}
}
}

2nd Augment YANG:
module C {
grouping pmetric {
container performance-metric {
leaf value {
type uint64;
}
}
}

augment “/if:interfaces/if:interface/eth:ethernet” {
uses pmetric;
}
}

I have a main YANG module that defines a generic interface. It has a mandatory ‘type’ attribute. An augment YANG module adds a container ‘ethernet’ to it when the type of this interface is ‘ethernet’. Further, another augment statement directly refers to this ‘/interfaces/interface/ethernet’ container and adds ‘performance-metric’ container to it.

How does CONFD add these nodes to it’s data model? Currently, I’m observing that even though ‘ethernet’ container is defined as a conditional augment, it is always present within the model. And ‘performance-metric’ container is added to it.

Further cdb_exists() function returns True for ‘/interfaces/interface{x}/ethernet/performance-metric’ even when configured interface is not of ethernet type.

Is this expected behavior? I would assume the as ‘ethernet’ container is conditional, both these containers should only be present within data-model when type is ‘ethernet’.

CONFD VERSION used: confd-6.2 and confd-6.4.1

2

Could you elaborate on how you are observing the data model? Subtrees whose existence is conditional on a when statement, whether augmented or not, are always present in ConfD’s internal representation of the data model - but they are only visible in the NB interfaces when the when expression evaluates to true. The data model representation that you can load with e.g. confd_load_schemas() is essentially equivalent to ConfD’s internal representation, i.e. such subtrees are present there too.

As per the documentation in the confd_lib_cdb(3) man page, cdb_exists() reports on optional leafs, presence containers, and list entries - i.e. nodes that can be created or deleted, and thus actually have an “existence” property. Non-presence containers like performance-metric only serve to organize the data model, they can’t really be created or deleted, and thus using cdb_exists() on such nodes does not give a meaningful result. However cdb_exists() should always return false (i.e. 0) for the value leaf in your model if your when expression evaluates to false.