NSO Nano Service force commit not working as expected

[neetimit]

Nso experts,

I am trying to implement following usecase using Nano services on NSO 6.1.4: For cisco-ios devices, we want to do the tunnel interface updates in step wise manner where step 1 is shutting down tunnels where user is doing non-description updates. Once tunnels are shut then in step 2 we perform rest of the updates to the device and in the last step 3, we unshut any tunnels which were shut down in step1. 

Here is my draft yang model, the problem I am facing is that whenever I create a new service, I see that there are more than 3 commits happening and nano call back for shut tunnels is getting executed multiple times instead of only one. Since there are 3 components/states with force-commit I was expecting only 3 commits. I don't see any failures. At the end all states are in reached status. Also, if I remove force-commit from all components, then it works fine. However, I need force-commit to make sure shut tunnel completed before we proceed to tunnel updates.

Does anyone has any inputs here?

ncs:plan-outline asr1k-customer-onboard-plan {

description "Plan for deploying a asr1k customer";

ncs:self-as-service-status; // Makes the self component show when all

// components have reached the init and ready

// states

ncs:component-type "ncs:self" {

ncs:state "ncs:init";

ncs:state "ncs:ready";

}

ncs:component-type "eobNanoServicePOC:asr1k-shut-tunnels" {

ncs:state "ncs:init";

ncs:state "eobNanoServicePOC:shut-tunnels" {

ncs:create {

// Invoke a Java callabck template to check updates safety and apply service

ncs:nano-callback;

ncs:force-commit;

}

}

ncs:state "ncs:ready";

}

ncs:component-type "eobNanoServicePOC:asr1k-cust-onboard-service" {

ncs:state "ncs:init";

ncs:state "eobNanoServicePOC:service-configuration" {

ncs:create {

// Invoke a Java callabck template to check updates safety and apply service

ncs:pre-condition {

ncs:monitor "$SERVICE/plan" {

ncs:trigger-expr "component[type='eobNanoServicePOC:asr1k-shut-tunnels']" +

"/state[name='ncs:ready'][status='reached']";

}

}

ncs:nano-callback;

ncs:force-commit;

}

}

ncs:state "ncs:ready";

}

ncs:component-type "eobNanoServicePOC:asr1k-unshut-tunnels" {

ncs:state "ncs:init";

ncs:state "eobNanoServicePOC:unshut-tunnels" {

ncs:create {

ncs:pre-condition {

ncs:monitor "$SERVICE/plan" {

ncs:trigger-expr "component[type='eobNanoServicePOC:asr1k-cust-onboard-service']" +

"/state[name='ncs:ready'][status='reached']";

}

}

// Invoke a Java callabck template to check updates safety and apply service

ncs:nano-callback;

ncs:force-commit;

}

}

ncs:state "ncs:ready";

}

}

ncs:service-behavior-tree asr1k-nano-poc-servicepoint {

description "Two components for 1 customer device pair";

ncs:plan-outline-ref "eobNanoServicePOC:asr1k-customer-onboard-plan";

ncs:selector {

// Self component is here used to keep track of the other components

ncs:create-component "'self'" {

ncs:component-type-ref "ncs:self";

}

// service component for device customer pair

ncs:create-component "'shut-tunnels'" {

ncs:component-type-ref "eobNanoServicePOC:asr1k-shut-tunnels";

}

ncs:create-component "'asr1k-cust-onboard-service'" {

ncs:component-type-ref "eobNanoServicePOC:asr1k-cust-onboard-service";

}

ncs:create-component "'unshut-tunnels'" {

ncs:component-type-ref "eobNanoServicePOC:asr1k-unshut-tunnels";

}

}

}

[snovello]

Hello,
from your description, I was expecting to find a nano service with a single component + self component. That one component would have 3 states, without any preconditions, and of course with the force-commit. The component just goes through its 3 states. I can see how your implementation works but it is very complex to have 3 components and preconditions, when actually you have one service component that should just go through a sequence of states.

The general rule for components in a service is they should be an item that can be provisioned independently. For example, if you have 2 tunnels to create a bidirectional service then they would be 2 components, or a VPN would have a component per endpoint.

Do not be surprised if you see your nano-create code called multiple times. The way a nano-service works is by calling re-deploy on the service, but if you are doing 3 steps it should be enough to have 3 commits.

Your design deals with the create case but I don't see a mechanism to ensure that on modify, you always shutdown the interface before applying changes. To do that you could have a version leaf (config false) that you increment every time the service reaches the final state (in the post call). Use the version number in the name of the component in the plan. So each time you reach completion and then redeployment happens because you make a change, the component has a new name and so has to start from scratch. The examples included in NSO show how to use variables in the name of a component.

That post modify callback would need to read the plan and ensure the last stage is reached, because it is called on every re-deploy even though the last stage of the plan may not have been reached.

When developing nano-services always turn on progress trace, in a verbose mode to see all the calls and kickesr.

In your case you are also very interested in ensuring the right sequence of provisioning, so shutting the tunnel before making changes - that is visible in the device trace.