10-01-2018 05:05 AM
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.
Solved! Go to Solution.
10-01-2018 05:14 AM
10-01-2018 05:31 AM
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.
10-01-2018 05:14 AM
10-01-2018 05:31 AM
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.
10-01-2018 06:22 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide