NSO with pyATS

[crench92]

I'm wondering in what ways I can tie in pyATS when making configuration changes or deploying services with NSO.  Is there a way to tie in this platform before making a change and after making a change to verify changes are made successfully? Rollback changes when pyATS determines issues occurred or is there a way to do this natively within NSO?

[rogaglia]

Hi,

Interesting question!

The answer would be "depends" on how are you using PyATS. For example, one of the things PyATS does is to give you a model on top of Cisco's different CLIs to facilitate tests. This is something that may interest you to test the devices directly even for NSO target configurations.

What I did test in the past is that PyATS is evolving to support NETCONF. In this sense, you could have PyATS to call NSO for test automation using our NETCONF/YANG API for either service or device modules.

Finally, a number of our customers also integrate NSO towards the ROBOT testing framework: https://robotframework.org/

(Cisco CX services can eve help you in this environment).

All in all, you can use the NETCONF support in PyATS to connect to NSO and automate your service tests but you can also use other frameworks.

[crench92]

So we haven't implemented NSO or pyATS yet.  I'm trying to figure out how to ensure that when NSO makes a configuration change on the network, tests are run before and after to ensure everything is stable.  pyATS in this use case will not interact with the devices in a write fashion at all, only a read capability to gauge how successful the change was.  If this is covered in some way in NSO, great.  I'm just trying to figure out what an appropriate test platform should be and how to use it around NSO.

[vleijon]

It is a very relevant question. You are talking about a post-check/pre-check/self-test. I think that pyATS could definitely play a role there. I have seen people talk about it in the past, but I have never seen it integrated like that. Maybe someone else knows?

[snovello · Accepted solution]

Just for the mechanics of triggering tests after a service is implemented, or sometimes you need to do some tests in the middle, before you configure the next step of a service

In the developer manual the chapter on nano services covers this. It’s the most complete framework for doing this in NSO
https://developer.cisco.com/docs/nso/guides/#!nano-services

For many simple use cases kickers will also work
https://developer.cisco.com/docs/nso/guides/#!kicker

In addition there is a very simple to use package to just express some self tests in the template of a service, these can then be easily triggered using the kickers
https://github.com/NSO-developer/selftest

[crench92]

Did some digging and found these 2 posts:

https://community.cisco.com/t5/nso-developer-hub-discussions/nso-service-template-pre-and-post-check/td-p/4278041?force_isolation=true

https://community.cisco.com/t5/nso-developer-hub-discussions/when-to-use-pre-post-modification/td-p/3853225?force_isolation=true

It looks like there are pre and post mod decorators I can use but it looks like this isn't recommended for operations that take awhile since this would be within the transaction lock but maybe this is where pyATS could be integrated within the service python code itself?

[vleijon]

You can but it isn’t super recommended. I would say that the recommended way is to do it as a nano-serivce with the pyats callout as what is called a post-action. I wish I had a good demo of this, maybe something we should look into. Here is an older example of a self-test: https://github.com/NSO-developer/selftest

[snovello]

These pre and post -modification callbacks are inside the transaction lock, they are for making changes to the database which will not be considered as part of the service.

Typical pre- examples
A service allocates a value from a resource pool, the pool is created on demand in pre- when the service is deleted the pool remains in place
A service assumes the existence of a fixed piece of config that should be part of day1 on all devices, for robustness it will create it in pre- and again if service is removed that config will not be removed

Typical post- example
Service is removed, and you have to do some explicit cleanup. For example the service configures a physical port that needs to be reliably left in a clean state when service is removed. That cleanup can be done in post- the default service removal removes all the service config and puts any overwritten values back to the state they had before the service was implemented, so if you want all ports with no service to be shut down and have no description, but choose to not enforce that a service may only be implemented on such a port, then you will want to enforce it on service removal in the post- callback.