11-29-2017 09:15 AM - edited 03-01-2019 04:03 AM
Hi NSO experts!
Considering the following model:
list device {
key "reference";
leaf reference {
type string;
}
uses ncs:service-data;
ncs:servicepoint sp;
leaf group {
type string;
}
...
}
If two devices are added to the list with the same "group" value then I want my RFS to add additional common configuration to both of them. If a device is removed so the peer device remains alone in the group, I want the additional configuration to be removed from both devices.
What's the best way to perform this?
Thanks,
Sylvain
Solved! Go to Solution.
11-30-2017 04:39 AM
If two devices are added to the list with the same "group" value then I want my RFS to add additional common configuration to both of them. If a device is removed so the peer device remains alone in the group, I want the additional configuration to be removed from both devices.
What's the best way to perform this?
This is easy to achieve with a bit of Python or Java. The way you model it here, however, the code would have to scan all service instances. If this service scales to a lot of instances, that would take a bit of CPU. If instead you modeled leaf group as a leafref to the other device, the search would not be needed and you could also use this "XPATH bridge" to cross over to the other device in your template.
Is there any way from a Java RFS to force the redeployment of another instance of the service, so each device looks for possible peers, and updates itself only?
Yes, but you would need an intermediary (subscriber, kicker, etc) because you can't start a new transaction (which redeploy does) while you are in the RFS create() code.
Yes. What you need is some element in the service YANG that points to some location in the YANG tree from where you can navigate to the desired data using a relative path. For example, modeling the leaf group as a leafref to the other device, or as a leafref to a group list, which in turn has leafrefs to both/all the members would do it.
You could also implement a leaf the-other-device { type leafref { ... } } backed by a data provider that points out which device this one is paired with (if any). Then the template could simply use {/the-other-device/...} to access the other device. This data provider approach sounds like more work than the above, tho.
I guess I could attach the servicepoint at the parent level, so the callback would be triggered for any change, and loop over all devices, but this looks like an expensive operation in case there are many devices.
Yes. And the semantics would change from N service instances to a single one. Probably not a good idea.
I would prefer avoiding adding a leaf to the device model to track this, because I don't want this flag to be visible and/or changeable by anything else than the RFS code.
Well, if you model the leaf group as I suggested, the solution would be simple, straight forward and efficient. If you want to keep group as a string (and scan all service instances) then you need some variant of the data provider approach.
11-30-2017 04:39 AM
If two devices are added to the list with the same "group" value then I want my RFS to add additional common configuration to both of them. If a device is removed so the peer device remains alone in the group, I want the additional configuration to be removed from both devices.
What's the best way to perform this?
This is easy to achieve with a bit of Python or Java. The way you model it here, however, the code would have to scan all service instances. If this service scales to a lot of instances, that would take a bit of CPU. If instead you modeled leaf group as a leafref to the other device, the search would not be needed and you could also use this "XPATH bridge" to cross over to the other device in your template.
Is there any way from a Java RFS to force the redeployment of another instance of the service, so each device looks for possible peers, and updates itself only?
Yes, but you would need an intermediary (subscriber, kicker, etc) because you can't start a new transaction (which redeploy does) while you are in the RFS create() code.
Yes. What you need is some element in the service YANG that points to some location in the YANG tree from where you can navigate to the desired data using a relative path. For example, modeling the leaf group as a leafref to the other device, or as a leafref to a group list, which in turn has leafrefs to both/all the members would do it.
You could also implement a leaf the-other-device { type leafref { ... } } backed by a data provider that points out which device this one is paired with (if any). Then the template could simply use {/the-other-device/...} to access the other device. This data provider approach sounds like more work than the above, tho.
I guess I could attach the servicepoint at the parent level, so the callback would be triggered for any change, and loop over all devices, but this looks like an expensive operation in case there are many devices.
Yes. And the semantics would change from N service instances to a single one. Probably not a good idea.
I would prefer avoiding adding a leaf to the device model to track this, because I don't want this flag to be visible and/or changeable by anything else than the RFS code.
Well, if you model the leaf group as I suggested, the solution would be simple, straight forward and efficient. If you want to keep group as a string (and scan all service instances) then you need some variant of the data provider approach.
11-30-2017 12:49 PM
Hi Jan,
Thanks a lot for your reply.
Jan Lindblad a écrit:
Yes. What you need is some element in the service YANG that points to some location in the YANG tree from where you can navigate to the desired data using a relative path. For example, modeling the leaf group as a leafref to the other device, or as a leafref to a group list, which in turn has leafrefs to both/all the members would do it.
Could you elaborate a little bit more on this?
In this scenario:
=> In 2., when running Template.apply(), how to force this configuration to backreference device A instead of device B? I tried to build a customer ServiceContext referencing device A's node, but FastMap still creates the backreference pointing to B.
This is just to get to the bottom of it, I got that the easiest option would be to build a list of the groups with references to the devices.
Thanks again,
Sylvain
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