How to use leafref to reference different vendor paths in yang model?

[MitchMahan]

I have a yang model that needs to reference "servers/nodes" on two types of devices (F5 and A10).

For F5:

root@ncs(config)# devices device slb01sqsccc config bigip:ltm node ?
This line doesn't have a valid range expression
Possible completions:
name test-server-1 test-server-2

For A10:

root@ncs(config)# devices device slb45sqsccc config a10-acos:slb server ?
This line doesn't have a valid range expression
Possible completions:
<NAME<length:1-63>> - Server Name
a10-test -
test-server-1 -
test-server-2 -

How do I model the path to either the F5 or A10 NED based on the device being configured?

leaf name {

  tailf:info "Server/Node Name";

  type string;

  //type leafref {

   if f5....

  // path "devices device slb01sqsccc config bigip:ltm node ?";

   if a10...

// path "devices device slb45sqsccc config a10-acos:slb server ?";

  //}

  mandatory true;

}

[vleijon]

The problem is of course that you need to have something do the if-statement on and that makes sure that what you do is unambiguous.

You have three options here: choice, when and union types. You could try doing a union, and add both leafrefs in the same leaf. This should be fine if you already have a leaf for the device. I would often pick a choice nodes for branching since there is often more than one parameter that changes between types.

[MitchMahan]

Is there a guide for using choice nodes? I have not seen choice used yet.

How do I convert the cli path to the correct union leafref?

[yfherzog]

I think you won't be able to use leafref directly here.

As far as I recall, the YANG RFC doesn't allow type leafref inside a union.

[MitchMahan]

Blasted.

What's the best option? Will I have to go into python?

The use case seems fairly simple and I would like to avoid using outside code from templates/xml...

[frjansso]

You can still use templates, please see the processing instructions for templates, more specifically <?if {cond} ?>

[frjansso]

I believe that used to be true, but with YANG 1.1 it's allowed.

[yfherzog]

"I believe that used to be true, but with YANG 1.1 it's allowed."

Interesting!

Indeed, looking into RFC 6020 we have:

A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref"

but looking into RFC 7950, we have:

A member type can be of any built-in or derived type.

Which version of NSO started using YANG 1.1?

[yfherzog]

"I believe that used to be true, but with YANG 1.1 it's allowed."

Interesting!

Indeed, looking into RFC 6020 we have:

A member type can be of any built-in or derived type, except it MUST
   NOT be one of the built-in types "empty" or "leafref"

but looking into RFC 7950, we have:

A member type can be of any built-in or derived type.

Which version of NSO started using YANG 1.1?

[vleijon]

Regarding YANG 1.1 it seems to be from NSO-4.2 [May 26, 2016], but I can also see that some fixes and improvements have been made in the releases just after that.

Regarding the issue at hand, the reason why unions between leafrefs are a little bit iffy is because it is not in general obvious which of the leafrefs a value comes from, both lists may have the same keys. But in this case you probably have some other part of the model that can be used to resolve that ambiguity. Take a look at what you are trying to do and ask a followup question if it seems hard!  

[ramkraja · Accepted solution]

Yes, unions can contain leafrefs, as per the RFC, but as of now, in NSO, it is not fully supported.

The man page for "ncsc" (the compiler) says

Type leafref in unions are not validated, and treated as a string internally.

So, yes, you can have leafrefs in unions in your model, and NSO can compile and load them. But they won't work as you expect of a normal leafref.

/Ram