I wanted to use one OpenConfig YANG model in my model and included it that way:
import openconfig-if-ip {
prefix oc-if-ip;
}
Then I used a grouping type that I am interested in: useѕ oc-if-ip:ip-common-global-config;
I had to add multiple other YANG models that were required and eventually ended with following errors from confdc:
/home/…/confd/yang/openconfig-if-aggregate.yang:210: error: the node is config, but refers to a non-config node ‘type’ defined at /home/…/confd/yang/openconfig-interfaces.yang:348
/home/…/confd/yang/openconfig-if-ethernet.yang:433: error: the node is config, but refers to a non-config node ‘type’ defined at /home/…/confd/yang/openconfig-interfaces.yang:348
I am using Confd 7.2.0.1 and the most recent OpenConfig models that are on github.
Any help would be much appreciated.
As far as I can see, that grouping defines only a single boolean leaf dhcp-client - does it really make sense to “pull in” a lot of OpenConfig modules just for that?
I checked only the first one, and it seems confdc is correct - the when expression on line 210 is for a uses statement in config data (/oc-if:interfaces/oc-if:interface) and references the “config false” leaf /oc-if:interfaces/oc-if:interface/oc-if:state/oc-if:type. This is not allowed per this section of RFC 7950 - The YANG 1.1 Data Modeling Language :
The accessible tree depends on where the statement with the XPath
expression is defined:
o If the XPath expression is defined in a substatement to a data
node that represents configuration, the accessible tree is the
data in the datastore where the context node exists. The root
node has all top-level configuration data nodes in all modules as
children.
I.e. state data is not part of the “accessible tree” for a when expression on a config node (see the next paragraph in the RFC for the specification of the “accessible tree” for an XPath expression on state data - which does include “all state data”).
Minor correction: since openconfig-if-aggregate is a YANG 1 module, the relevant reference should be to RFC 6020, but it has essentially the same text - https://tools.ietf.org/html/rfc6020#section-7.19.5 :
The accessible tree depends on the context node:
o If the context node represents configuration, the tree is the data
in the NETCONF datastore where the context node exists. The XPath
root node has all top-level configuration data nodes in all
modules as children.
Well, that is a different issue with the same when statement - strictly speaking, that issue doesn’t make the when expression invalid though, it “just” means (if the description of the issue is correct, I haven’t checked) that the oc-if:state/oc-if:type = 'oc-ift:IF_AGGREGATE' part of the expression will always evaluate to false.
A when statement like when "/foo = 'bar'" is perfectly valid even if /foo is an integer leaf, in fact even if there is no /foo at all in the schema (in both cases the expression will always evaluate to false). confdc will (in most cases) produce a warning if the expression references a node that doesn’t exist in the schema, but not if a comparison uses a value that is “impossible” for the leaf.
Actually, looking closer, I see that the “the node is config, but refers to a non-config node” messages that you reported originally are also warnings, so presumably you are compiling with --fail-on-warnings since you get them as errors. This means that you can suppress them with this option to confdc (from the man page):
-w ErrorCode
Do not report the warning ErrorCode, even if --fail-on-warnings is
given. ErrorCode must be a warning.
confdc --list-errors will tell you that the relevant ErrorCode is YANG_ERR_XPATH_REF_BAD_CONFIG, i.e. you can use
-w YANG_ERR_XPATH_REF_BAD_CONFIG
to suppress the warnings. It’s not a good idea for modules that you will actually use though - if a when expression (or must expression or leafref path) for config references state data, it means that the validity of the configuration depends on state, and thus that a validated and committed configuration can become invalid if some state data is changed (this is of course the reason for the requirements in the RFCs).