Reflect service variables which are set through code (Python/Java) in the WebUI

[ian.scheidler1]

Hi.

I have a VPN service which gathers some input from the User. This is reflected in YANG model and when the values are set they are reflected in the WebUI when I view/open the service instance.

Nevertheless there are also some variables which are filled from the service's python code (e.g. gathering values from 3rd party systems). How can I make these values visible when I open the service instance in the WebUI?

I had tried adding them as input fields (leafs) to the YANG model and thought it might be reflected as long as I use the same variablenames (code variable names=leaf names in YANG) in my code. Unfortunately that is not the case.

So how can I have all service parameters relfected in the WebUI (both user input AND "calculated" parameters from my Python code?

Thanks in advance for the help.

[vleijon · Accepted solution]

Hi Ian.

Unfortunately there is no automated reflection. The easiest way is to set them as operational data. Here is an example from a service I created.

1. Add an operational field to your model:

leaf vni-id {
type uint32;
config false;
tailf:cdb-oper {
tailf:persistent true;
}
}

2. Set it from your create code using maagic, so that in python you do something like

service.vni_id = 400


This turns up to me in the webui.

-Viktor

[Jan Lindblad · Accepted solution]

For reasons I don't completely understand, I haven't seen people doing this a lot. Personally, I have found this pattern useful a couple of times.

The way to go is to model your computed values as config false, and have your service code provide the values for the oper leaf(s). You can either do that as a dataprovider with a callpoint, but this is a bit tedious, so I would recommend going with the other approach -- to store the state data in CDB, i.e. mark it as tailf:cdb-oper.

Let's say you wanted to expose the allocated-vlan-id of some vlan. The service model could look something like this:

list myservice {

...

  uses ncs:service-data;

  ncs:servicepoint myservice;

  leaf allocated-vlan-id {

    type uint32 { range 1..4094; }

    config false;

    tailf:cdb-oper;

  }

}

Then in your create() method (or in any code you have, really), you simply write the value you want to the service.allocated_vlan_id. Since this is operational data, it lives outside any transaction, and anything you write will stick immediately, no matter what happens with the transaction. As a consequence, you need to think through when you update this data, and for example not write it in a dry-run scenario.

[ian.scheidler1]

Thanks for the reply. That already helps a lot.
How can I identify in my code whether someone used "commit" or "commit-dry-run", so that I can act accordingly in my code?