# Augmenting to a conditional augment statement

**URL:** <https://dmap-community.ductus.global/t/augmenting-to-a-conditional-augment-statement/2340>\
**Category:** YANG\
**Created:** [March 1, 2019, 9:00pm UTC](https://dmap-community.ductus.global/t/augmenting-to-a-conditional-augment-statement/2340 "2019-03-01T21:00:50Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![gouthamp174](https://avatars.discourse-cdn.com/v4/letter/g/898d66/32.png) [@gouthamp174](https://dmap-community.ductus.global/u/gouthamp174)\
**Post date:** [March 1, 2019, 9:00pm UTC](https://dmap-community.ductus.global/t/augmenting-to-a-conditional-augment-statement/2340/1 "2019-03-01T21:00:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![per](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@per](https://dmap-community.ductus.global/u/per)\
**Post date:** [March 4, 2019, 4:59pm UTC](https://dmap-community.ductus.global/t/augmenting-to-a-conditional-augment-statement/2340/2 "2019-03-04T16:59:30Z")

</div>

> [@gouthamp174](#):
>
> 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.

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.

> [@gouthamp174](#):
>
> Further cdb\_exists() function returns True for ‘/interfaces/interface{x}/ethernet/performance-metric’ even when configured interface is not of ethernet type.

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`.