1. NE config snapshot/rollback#

1.1 Prerequisites#

• Basic knowledge the NSP UI
• Basic knowledge about Workflow Manager
• Basic knowledge about Device Operations
• No fear to touch code (for the 2^nd part of this activity)

1.2 Objectives#

The purpose of this activity is to take advantage of NSP Device Operations to take NE configuration snapsnhots allowing to rollback to snapshots taken. NE snapshot/rollback operations will appear as backup/restore operation-category under NSP Device Management.

The difference to backup/restore operations that come as part of the product is, that we are taking advantage of transactional, declarative device management protocols (gNMI, NETCONF). One of the benefits of this approach is, that we can directly access the running configuration while there is no need to save the configuration prior to the download. Another benefit is, that the solution can easily be adopted to other device vendors/families, as long those support NETCONF or gNMI. Finally, there is no dependency to file-transfer (xFTP/SCP) and vendor-specific filenames.

In order to keep the barrier for executing this activity low, we will provide you with a template and simple recipe to create your own unsigned artifact bundle, that you can import into NSP using Artifact Manager to get started.

1.3 Goals to achieve#

1.3.1 Part 1 - Beginner (steps 1-5)#

Grain practical experience in following areas of NSP:

• NSP Artifact Manager, by importing the artifact bundle and monitoring the installation process.
• NSP Operations Manager and Device Management by executing snapshot and rollback operations, view and compare snapshots
• NSP Workflow Manager, by checking the execution results

1.3.2 Part 2 - Intermediate (step 6, 7)#

Extend the operation capabilities by updating the workflows:

• Improve the workflow by applying some best practices
• Extend the workflow to support SR Linux nodes

1.4 Tasks#

You should read these tasks from top-to-bottom before beginning the activity.

It is tempting to skip ahead but tasks may require you to have completed previous tasks before tackling them.

1.4.1 Step 1 - Download, customize and install bundle:#

1. Clone this repo to your local system.
2. Check the content of cfg-snapshot-artifact-bundles
3. Adjust the artifact-bundle content for your group and build the artifact.
4. Login to NSP. Access details will be provided during the hackathon.
5. In NSP, open the hamburger menu and select Artifacts.
6. Select Import and Install, find the zip file and install the bundle.

% cd cfg-snapshot-artifact-bundle
% tree
.
├── metadata.json
├── operation-rollback
│   ├── ne-rollback-groupxx.yaml
│   ├── ne-rollback-groupxx.yang
│   └── operation_types.json
├── operation-snapshot
│   ├── ne-snapshot-groupxx.yaml
│   ├── ne-snapshot-groupxx.yang
│   └── operation_types.json
├── workflow-rollback
│   ├── README.md
│   └── ne-rollback-groupxx.yaml
└── workflow-snapshot
    ├── README.md
    ├── ne-snapshot-groupxx.json
    └── ne-snapshot-groupxx.yaml

4 directories, 12 files

export instance=group02
cp -r cfg-snapshot-artifact-bundle /tmp
cd /tmp/cfg-snapshot-artifact-bundle
find . -name '*groupxx*' -exec bash -c 'mv "$0" "${0//groupxx/$instance}"' {} \;
find . -type f -exec sed -i '' s/groupxx/$instance/g {} \;
zip -r /tmp/cfg-snapshot-$instance.zip *

export instance=group02
cp -r cfg-snapshot-artifact-bundle /tmp
cd /tmp/cfg-snapshot-artifact-bundle
find . -name '*groupxx*' -exec bash -c 'mv "$0" "${0//groupxx/$instance}"' {} \;
find . -type f -exec sed -i s/groupxx/$instance/g {} \;
zip -r /tmp/cfg-snapshot-$instance.zip *

Copy-Item -Path "cfg-snapshot-artifact-bundle" -Destination "C:\tmp" -Recurse -Force
Set-Location -Path "C:\tmp\cfg-snapshot-artifact-bundle"
$instance = "group002"
Get-ChildItem -Path "." -Filter "*groupxx*" | Rename-Item -NewName { $_.Name -replace 'groupxx', $instance }
Get-ChildItem -Path "." -File | ForEach-Object {
    $content = Get-Content -Path $_.FullName
    $newContent = $content -replace 'groupxx', $instance
    Set-Content -Path $_.FullName -Value $newContent
}
$outputZip = Join-Path -Path "C:\tmp" -ChildPath "cfg-snapshot-$instance.zip"
Compress-Archive -Path "*" -DestinationPath $outputZip -Force

Once your bundle is shown as Installed, you can continue...

1.4.2 Step 2 - Test the operation#

1. In NSP, select Device Management in the hamburger menu.
2. In the dropdown menu, select All Operations
3. Click on "+ OPERATION" to create a new operation
4. Select Operation Type ne-snapshot-group02 (adjust to your group)
5. Provide operation name, for example initial-cfg-snapshot-group02 (adjust to your group)
6. Select P1, P2, PE1, PE2, PE3, PE4 as Target NEs to take a snapshot (adjust to your group)
7. After the creation the user can check the operation status, it should set to completed.
8. Check the operation result and cross-navigate to see the underlying workflow executions

1.4.3 Step 3 - Explore NSP WebUI shortcuts#

The Operation section under Device Management is common for all NSP operations. To simplify usability, you can access the snapshot/rollback operations and results from the Managed Network Elements view.

1. In NSP, select Device Management in the hamburger menu.
2. In the dropdown menu, select Managed Network Elements
3. Click on the 3 dots for your P1 node to open the context menu for device specific Operations (adjust to your group)
4. Explore the options to access operation history, review backups and create backups.
5. In NSP, select File Server in the hamburger menu (section: NSP Administration)

1.4.4 Step 4 - Taking it a step further#

1. Apply changes to a node using CLI or MDC and take another config snapshot! Example: Add/Update location and contact information under configure > system. Do you see the changes?
2. Use the rollback operation to restore the initial configuration (without reboot)! Was the config restored?
3. Update your operations to become the default operation. What has changed?
4. Try the option to Compare with current NE config (only works, if your operation is the default operation)
5. Delete snapshot operations. Do you still have access to the snapshot itself? Can it be displayed/restored?
6. Create a scheduled operation, that takes NE snapshots from all SR OS nodes every hour.

1.4.5 Step 5 - Digging into the code#

Review the code examples provides for the operation-types and the workflows. There is different ways to access the code using vsCode or from WebUI.

1.4.6 Step 6 - Improve the operation#

Review the workflow that takes the configuration snapshot. Check, if there is anything that can be improved! Are best practices appropriately applied?

You may find, that action getConfigSROS publishes the configuration as JSON string. This approach works well for smaller configurations, like in context of this Hackathon. But considering production-scale nodal configurations, be reminded that publishing mega-bytes of data is not recommended, as it impacts resource usage of the WFM services and DB footage.

To work around this, you may consider updating the workflow. The nsp.https action allows to store the result in the local file-system by using the input attribute called fileName. Change the task to store the JSON response as file under the path /tmp/<% $.neName %>.nokia-conf.json. When applying this change, you need to consider to add another input attribute resultFilter : $.content. This applies a YAQL expression to the response before writing it to a file, else everything would be wrapped into a top-level element called content.

Please ensure to use an unique filename, as multiple snapshot operations for different targets may run in parallel.

To upload the file to the file-service, you need to update the task writeConfigFile. Uploading files is relatively easy using the nsp.uploadFile action.

As /tmp is a shared file-system, validate if you can take multiple snapshots from different devices in parallel! We are not removing files from /tmp. Does this cause any further issues?

You may spot, that the JSON file is now minified, while it was prettified before. This impacts usability when displaying or comparing backups. As of today, the action nsp.https does not have an option to store the result as pretty JSON. You may consider using python to make it pretty.

While we've applied the best practices change for taking a configuration snapshots, you may observe that the rollback workflow publishes the configuration too and renders a full blown nsp.https request, that contains the entire config in the body payload. Please note, the action nsp.https does not have an option to load the payload body from the filesystem.

action: nsp.https
input:
  method: GET
  url: https://restconf-gateway/restconf/data/network-device-mgr:network-devices/network-device=<% $.neId %>/root/nokia-conf:configure
  fileName: /tmp/<% $.neName %>.nokia-conf.json
  resultFilter : $.content        
publish-on-error:
  lsoInfo: "Failed: getting config from MD-SROS node"
  lsoStageError: <% task().result %>      
on-success:
  - createBackupFolder

action: nsp.uploadFile
input:
  fileServicePath: <% $.dirName %>/<% $.timestamp %>
  localFilePath: /tmp/<% $.neName %>.nokia-conf.json
on-success:
  - zipConfig

    prettify:
      action: nsp.python
      input:
        context:
          filename: /tmp/<% $.neName %>.nokia-conf.json
        script: |
          import json
          import sys
          with open(context["filename"], 'r') as f:
            data = json.load(f)
          with open(context["filename"], 'w') as f:
            json.dump(data, f, indent=2, sort_keys=True)

1.4.7 Step 7 - Extend the operation#

Congrats, if you already made it to this point! You've mastered operations and workflows and even you've done a bit of coding. This is excellent! In the final part of this activity, we want to go practical. The ask is to extend the snapshot operation/workflow to support SR Linux.

Let's start with the operation first. As the mapping profile associates supported device-types with workflows to be executed, you need to extend the mapping profile to support the corresponding SR Linux families. Take a look into the NSP operation nsp-ne-backup that is installed by default. It contains the entries 7220 IXR SRLinux and 7250 IXR SRLinux for family_type. Extend the list of supported families for your own operations, while we will keep the same workflows!

After you've imported your updated bundle, you may consider running a test to validate, that the existing functionality still works. Once this is done you can start updating your workflows.

The most notable difference between SR OS and SR Linux would be, that SR OS stores all configuration in a single root module (/nokia-conf:configure) while SR Linux uses multiple root-level modules.

In addition, be aware that SR Linux mixes configuration (read/write) and state attributes (read-only) in the same subtree. As the ask is to capture the configuration only, the RESTCONF query parameter ?content=config should be added to the corresponding RESTCONF GET request.

As MDC does not support to fetch all module instance by accessing /root, and because we are not interested in OpenConfig models, you may use the SRL YANG Explorer or NSP MDC to find appropriate root paths. You may want to start with the following root paths:

• srl_nokia-network-instance:/network-instance
• srl_nokia-interfaces:/interface
• srl_nokia-system:system

It's recommended to store the output of those queries in separate files, while the ZIP archive would now contain multiple files.