components/model-catalog/blueprint-model/test-blueprint/golden/README

   1
   2 Example
   3
   4     Pre-requisite
   5
   6         Netbox running: https://github.com/netbox-community/netbox-docker
   7
   8         NETCONF capable device (JUNOS use in this example, but templates could be changed for another OS)
   9
  10         Blueprint processor micro-service runnint
  11
  12         CDS SQL database, populated with reference data as bellow:
  13
  14           CREATE TABLE `demo` (
  15             `id` text DEFAULT NULL,
  16             `value` text DEFAULT NULL
  17           );
  18
  19           INSERT INTO `demo` VALUES ('1','vsn'),('2','vpg'),('3','vfw');
  20
  21     resources
  22
  23          Bellow a table of the resource used within this example, and how this resource
  24          are resolved.
  25          The resources are used in the context of device configuration. These shouldn't be
  26          confused with SDC model resources.
  27
  28               name               |   resolve through
  29           ------------------------------------------------------
  30           prefix-id              |   default
  31           vfw_interface_ip       |   rest (through Netbox)
  32           hostname               |   input
  33           vf-module-number       |   default
  34           vf-module-type         |   database
  35           unit-number            |   input
  36           interface-name         |   input
  37           interface-description  |   capability (python script)
  38
  39     4 workflows
  40
  41         resource-assignment
  42
  43             Ability to resolve templates with their mappings and provide the result as output.
  44             Example provide one templates: vf-module-1
  45
  46             Input:
  47
  48               Nothing specific to pass as input to the request. The resolution will use SQL and script to
  49               resolve all the parameters.
  50
  51             Output:
  52
  53               {
  54                 "resource-assignment-response": {
  55                     "meshed-template": {
  56                         "vf-module-1": "<interface>\n    <description>This is the Virtual Firewall entity</description>\n    <vfw>10.10.10.69/24</vfw>\n</interface>"
  57                     }
  58                 }
  59               }
  60
  61         config-assign (dry-run)
  62
  63             Ability to resolve templates with their mappings and provide the result as output.
  64             Example provide one templates: hostname
  65
  66             This action uses the same functionality as resource-assignment, and in addition,
  67             store the resulting meshed-template to be used later.
  68
  69             Input
  70
  71                 resolution-key:   To identify the configlet saved in the DB
  72                 hostname:         Value defined to be result trough input in the hostname mapping file
  73                 interface-name:   Name of the interface to configure
  74                 unit-number:      Unit to configure for the interface
  75
  76               {
  77                   "config-assign-request": {
  78                     "resolution-key": "config-assign-demo-123",
  79                     "config-assign-properties": {
  80                       "hostname": "blah",
  81                       "interface-name": "ge-0/0/7",
  82                       "unit-number": 0
  83                     }
  84                   }
  85               }
  86
  87             Output:
  88
  89               "config-assign-response": {
  90                   "dry-run": {
  91                       "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",
  92                       "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>"
  93                   }
  94               }
  95
  96         config-deploy
  97
  98             This action will run a python script that will retrieved the resolved template
  99             from previous step using the resolution-key.
 100             This action will push these resolved templates into a device (JUNOS) using NETCONF.
 101             The python script will make use of utilities classes provided by the platform:
 102             resolution helper and netconf client.
 103
 104             Information about the device is modelled as a requirement of this action, specifying that
 105             username, password and ip of the device should be provided as input.
 106             Note: you could resolve those information using the resource resolution framework, if need be.
 107
 108             Input:
 109
 110                 resolution-key:   To identify the configlet saved in the DB in previous step
 111                 username:         NETCONF device user
 112                 password:         NETCONF device password
 113                 ip:               NETCONF device ip
 114
 115
 116               {
 117                 "config-deploy-request": {
 118                   "resolution-key": "config-assign-demo-123",
 119                   "username": "admin",
 120                   "password": "passwd",
 121                   "ip": "10.198.1.35"
 122                 }
 123               }
 124
 125             Output:
 126
 127                 No specific output beside success or failure.
 128
 129         rollback
 130
 131             This action will rollback the last committed config on the device, using NETCONF and device
 132             specific RPC. To do so, a python script will be used, similar as in previous action, to dynamically
 133             resolve the rollback template payload, and send the RPC to the device.
 134
 135             Information about the NETCONF device is provided in a similar fashion as previous step.
 136
 137             Input:
 138
 139                 username:         NETCONF device user
 140                 password:         NETCONF device password
 141                 ip:               NETCONF device ip
 142
 143               {
 144                 "rollback-request": {
 145                   "username": "admin",
 146                   "password": "passwd",
 147                   "ip": "10.198.1.35",
 148                   "rollback-properties": {
 149
 150                   }
 151                 }
 152               }
 153
 154             Output:
 155
 156                 No specific output beside success or failure.
 157
 158
 159 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.
 160
 161     https://www.getpostman.com/collections/d68b12a60fd6ed336059