12-11-2023 07:49 AM
I have two services: A and B with yang model like below:
A:
list A-list {
key name;
leaf name { type string; }
leaf state { type string; }
}
B:
list B-list {
key name;
leaf name {type string;}
...
uses ncs:service-data;
ncs:servicepoint B-servicepoint;
}
In service B python code I'd like to set a kicker on /A-list/state and I only want B to be triggered/redeployed once as there may be a thousand elements in B-list. Is there a way to achieve this?
12-11-2023 08:18 AM
Hi, I think it should be possible with a trigger-expression (see "Kicker Constraints/Filters" in https://developer.cisco.com/docs/nso/guides/#!kicker/data-kicker-concepts). I never used it, so I have to look at it myself before I can post an example. But I hope it helps as a startingpoint anyway.
12-11-2023 10:17 AM
Hmm, actually I do have trigger-expression set to 'up' to monitor a new element of A coming up. Currently I set the kick-node to /B-list and action-name as 're-deploy', and this will redeploy B as many times as the number of elements in B-list which is inefficient.
12-11-2023 10:31 PM
I think we just need the correct xpath in the trigger expression. Can you post the actual yang model with your two lists as well as the current kicker config (show full-configuration kickers)?
12-12-2023 03:21 PM
pcl-svc.yang:
list pcl {
key name;
leaf name { type string; }
leaf state { type string; }
…
}
node-svc.yang:
list node {
key name;
leaf name {type string;}
…
uses ncs:service-data;
ncs:servicepoint node-svc-servicepoint;
}
node-svc main.py:
class NodeServiceCallback:
def cb_create(self, tctx, root, service, proplist):
kicker = root.kicker__kickers.data_kicker.create(“node—{service.name}-pcl-kicker")
kicker.monitor = "/pcl/state"
kicker.trigger_expr = ". = ‘up’”
kicker.trigger_type = "enter"
kicker.kick_node = “/node”
kicker.action_name = 're-deploy'
# more processing
class Main(ncs.application.Application):
def setup(self):
self.register_service(‘node-svc-servicepoint’, NodeServiceCallback)
12-12-2023 10:50 PM
Ok now I understand the problem.
The trigger expression is evaluated against the monitor tree - what would be needed is kind of a trigger expression evaluated against the node tree. I don't know if this is possible.
12-13-2023 10:18 AM
Thanks for helping me to clarify my question.
12-13-2023 01:36 AM
There is unfortunately no straight forward way to achieve this.
So you're monitoring the state leaf, and you use that for your trigger expression. With this said, I think it makes sense for the kicker to trigger once for each list element, since the trigger expression has to be evaluated for each list element. What would happen for instance if you add one list element with state = up and one with state = someting else. Should that trigger the kicker or not? I'm guessing that you want the kicker to trigger only once if there are any list elements added/modified with state = up.
You could wrap your list in a container and monitor that container. Something like this:
container pcl {
list pcl {
key name;
leaf name { type string; }
leaf state { type string; }
…
}
}
If you monitor the container, you'll get one action invocation for each modification per transaction, regardless of the number of list elements. You wouldn't be able to filter on the state value though, but suppose you'd still get less re-deploys than what you get now.
12-13-2023 04:14 AM
Or if the pcl list is mapped to the node list, so that they have identical key names, and that each element in the pcl list represents the element with the same key in the node list, then you could design your kicker in such a way where an update to a certain pcl list element only re-deploys the service with the same key name in the node list. You might find the example in examples.ncs/getting-started/developing-with-ncs/21-kicker useful for this case.
12-13-2023 10:17 AM
Actually this is what I want to achieve: if an element's state in pcl changes to 'up', the kicker is expected to fire off. It's impossible to map element in pcl to node because there may be hundreds of node element while only single digit number of pcl. It'll be inefficient to redeploy node-svc hundreds of times when an element's state in pcl changes from down to up, I'd like to redeploy once and in cb_create loop through all nodes, assuming it's more efficient. I wonder if wrapping list node in a container and move the servicepoint out of the list will work.
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