cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
480
Views
0
Helpful
3
Replies
Stefan Marcin
Beginner

impact of various changes in our service packages

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 ?

1 ACCEPTED SOLUTION

Accepted Solutions
rogaglia
Cisco Employee

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

3 REPLIES 3
rogaglia
Cisco Employee

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

Hi, thanks, we had also internal discussion about this, we are going to perform some testing also based on "service update" section in NSO 301 guide, where there couple of scenarios explained, e.g. changing leaf types, testing xml changes if VNF will be redeployed, etc.

alexstev
Cisco Employee

 

Hi @Stefan Marcin, I hope you saw this response!