xpath lookup for bigip ltm data

[ron.whitt]

Hello experts,

I'm having trouble getting an xpath lookup working.

I'm trying to retrieve data synced from an f5-bigip device.

here is the path I'm trying to use: 

----------from the YANG model -------------------------

leaf node_name {
description "Use the same node name LAMP_01";
type string;
tailf:link "/ncs:devices/ncs:device[ncs:name=current()/../device-name]/ncs:config/f5-bigip:node_name";

When I compile, I get this error:

yang/load-balancer.yang:72: error: the node 'node_name' from module 'tailf-ned-f5-bigip' (in node 'config' from 'tailf-ncs') is not found

If you do a show running | display xpath, this is what the system shows:

admin@ncs# show running-config devices device bigip-a config bigip:ltm node LAMP_01 | display xpath
/devices/device[name='bigip-a']/config/bigip:ltm/node[name='LAMP_01']/address 10.128.20.104
/devices/device[name='bigip-a']/config/bigip:ltm/node[name='LAMP_01']/monitor [ icmp ]

so, what I'm trying to do is look up the node LAMP_01.  But I can't see how I choose the "ltm" tree under f5-bigip. 

When you're in config mode on NSO, you get from "config devices device bigip-a config bigip" you have to choose a direction

admin@ncs(config)# devices device bigip-a config bigip:
Possible completions:
bigip:apm bigip:asm bigip:auth
bigip:cached-show bigip:cli bigip:cm
bigip:gtm bigip:ltm bigip:net
bigip:security bigip:sys bigip:vcmp
admin@ncs(config)# devices device bigip-a config bigip:

so, unclear on how to translate this into an xpath where you go from ncs... to f5-bigip:ltm...

Any help here would be appreciated.

Thanks everyone.

Ron 

[Jan Lindblad]

I'm sure we could work out the proper xpath for this, but the problem I have is really understanding what you are trying to achieve. The leaf node_name with the link, is that a link from a service model directly to a device model? Does not sound like a good idea at all.

I think it would be good if you could take a step back and explain what it is that you want to achieve. If an xpath needs to be worked out once we understand the use case, we can do so.

[ron.whitt]

Hi Jan,

Thanks for the reply, sure thing, here is a diagram of the service.  

This is for a demo, not a production environment.  We wish to show NSO deploying an LTM service into a single f5.

I have marked in red the xpath points I wish to incorporate:

Under List: Member:

- node_name - is a reference to attached nodes, I'd like this to appear as a dropdown list

- address - these are IP address already assigned to those nodes

Uder list: Virtual:

- destination - pointer back to the "address" created under virtual-address

I've included the XML 

Thanks for any help or advice you can offer.

[Jan Lindblad]

Ok, thanks. This explanation and picture helps a lot to understand the use case.

So are all the things in the diagram configuration data a user is expected to fill in? Or would some of it be sort of read-only information displayed back to the user? Or is any of this information your provisioning application might figure out on its own without the user specifying? Assuming it's all configuration data at this point.

In the diagram, leaf node_name is listed as a leafref. This makes sense to me. In the code you showed earlier, it was modeled as a tailf:link. That is something completely different, and does not make sense here. Change it back to leafref.

With a leafref, you also need to specify the proper xpath. The simple way to get the right xpath is to run a show command in NSO, which displays the exact right names you want the leafref to point to, then pipe the result to |display xpath|display prefixes

E.g.

show running-config devices device config xx:interfaces interface name | display xpath | display prefixes

...

Is the node_name leaf supposed to point to a device in the NSO device list? If so the node_name declaration might be:

leaf node_name {

  type leafref {

    path /ncs:devices/ncs:device/ncs:name;

  }

}

In case node_name is supposed to point to something else than the device name (as known by NSO), please explain.

[ron.whitt]

Thanks Jan, Here are the answer to your questions:

1) So are all the things in the diagram configuration data a user is expected to fill in? Or would some of it be sort of read-only information displayed back to the user? Or is any of this information your provisioning application might figure out on its own without the user specifying? Assuming it's all configuration data at this point. Answer: Configuration data. All the leafrefs point to config items previously configured (not by this service). In all cases, I would like the system to present a list (drop-down) of available choices.

2) Is the node_name leaf supposed to point to a device in the NSO device list? If so the node_name declaration might be... Answer: node_name is a reference to a server under which the F5 manages as part of local traffic management. NSO does not connect to the device, so it wouldn't be in the CDB. The only device in the CDB is the F5 itself, in this case "bigip-a"

I was familiar with the show running... | display xpath, but I didn't realize you could add another display modifier to that for prefixes.

When I do that here is what I get: show running-config devices device bigip-a config bigip:ltm node LAMP_01 | display xpath | display prefixes

/ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:address 10.128.20.104 /ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:monitor [ icmp ]

So... a listing of nodes is my aim, thus .../ncs:config/bigip:ltm/bigip:node... I'll explore this and see if I can get a result. As always... great help, Jan! Thanks

[ron.whitt]

I posted a reply to this, but for some reason it got lost after I tried to edit...

Second try...

To answer your questions:

1) So are all the things in the diagram configuration data a user is expected to fill in? Or would some of it be sort of read-only information displayed back to the user? Or is any of this information your provisioning application might figure out on its own without the user specifying

Answer: The info should be config data already present.  The behavior I seek is to have the system present a drop-down with a list of available nodes.  These would be nodes previously provisioned (not by this service)

2) Is the node_name leaf supposed to point to a device in the NSO device list? If so the node_name declaration might be...

Answer: no, it's a record of managed servers which the service is adding to a record called "members".

You gave me a piece of info I didn't know.. you can add two modifiers to the show running... | display xpath | display prefix

I had only tried it with | display xpath.  Here is what that yields:

show running-config devices device bigip-a config bigip:ltm node LAMP_01 | display xpath | display prefixes
/ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:address 10.128.20.104
/ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:monitor [ icmp ]

I'm trying to get a list of nodes (i.e. LAMP_01) to appear in the drop down.  So I made this change:

65 list members {
66 description "Internal Servers members in the Pool";
67 key node_name;
68
69 leaf node_name {
70 description "Use the same node name LAMP_01";
71 type leafref {
72 path "/ncs:devices/ncs:device[ncs:name=current()/../node_ name]/ncs:config/bigip:ltm/bigip:name";
73 }}

When I make clean all on this I get this result:

$ make clean all
rm -rf ../load-dir
mkdir -p ../load-dir
/home/nsoadmin/./nso452/bin/ncsc `ls load-balancer-ann.yang > /dev/null 2>&1 && echo "-a load-balancer-ann.yang"` \
-c -o ../load-dir/load-balancer.fxs yang/load-balancer.yang
yang/load-balancer.yang:72: error: the node 'ltm' from module 'tailf-ned-f5-bigip' (in node 'config' from 'tailf-ncs') is not found

This was my original problem.  

[Jan Lindblad]

---

@ron.whitt wrote:

I posted a reply to this, but for some reason it got lost after I tried to edit...

Second try...

---

Yes, I saw that. I mean I got a mail with your message, and an error message when I clicked the link in the mail. And no article when browsing the site. Quite odd.

---

1) So are all the things in the diagram configuration data a user is expected to fill in? Or would some of it be sort of read-only information displayed back to the user? Or is any of this information your provisioning application might figure out on its own without the user specifying

Answer: The info should be config data already present.  The behavior I seek is to have the system present a drop-down with a list of available nodes.  These would be nodes previously provisioned (not by this service)

I posted a reply to this, but for some reason it got lost after I tried to edit...

When you say "config data already present", you mean the user should configure a pointer in the service that points to some existing device configuration? That would make sense, and is exactly what you should use a leafref for.

---

2) Is the node_name leaf supposed to point to a device in the NSO device list? If so the node_name declaration might be...

Answer: no, it's a record of managed servers which the service is adding to a record called "members".

You gave me a piece of info I didn't know.. you can add two modifiers to the show running... | display xpath | display prefix

I had only tried it with | display xpath.  Here is what that yields:

show running-config devices device bigip-a config bigip:ltm node LAMP_01 | display xpath | display prefixes
/ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:address 10.128.20.104
/ncs:devices/ncs:device[ncs:name='bigip-a']/ncs:config/bigip:ltm/bigip:node[bigip:name='LAMP_01']/bigip:monitor [ icmp ]

I'm trying to get a list of nodes (i.e. LAMP_01) to appear in the drop down.  So I made this change:

65 list members {
66 description "Internal Servers members in the Pool";
67 key node_name;
68
69 leaf node_name {
70 description "Use the same node name LAMP_01";
71 type leafref {
72 path "/ncs:devices/ncs:device[ncs:name=current()/../node_ name]/ncs:config/bigip:ltm/bigip:name";
73 }}

When I make clean all on this I get this result:

$ make clean all
rm -rf ../load-dir
mkdir -p ../load-dir
/home/nsoadmin/./nso452/bin/ncsc `ls load-balancer-ann.yang > /dev/null 2>&1 && echo "-a load-balancer-ann.yang"` \
-c -o ../load-dir/load-balancer.fxs yang/load-balancer.yang
yang/load-balancer.yang:72: error: the node 'ltm' from module 'tailf-ned-f5-bigip' (in node 'config' from 'tailf-ncs') is not found

This was my original problem.  

---

In order to allow references from one YANG into another, you need to import it. When it comes to importing device YANGs from service YANGs, you also need to tweak the Makefile in your package, so that the YANGPATH sees the right device YANG modules.

So in your Makefile, add (e.g. at the top of the file) 

YANGPATH += ../../<ned-name>/src/ncsc-out/modules

Then in your YANG file, add

import ned-name { prefix myned; }

Then refer to the objects in that NED as myned:foo, etc.

The XPATH expression on line 72 is no good. The expression in brackets references this leaf itself, which makes little sense. You can either skip this completely (at least to start with), in which case it will be possible to configure ltm names from any f5 device. This is better than not being able to use this model at all. If you want to fix the expression, the part after current() needs to lead to a leaf that holds the NSO device name of the f5 device you are talking about. Since that is what the equality test against /devices/device/name will be about.

Also, according to the show | display xpath output above, the correct path seems to be:

/ncs:devices/ncs:device/ncs:config/bigip:ltm/bigip:node/bigip:name

i.e. add bigip:node/ to what you had.

[ron.whitt · Accepted solution]

Hi Jan,

As always, you have the answer!  Thanks so much.

Here is the finished YANG model:

module load-balancer {
  namespace "http://com/example/load_balancer";
  prefix load-balancer;
  
// Version 5

 import ietf-yang-types { prefix yang; }
 import tailf-ned-f5-bigip { prefix bigip; }
 import ietf-inet-types { prefix inet; }
 import tailf-common { prefix tailf; }
 import tailf-ncs { prefix ncs; }

// Service Instance List
  list load-balancer {
    key name;

    uses ncs:service-data;
    ncs:servicepoint "load-balancer";

    leaf name {
      type string;
    }

    list device {
        description "Defining the target BigIP Load Balancer Information";
        key name;

        leaf name {
        type leafref { path "/ncs:devices/ncs:device/ncs:name"; }		  
	    }
      container ltm {
			
        list node {
          key name; 
          description "list of Internal Web servers nodes";
        
		  leaf name {
            type string; 
            mandatory true;
            description "Internal Node Name";
          }
		  
          leaf address {
            type "inet:ipv4-address";
	        mandatory true;
			description "IP for the node";
          }
		  
          leaf monitor {
            type enumeration {enum "icmp";}
          }
        }

      list pool {
        description "Internal Servers Pools";
        key name;
        
		leaf name {
              description "Server Pool Name";
              type string;
              }
			  
        list members {
          description "Internal Servers members in the Pool";
          key node_name;
          
		  leaf node_name { 
	        description "Use the same node name LAMP_01";
            type leafref {
		   path "/ncs:devices/ncs:device/ncs:config/bigip:ltm/bigip:node/bigip:name";
          }}
                     
          leaf port {
                  description "Web Server Port which is 'http'";
                  type enumeration { enum http; }
		  }		  
          
		  leaf address {
            type leafref {
			path "/ncs:devices/ncs:device/ncs:config/bigip:ltm/bigip:node/bigip:address";
          }}
	    }  // terminates list "members"
	  }    // terminates list "pool"

      list virtual-address {
        key name;
        description "definiting the Web Server Internal Virtual Address";
          
		  leaf name {
            description "virtual IPV4 address to use";
            type inet:ipv4-address;
          }
              
          leaf address {
            description "Virtual External IP Address xx.xx.10.xx ";
            type inet:ipv4-address;
          }  
        }
          
        list virtual {
            description "Virtual IP (VIP) Address Service";
            key name;
            leaf name {
                description "Name of th External virtual IP Address (VIP) ";
                type string;
            }
			
            leaf destination {
              description "Use Virtual Address Name under virtual-address";
			  type leafref {
			  path "/ncs:devices/ncs:device/ncs:config/bigip:ltm/bigip:node/bigip:address";
			  }}
            leaf ip-protocol {
              description "ip protocol information should be set to 'tcp'";
			  type enumeration { enum "tcp"; }
            }
			
            leaf pool {
              description "reference back to the Pool name";
              type leafref {
			  path "/ncs:devices/ncs:device/ncs:config/bigip:ltm/bigip:pool/bigip:name";
            }}
			
            leaf source-address-translation {
              description "Map the Source address to a specific destination, default automap";
              type enumeration { enum "automap"; }

            }
        }  // terminates the list "virtual"
    }      // terminates the "ltm" record
  }        // terminates the container "device"
 }         // terminates the list "load-balancer"
}          // terminates the module "load-balancer"