Solved: Re: impact of various changes in our service packages

Stefan Marcin · ‎07-13-2021

One of the key features of NSO is that service package code can be modified or updated and the configuration diff is automatically calculated by FASTMAP and applied to the devices. This works most of the time, however there could be some edge cases which may impact the running VNF which is not desirable.

I am wondering if there is some list of known issues, when you change something in one of those parts:

various changes in the YANG file
changes in the XML configuration templates
Python code changes
DAY0, DAY0.5 and DAY1/DAY2 configuration changes

What changes would cause re-deploy issues and what do not ?

rogaglia · ‎07-13-2021

Hi Stefan,

The answer to such a question will always be "depends" and I believe yours is a great point on why automation of testing is so important to make sure that you have good testing coverage against package changes.

One other interesting things about NSO:

1- The sysyem has a number of warning signs pre-built (of course it does not cover all possibilities of what can go wrong) such as:

package reload: without "force" will warn you if there is some suspicious constructs such as deleting leafs or others.
when doing "re-deploy" for a service with a new package version, you can dry-run the re-deploy

2- If you have detected that the new package version will change something in the existing service instances, NSO has an "upgrade" API that allows you to perform changes in your CDB as the upgrade process goes forward.

In the NFV domain in particular, I would be careful if your upgraded package has changes to the NFVO API. That is particularly sensitive because not all VNFs react well to changes. The good thing is that you can test it and dry-run it.

View solution in original post

rogaglia · ‎07-13-2021