From the developer guide about data kickers
No distinction is made between configuration and operational data.
However when I attempt a nano service using ncs:monitor to monitor an operational leaf, I can't get the kicker to trigger when that operational leaf is updated.
nano-service.yang
module nano-service {
namespace "http://com/example/nanoservice";
prefix nano-service;
import ietf-inet-types {
prefix inet;
}
import tailf-ncs {
prefix ncs;
}
import tailf-common {
prefix tailf;
}
identity nano-component {
base ncs:plan-component-type;
}
identity nano-template {
base ncs:plan-state;
}
ncs:plan-outline nano-plan {
ncs:component-type "ncs:self" {
ncs:state "ncs:init";
ncs:state "ncs:ready";
}
ncs:component-type "nano-component" {
ncs:state "ncs:init" {
ncs:create {
ncs:pre-condition {
ncs:monitor "$SERVICE" {
ncs:trigger-expr "oper-status='OK'";
}
}
}
}
ncs:state "nano-template" {
ncs:create {
ncs:nano-callback;
}
}
ncs:state "ncs:ready";
}
}
ncs:service-behavior-tree nano-service {
ncs:plan-outline-ref nano-plan;
ncs:selector {
ncs:create-component "self" {
ncs:component-type-ref "ncs:self";
}
ncs:create-component "nano-component" {
ncs:component-type-ref "nano-service:nano-component";
}
}
}
list nano-service {
key name;
uses ncs:nano-plan-data;
uses ncs:service-data;
ncs:servicepoint "nano-service";
leaf name {
type string;
}
leaf-list device {
type leafref {
path "/ncs:devices/ncs:device/ncs:name";
}
}
leaf oper-status {
config false;
type enumeration {
enum "NOT OK";
enum "OK";
}
tailf:cdb-oper {
tailf:persistent true;
}
}
}
}In NCS CLI
admin@ncs% set nano-service test device iosxr0
[ok][2019-10-07 16:32:34]
[edit]
admin@ncs% commit | debug kicker
2019-10-07T16:32:39.307 kicker: internal at /kicker:kickers changed; invoking {kicker_server,
kicker_data_changed,[]}
Commit complete.
[ok][2019-10-07 16:32:39]
[edit]
admin@ncs% unhide debug
[ok][2019-10-07 16:32:47]
[edit]
admin@ncs% show kickers
data-kicker "pre-condition: /nano-service:nano-service{test}/plan/component{nano-service:nano-component \"\"}/state{ncs:init}" {
monitor $SERVICE;
trigger-expr oper-status='OK';
variable PLAN {
value /nano-service[name='test']/plan;
}
variable SERVICE {
value /nano-service[name='test'];
}
variable ZOMBIE {
value "/ncs:zombies/ncs:service[ncs:service-path=\"/nano-service[name='test']\"]";
}
kick-node /nano-service:nano-service[nano-service:name='test'];
action-name reactive-re-deploy;
}
[ok][2019-10-07 16:32:49]
[edit]
admin@ncs% run show nano-service
POST
BACK ACTION
TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS
-------------------------------------------------------------------------------------------------
self false - init reached 2019-10-07T16:32:39 - -
ready reached 2019-10-07T16:32:39 - -
nano-component false - init not-reached - - -
nano-template not-reached - - -
ready not-reached - - -
[ok][2019-10-07 16:32:58]
[edit]
admin@ncs% run show nano-service oper-status
OPER
NAME STATUS
--------------
test -
[ok][2019-10-07 16:33:12]
[edit]
admin@ncs% run show nano-service oper-status
OPER
NAME STATUS
--------------
test OK
[ok][2019-10-07 16:33:16]
[edit]
admin@ncs% run show nano-service
POST
BACK ACTION
TYPE NAME TRACK GOAL STATE STATUS WHEN ref STATUS
-------------------------------------------------------------------------------------------------
self false - init reached 2019-10-07T16:32:39 - -
ready reached 2019-10-07T16:32:39 - -
nano-component false - init not-reached - - -
nano-template not-reached - - -
ready not-reached - - -
oper-status OK
[ok][2019-10-07 16:33:19]To set oper-status I'm using the following command
$ ncs_cmd -c "dbset operational; set /nano-service{test}/oper-status OK"I found https://community.cisco.com/t5/nso-developer-hub-discussions/understanding-kickers/td-p/3890298 that mention kickers may depend on how the operational data is set but doesn't go into any details.
I was expecting the kicker to pick up the change and reactive-re-deploy the service but instead it's stuck. Is there something I'm missing in the configuration or how kickers or nano-services work?
Thanks
/Diddi
