3. CIRV-HDV Configuration Guide

The HDV tool takes input two files:

3.1. PDF2.0

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.

3.2. 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:

...
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}/
...

3.3. 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:

3.3.1. 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:

expected_result:
  AssetTag: CM_cc@1234
  • a complex example:

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.

3.3.2. 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

url : /redfish/v1/Systems/1/Processors/1/
  • Url for accessing all CPUs of System id 1

url : /redfish/v1/Systems/1/Processors/{cpu_id}/
  • Url for accessing all CPUs of all Systems

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:

key_flag_dict :
    system_id: Members
    cpu_id: Members