Help Needed: Resetting PortConfiguration to Default State on Nokia7750

[PrashantSharma-Dev]

Hi everyone,

I have created a Python + Template XML based Cisco NSO service package to automate port configuration on a Nokia 7750 SR router's physical port. The service package works well for configuring the ports, but I am facing challenges with the cleanup process when deleting the service instance.

Objective: When I delete the service instance for port configuration, I need the port to be brought back to its default settings (maybe by using a secondary template XML file for cleanup purposes). I tried applying the secondary template file using ncs.maagic API (service = get_node(trans, kp)). 

Challenges Faced:

1. Accessing Service Instance Details During Deletion:

   • When attempting to access service instance details during the pre-modification phase, I encounter a KeyError because the service instance is already marked for deletion and is not fully accessible.
   • Error log:

     <INFO> - Pre-modification: Delete operation detected. Extracting PORT_ID and device name...
     <INFO> - An error occurred while extracting PORT_ID and device name: '{port_conf_1} not in /ncs:services/test_port_configuration:test_port_configuration'

2. Storing and Retrieving Details:

   • Attempted to store PORT_ID and device name during the creation phase and retrieve them during deletion, but the details were not found during the deletion phase

Request for Help:

• How can I effectively reset the port configuration to its default state during the service deletion process?
• Is there a better approach to store and retrieve the necessary details (PORT_ID and device name) for the cleanup?
• Any examples or best practices for implementing NSO actions for such cleanup tasks?

Any guidance or suggestions would be greatly appreciated!

Thank you in advance for your help!

Best regards, 

Prashant

[Jesus Illescas]

I'm not an expert on the topic, but If I were creating the service to reset the ports, I would use a post_modification callback and pass the PORT_ID or any other data as a persistent opaque (proplist in python).

See the service callbacks available here https://cisco-tailf.gitbook.io/nso-docs/development/advanced-development/developing-services/services-deep-dive#ch_svcref.cbs there you can find types and arguments.

A bit below you can find the persistent opaque data https://cisco-tailf.gitbook.io/nso-docs/development/advanced-development/developing-services/services-deep-dive#ch_svcref.opaque what it is and how they are.

Lastly, the BU recently published the NSO collection examples in Github, here you can find an example that does something very similar to what you want, but using post-modification callback along with the persistent opaque data using proplist.

This example includes a service, iface, that uses the post-modification functionality to deploy a default configuration to an interface, once the service is removed. This configuration ensures the interface is shut down and configured with an unused VLAN (here VLAN number 2).

https://github.com/NSO-developer/nso-examples/blob/6.4/service-management/iface-postmod-py/README.md

Following the example logic, you could have a second xml template that will apply the default settings to the port.

[Jesus Illescas]

One addition to my previous response, in some platforms you have a command to remove any existing configuration from an interface and leave the default settings. In IOS-XR you have for example: "default interface" command which will remove any config and set the defaults. Check if you have a similar command in Nokia. If there is a similar command in Nokia and is not available in your NED, open a ticket requesting that command to be added. It will be much simpler to reset a port this way.

[snovello]

The way NSO works when removing a service, is to return the configuration in the areas touched by the service to what it found previously. So if you want to be sure to return the configuration to a speciffic state when you delete a service, one approach is to make sure to have that state of the configuration at the point when you create the service.

One way to do that is the pre-modification callback (or pre-modificaion template), in case of creation, you would have that template configure how you want it to be when the service is deleted.

Then the create callback will overwrite that state with the service configuration, and when you delete the service you will see the configuration returned to the config in the pre-modification template.

In the template, you will probably use tags=replace or  tags=create because the default tags=merge will not remove existing configuration. Note this setting of the configuration is all happening only within the transaction, so will not be visible externally. Since you are controlling the configuration you are not limited to a default configuration, for example this would be a way to ensure an interface was left with a description saying it is unused after the service was removed.

One thing to keep in mind with this approach, is that if there were configurations within the structures touched by the service (in your case the interface) which are not managed by the services, than your pre-modification template, particularly if using tags=replace, will remove those extra configurations.

I would say maintaining such configurations that are not managed by the service but are in the scope of the objects configured by the service would be the only reason to try and set the default state at the point of removal. The reason to avoid doing things at the point of removal is of course that it is complicated by the fact that all the service data is gone when your code is called. Nano-services can help here, because you can have callbacks after the service is removed, and the whole of the service data is copied into a separate part of the cdb -  a so called zombie. Normally using pre-modification should be enough.