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
135
136
137
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c)
CIRV-HDV Configuration Guide
============================
The HDV tool takes input two files:
PDF2.0
^^^^^^
.. _link: https://github.com/opnfv/cirv-sdv/tree/master/sdv/pdf/template
PDF2.0 is a standard to describe Pod infrastructure originated from OPNFV. you can find the further information about PDF2.0 here - `link`_.
HDV tool uses this file to get redfish ip and credentials for accessing servers.
cases file
^^^^^^^^^^
The file defines all the test cases which hdv tool takes as input to validate.
Every test case is a set of key-value pairs.
Example:
.. code-block:: console
...
case_name: check CPU info
case_sn: 12
enabled: true
expected_code: 200
expected_result:
count: 2
Manufacturer: Intel(R) Corporation
MaxSpeedMHz: 2300
Model: "Intel(R) Xeon(R) Gold 5218N CPU @ 2.30GHz"
ProcessorArchitecture: ["x86", "IA-64", "ARM", "MIPS", "OEM"]
Socket: [1, 2]
Status:
Health: OK
State: Enabled
TotalCores: 16
TotalThreads: 32
group: compoment management
header: null
method: GET
request_body: null
url: /redfish/v1/Systems/{system_id}/Processors/{cpu_id}/
...
Create your own test case
^^^^^^^^^^^^^^^^^^^^^^^^^
There are differences between vendors's redfish implementation, or even versions for the same vendor.
So, we made the tool generic enough so that anyone can easily define more test case or update existing case in the cases.yaml by defining following paramters:
1. **case_name** : name of test case.
2. **case_sn** : Every testcase must have unique serial number
3. **enabled** : whether to run this test or skip
4. **expected_code**: http return code (200,201,400,..)
5. **expected_result**: Tool will compare the response value with value define in ``expected_result`` to decide if the case passed.
6. **header**: header for http request
7. **method**: http method (GET, POST, PUT, DELETE)
8. **request_body**: data to sent in request in case of POST, PUT method else "null"
9. **url**: URI of the resource which needs to be validated
10. **key_flag_dict**:
How to write expected_result:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* It should be in yaml format.
* The hierachy should be exactly the same with actual returned value.
* a simple example:
.. code-block:: console
expected_result:
AssetTag: CM_cc@1234
* a complex example:
.. code-block:: console
expected_result:
count: 2
Manufacturer: "Intel(R) Corporation"
MaxSpeedMHz: 2300
Model: "Intel(R) Xeon(R) Gold 5218N CPU @ 2.30GHz"
ProcessorArchitecture: ["x86", "IA-64", "ARM", "MIPS", "OEM"]
Socket: [1, 2]
Status:
Health: OK
State: Enabled
TotalCores: 16
TotalThreads: 32
* In the above data, a specific "count" attribute defined to check components quantity returned, e.g How many cpus expected.
* Generally expected_result can be a subset attributes definition, comparing with actual return value.
* It can support list of all expected value for list of objects. Example: "Socket:[1,2]", expecting return "Socket:1" and "Socket:2" from returned response.
How to write URL and key_flag_dict:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Redfish uses RESTful interface semantics to access data that is defined in model format to perform out-of-band systems management.
Every test requires a URI of the target resource. The URIs for every Redfish Resource are defined to appear at known, fixed locations (you can find it in official redfis documentation of your server).
In HDV, for validation of more than 1 resource you have the option to replace the ids with variables.
Examples:
* Url for accessing CPU with id 1 of System id 1
.. code-block:: console
url : /redfish/v1/Systems/1/Processors/1/
* Url for accessing all CPUs of System id 1
.. code-block:: console
url : /redfish/v1/Systems/1/Processors/{cpu_id}/
* Url for accessing all CPUs of all Systems
.. code-block:: console
url : /redfish/v1/Systems/{system_id}/Processors/{cpu_id}/
When using variables you need to define key_flag_dict, it is used to describe object name which hdv tool will use to replace variable in URL with appropriate resource id.
Example:
.. code-block:: console
key_flag_dict :
system_id: Members
cpu_id: Members
|
