cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
775
Views
0
Helpful
1
Replies

How to detect changes to device-groups in my service

I'm developing a service that uses a leaf-list of references to /devices/device-group to decide the list of devices to apply to.

 

Dereferencing these in the template works just fine.

But, after my service instance is created, any changes that only touch a device-group (i.e. adding / removing a device-name) do not seem to trigger FASTMAP for my service. The template does not get applied to the new effective list of devices. If I have a Python cb_create, that doesn't get called either.

 

Is there a workaround for this kind of thing, in YANG / templates / code? How do I detect changes on a part of the config tree that's not a subtree of my service, and then re-run create() / the service template?

 

Thank you in advance for your help.

 

 

<config-template xmlns="http://tail-f.com/ns/config/1.0">
<devices xmlns="http://tail-f.com/ns/ncs">
<?foreach {/device-group}?>
<device>
<name>{deref(.)/../member}</name>
...
 
augment /ncs:services {
description "Service Configuration";

list my-service {
...
leaf-list device-group {
type leafref {
path "/ncs:devices/ncs:device-group/ncs:name";
}
description "Device groups to apply this to";
}
 
 
1 Accepted Solution

Accepted Solutions

rogaglia
Cisco Employee
Cisco Employee
NSO is “working as design”.

You should try to “redeploy” your service once you change your device-group membership.

Regarding your question: “How do I detect changes on a part of the config tree that's not a subtree of my service, and then re-run create() / the service template?”, you should check the NSO_Developer guide on something called “Kickers”. Basically, you subscribe to changes in the try and automatically apply a “reactive-re-deploy”.

View solution in original post

1 Reply 1

rogaglia
Cisco Employee
Cisco Employee
NSO is “working as design”.

You should try to “redeploy” your service once you change your device-group membership.

Regarding your question: “How do I detect changes on a part of the config tree that's not a subtree of my service, and then re-run create() / the service template?”, you should check the NSO_Developer guide on something called “Kickers”. Basically, you subscribe to changes in the try and automatically apply a “reactive-re-deploy”.