NED Development: Reference NED live-status data in Generic NED command

[Johan Nemitz]

I have built a NED for VIRL as a learning exercise (find it here if interested).  It can populate the running simulations in the virl device's live-status tree.  What I would like to do is have my Stop-Simulation action be able to reference the live-status tree so that in the CLI the choices available are restricted to the simulations currently running on the device.  However, when compiling, no matter how I tried to make the path in the leafref resolve, I couldn't get it to compile.  Should I be able to do this?

I get the following error or some variation depending on how I set the path in the leafref:

error: the path has too many '..'

Here is a snippet of what is in my cisco-virl-stats.yang file:

module cisco-virl-stats {
...
  container simulations {
    config false;
    list simulation {
      key "name";
      leaf name {
        type string;
      }
...
}

Here is what is in my cisco-virl:

module cisco-virl {
  identity cisco-virl-id {
    base ned:generic-ned-id;
  }
...
  container commands {
    tailf:action Stop-Simulation {
      tailf:actionpoint ncsinternal {
        tailf:internal;
      }
      input {
        leaf simulation-name {
          mandatory true;
          type leafref {
            path "../../../../ncs:live-status/cisco-virl-stats:simulations/cisco-virl-stats:simulation/cisco-virl-stats:name";
          }
        }
      }
      output {
        leaf result {
          type string; 
        }
      }
    }
...
}

[Jan Lindblad]

A leafref from an action to some oper data is fine. Unless you have lots of VIRL instances, an absolute path would probably be easier to write. When working with relative paths in YANG, remember that not all "YANG indentation levels" count, e.g. "input { }" does not correspond to a ".." level; it's a "meta" keyword that isn't visible in the XML.

Another thing I find odd with the YANG below is that you specify the callpoint name "ncsinternal" and even set the tailf:internal flag. I don't suppose you're merging your action code into the NSO sources, so pick another callpoint name, and don't use that internal flag. Then write some callpoint implementation in python or java that registers the name you picked.

[Johan Nemitz]

I didn't understand the meta-data concept, thanks for that but I am still not having success.  So then, given that my NED (and this is a NED not a NSO service I am working with here, I might not have clearly explained that) command ends up in /devices/device/config/commands/Start-Simulation (I would really like it to end up in /devices/device/Start-Simulation but I could figure a way to get the ncsc to make that happen), how many levels up do I need to go to get to /devices/device - so that I can then traverse down the live-status branch?  I have included the entire module for completeness below.

Your other question about the ncsinternal.  It was my understanding that if this is a NED that I am writing one needs to use it so that the NedGenericBase.command() is called when it is executed.  Is that not correct?  And if so, what is the proper way to do it?

module cisco-virl {

  namespace "http://com/example/ciscovirl";
  prefix cisco-virl;

  import tailf-ncs-ned { prefix ned; }
  import tailf-common { prefix tailf; }
  import tailf-ncs { prefix ncs; }
  import cisco-virl-stats { prefix cisco-virl-stats; }

  identity cisco-virl-id {
    base ned:generic-ned-id;
  }

  container commands {
    tailf:action Stop-Simulation {
      tailf:actionpoint ncsinternal {
        tailf:internal;
      }
      input {
        leaf simulation-name {
          mandatory true;
          type string;
//          type leafref {
//            path "../../../ncs:live-status/cisco-virl-stats:simulations/cisco-virl-stats:simulation/cisco-virl-stats:name";
//          }
        }
      }
      output {
        leaf result {
          type string; 
        }
      }
    }
  }
}

[Jan Lindblad · Accepted solution]

Ah, I see. Never guessed this was a device YANG since you were importing tailf-ncs. That will not work in NED YANGs.

When compiling device bundle YANGs, the compiler will insert those tailf:action, tailf:actionpoint etc in the NED YANG. I don't think ncsc will appreciate that you're doing it too ;-) And you can't refer to anything outside the NED (e.g. the device list) when you do this.

To do what you're trying to do, I think a plain NSO YANG (not NED YANG) file that augments /devices/device with your action is what you want. This way, you don't even need to provide the path to the VIRL as input, since the action will be invoked on the VIRL instance directly. Don't use tailf:internal when you do this.

The thing I tried to say re the xpath and input keyword was simply that you might need fewer ../ in your path. How many I can only tell if you provide the full YANG. If you change your design as I suggested now, however, you won't need the path there at all here.

[Johan Nemitz]

Thanks Jan. That makes sense and I will give that a try.

[rogaglia]

Hi,

Very cool idea. Do you think you can publish in the NSO Dev. Hub git repository?

Regarding your error, I am not sure I understand what you are intending to do. Looks to me that you want to reference from an action input something that is not in CDB but that you actually have to execute via live-status. I think you are asking too much of YANG and NSO here. I would recommend you to validate this input inside your action code.

Regards,

Roque

[Jan Lindblad]

NSO and YANG should handle this fine, once the path is corrected. References to live-status may take a couple of seconds to resolve, but if the device is reasonably responsive, I think this can work fine.

[Johan Nemitz]

HI Roque,

Thanks for the tip.  I will publish as soon as I am feeling it is ready.

Johan