Example

    Pre-requisite

        Netbox running: https://github.com/netbox-community/netbox-docker

        NETCONF capable device (JUNOS use in this example, but templates could be changed for another OS)

        Blueprint processor micro-service runnint

        CDS SQL database, populated with reference data as bellow:

          CREATE TABLE `demo` (
            `id` text DEFAULT NULL,
            `value` text DEFAULT NULL
          );

          INSERT INTO `demo` VALUES ('1','vsn'),('2','vpg'),('3','vfw');

    resources

         Bellow a table of the resource used within this example, and how this resource
         are resolved.
         The resources are used in the context of device configuration. These shouldn't be
         confused with SDC model resources.

              name               |   resolve through
          ------------------------------------------------------
          prefix-id              |   default
          vfw_interface_ip       |   rest (through Netbox)
          hostname               |   input
          vf-module-number       |   default
          vf-module-type         |   database
          unit-number            |   input
          interface-name         |   input
          interface-description  |   capability (python script)

    4 workflows

        resource-assignment

            Ability to resolve templates with their mappings and provide the result as output.
            Example provide one templates: vf-module-1

            Input:

              Nothing specific to pass as input to the request. The resolution will use SQL and script to
              resolve all the parameters.

            Output:

              {
                "resource-assignment-response": {
                    "meshed-template": {
                        "vf-module-1": "<interface>\n    <description>This is the Virtual Firewall entity</description>\n    <vfw>10.10.10.69/24</vfw>\n</interface>"
                    }
                }
              }

        config-assign (dry-run)

            Ability to resolve templates with their mappings and provide the result as output.
            Example provide one templates: hostname

            This action uses the same functionality as resource-assignment, and in addition,
            store the resulting meshed-template to be used later.

            Input

                resolution-key:   To identify the configlet saved in the DB
                hostname:         Value defined to be result trough input in the hostname mapping file
                interface-name:   Name of the interface to configure
                unit-number:      Unit to configure for the interface

              {
                  "config-assign-request": {
                    "resolution-key": "config-assign-demo-123",
                    "config-assign-properties": {
                      "hostname": "blah",
                      "interface-name": "ge-0/0/7",
                      "unit-number": 0
                    }
                  }
              }

            Output:

              "config-assign-response": {
                  "dry-run": {
                      "hostname": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<configuration xmlns:junos=\"http://xml.juniper.net/junos/17.4R1/junos\">\n   <system xmlns=\"http://yang.juniper.net/junos-qfx/conf/system\">\n      <host-name operation=\"delete\" />\n      <host-name operation=\"create\">blah</host-name>\n   </system>\n</configuration>\n",
                      "vfw-interface": "<configuration>\n        <interfaces>\n            <interface>\n                <name>ge-0/0/7</name>\n                <unit operation=\"create\">\n                    <name>0</name>\n                    <description>This is the Virtual Firewall entity</description>\n                    <family>\n                        <inet>\n                            <address>\n                                <name>10.0.101.17/24</name>\n                            </address>\n                        </inet>\n                    </family>\n                </unit>\n            </interface>\n        </interfaces>\n</configuration>"
                  }
              }

        config-deploy

            This action will run a python script that will retrieved the resolved template
            from previous step using the resolution-key.
            This action will push these resolved templates into a device (JUNOS) using NETCONF.
            The python script will make use of utilities classes provided by the platform:
            resolution helper and netconf client.

            Information about the device is modelled as a requirement of this action, specifying that
            username, password and ip of the device should be provided as input.
            Note: you could resolve those information using the resource resolution framework, if need be.

            Input:

                resolution-key:   To identify the configlet saved in the DB in previous step
                username:         NETCONF device user
                password:         NETCONF device password
                ip:               NETCONF device ip


              {
                "config-deploy-request": {
                  "resolution-key": "config-assign-demo-123",
                  "username": "admin",
                  "password": "passwd",
                  "ip": "10.198.1.35"
                }
              }

            Output:

                No specific output beside success or failure.

        rollback

            This action will rollback the last committed config on the device, using NETCONF and device
            specific RPC. To do so, a python script will be used, similar as in previous action, to dynamically
            resolve the rollback template payload, and send the RPC to the device.

            Information about the NETCONF device is provided in a similar fashion as previous step.

            Input:

                username:         NETCONF device user
                password:         NETCONF device password
                ip:               NETCONF device ip

              {
                "rollback-request": {
                  "username": "admin",
                  "password": "passwd",
                  "ip": "10.198.1.35",
                  "rollback-properties": {

                  }
                }
              }

            Output:

                No specific output beside success or failure.


Postman collection used for this example. 5 requests are provided one per workflow to execute, and 1 to load the CBA in the runtime environment.

    https://www.getpostman.com/collections/d68b12a60fd6ed336059