I developed a fairly simple Loopback interface service. If I create a service instance the configuration is applied to the router. If I change the configuration of the device via NSO cli the configuration will change after the commit and the sync check of the Loopback service will fail as I expected. I would like to prevent that somebody will break a service due to missconfiguration. Unfortunately there will be manual and service configurations in my case .
Is it possible to lock certain Parts of the configuration for manual changes?
Is there a easy way to see which parts of the configuration is managed by a service? I found that this is possible via displaying the refcount in the configuration.
Generally, having two systems (operator and NSO here) doing overlapping configuration is not a good idea. There should be clear demarcation of the configuration space that is being touched by each.
Sometimes the operators may have to scribble stuff to resolve highly critical issues and they might have very short time to get things working.. This is when, after the fact, NSO can help check which service instances have gone out-of-sync and help with the reconciliation. Bring service configs back into policy.
You could explore NACM rules and have different users for service/manual configuration. Not sure if that will help. However, best to have clear demarcation of the config space.
Hank Preston and Jason Belk presented at Network Field Day 23 to a network engineer audience. Jason shared his personal journey from network engineer to automation evangelist, and how Cisco Network Services Orchestrator (NSO) drew him deeper into automati...
Step 1 : configure debug server in Pycharm
Go to Run => Edit Configurations, click on "+" => Python Remote Debug
In "Local Host name " enter ip or host name of your local machine. Enter a available port in "Port :"
Give a name, here it's "NSO debug...
Abstract: RFM services can be hard to implement. Especially the lifecycle management of the delete case of the service can be a challenge. Nano Services uses an executable plan and kickers to supports the full lifecycle of a RFM service.
Previous instalments of this blog post series have covered requirements (parts I and II) and baselining, profiling/optimising and monitoring (part III). In this final part we will discuss some architectures you may want to consider as your system grows in...