1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
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": "<?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-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
|
