From 64a168d7d9a86e5cbdf4e01718066e93ca0592da Mon Sep 17 00:00:00 2001 From: Alexis de Talhouët Date: Tue, 12 Mar 2019 16:49:54 -0400 Subject: Add intial test CBA MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Change-Id: If7c18e8ad472cebc3e36858fcb0cdf4c7ef6d52d Issue-ID: CCSDK-1149 Signed-off-by: Alexis de Talhouët --- .../blueprint-model/test-blueprint/golden/README | 134 +++++++++++++++++++++ 1 file changed, 134 insertions(+) create mode 100644 components/model-catalog/blueprint-model/test-blueprint/golden/README (limited to 'components/model-catalog/blueprint-model/test-blueprint/golden/README') diff --git a/components/model-catalog/blueprint-model/test-blueprint/golden/README b/components/model-catalog/blueprint-model/test-blueprint/golden/README new file mode 100644 index 00000000..06f91123 --- /dev/null +++ b/components/model-catalog/blueprint-model/test-blueprint/golden/README @@ -0,0 +1,134 @@ + +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 + + 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) + + 3 workflow + + resource-assignment (dry-run) + + Ability to resolve multiple templates and mappings at the same time, + based on the request 'artifact-name', and provide the result as output. + Example provide two templates: hostname and vf-module-1 + + In order to perform dry-run, we need to store the template and have + the ability to retrieve the stored result later point in time. For this + we have to specify that we want to store the result, and we need to provide + a resolution-key. + + Here is the request payload: + + artifact name: template(s) to resolve + store-result: whether to save the generated configlet in DB + resolution-key: To identify the configlet saved in the DB + hostname: Value defined to be result trough input in the hostname mapping file + + { + "resource-assignment-request": { + "artifact-name": [ "hostname", "vf-module-1" ], + "resolution-key": "hostname-demo-123", + "store-result": true, + "resource-assignment-properties": { + "hostname": "demo123" + } + } + } + + Output: + + { + "resource-assignment-params": { + "hostname": "\n\n \n \n demo123\n \n\n", + "vf-module-1": "\n This is the Virtual Firewall entity\n 10.10.10.39/24\n" + }, + "status": "success" + } + + config-deploy + + This action will run a python script that will retrieved the resolved template + from previous step using the resolution-key and the artifact-name. + The script will also resolve another template during its execution: the Interface Template. + Finally, 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. + + Here is the request payload: + + 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 + interface-name: Name of the interface to configure + unit-number: Unit to configure for the interface + + { + "resolution-key": "hostname-demo-123", + "username": "user", + "password": "pass", + "ip": "10.198.1.35", + "config-deploy-properties": { + "interface-name": "ge-0/0/7", + unit-number": "0" + } + } + + 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. Actually, the + same model is used. + + Here is the request payload: + + username: NETCONF device user + password: NETCONF device password + ip: NETCONF device ip + + { + "username": "pass", + "password": "user", + "ip": "10.10.10.10" + } + + Output: + + No specific output beside success or failure. + + +Postman collection used for this example. 4 requests are provided one per workflow to execute, and 1 to load the CBA in the runtime environment. + + https://www.getpostman.com/collections/4d199ff02a735bd3e680 \ No newline at end of file -- cgit 1.2.3-korg