aboutsummaryrefslogtreecommitdiffstats
path: root/components/model-catalog/blueprint-model/test-blueprint/golden/README
diff options
context:
space:
mode:
Diffstat (limited to 'components/model-catalog/blueprint-model/test-blueprint/golden/README')
-rw-r--r--components/model-catalog/blueprint-model/test-blueprint/golden/README124
1 files changed, 77 insertions, 47 deletions
diff --git a/components/model-catalog/blueprint-model/test-blueprint/golden/README b/components/model-catalog/blueprint-model/test-blueprint/golden/README
index 06f91123e..3fba19cfc 100644
--- a/components/model-catalog/blueprint-model/test-blueprint/golden/README
+++ b/components/model-catalog/blueprint-model/test-blueprint/golden/README
@@ -4,8 +4,19 @@ 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
+
+ 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
@@ -25,61 +36,74 @@ Example
interface-name | input
interface-description | capability (python script)
- 3 workflow
+ 4 workflows
+
+ resource-assignment
- resource-assignment (dry-run)
+ Ability to resolve templates with their mappings and provide the result as output.
+ Example provide one templates: vf-module-1
- 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
+ Input:
- 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.
+ 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>"
+ }
+ }
+ }
- Here is the request payload:
+ 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
- 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"
+ {
+ "config-assign-request": {
+ "resolution-key": "config-assign-demo-123",
+ "config-assign-properties": {
+ "hostname": "demo-config-assign"
}
}
- }
+ }
Output:
- {
- "resource-assignment-params": {
- "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\">demo123</host-name>\n </system>\n</configuration>\n",
- "vf-module-1": "<interface>\n <description>This is the Virtual Firewall entity</description>\n <vfw>10.10.10.39/24</vfw>\n</interface>"
- },
- "status": "success"
- }
+ {
+ "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\">demo-config-assign</host-name>\n </system>\n</configuration>\n"
+ }
+ }
+ }
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.
+ from previous step using the resolution-key.
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.
+ 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:
+ Input:
resolution-key: To identify the configlet saved in the DB in previous step
username: NETCONF device user
@@ -88,16 +112,18 @@ Example
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",
+ {
+ "config-deploy-request": {
+ "resolution-key": "config-assign-demo-123",
+ "username": "admin",
+ "password": "passwd",
"ip": "10.198.1.35",
"config-deploy-properties": {
"interface-name": "ge-0/0/7",
- unit-number": "0"
+ "unit-number": "0"
}
}
+ }
Output:
@@ -109,26 +135,30 @@ Example
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.
+ Information about the NETCONF device is provided in a similar fashion as previous step.
- Here is the request payload:
+ Input:
username: NETCONF device user
password: NETCONF device password
ip: NETCONF device ip
- {
- "username": "pass",
- "password": "user",
- "ip": "10.10.10.10"
- }
+ {
+ "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. 4 requests are provided one per workflow to execute, and 1 to load the CBA in the runtime environment.
+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/4d199ff02a735bd3e680 \ No newline at end of file
+ hhttps://www.getpostman.com/collections/4d199ff02a735bd3e680 \ No newline at end of file