From bad2aa0a7a3fb57515116d77b7a617a2941b2b50 Mon Sep 17 00:00:00 2001 From: Shubham Mishra Date: Wed, 4 Nov 2020 02:53:37 +0530 Subject: Documention and minor changes for easy installation Signed-off-by: Shubham Mishra Change-Id: I42caa10e0b775724c0304107b565695825a73d65 --- docs/release/configguide/index.rst | 131 +++++++++++++++++++++++++++ docs/release/release-notes/index.rst | 2 +- docs/release/release-notes/release-notes.rst | 22 +++++ docs/release/userguide/index.rst | 53 +++++++++++ 4 files changed, 207 insertions(+), 1 deletion(-) (limited to 'docs/release') diff --git a/docs/release/configguide/index.rst b/docs/release/configguide/index.rst index 8e708b0..b5bcaf3 100644 --- a/docs/release/configguide/index.rst +++ b/docs/release/configguide/index.rst @@ -4,3 +4,134 @@ 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 \ No newline at end of file diff --git a/docs/release/release-notes/index.rst b/docs/release/release-notes/index.rst index 82d4068..cdb3178 100644 --- a/docs/release/release-notes/index.rst +++ b/docs/release/release-notes/index.rst @@ -14,4 +14,4 @@ CIRV-HDV Release Notes release-notes.rst -Build date: |today| +Build date: |today| \ No newline at end of file diff --git a/docs/release/release-notes/release-notes.rst b/docs/release/release-notes/release-notes.rst index aa1b8ca..4087ceb 100644 --- a/docs/release/release-notes/release-notes.rst +++ b/docs/release/release-notes/release-notes.rst @@ -5,3 +5,25 @@ OPNFV Jerma Release ==================== +Introduction: +^^^^^^^^^^^^^ + +This is a sub project of CIRV about the hardware delivery validation tool implementation, +short as HDV. The HDV implementation is based on redfish interface. It can be used to validate or configurate server hardware, +especially if a very large scale of resource pool to build in NFV where all the servers are expected with same configuration required. +It's possible for user to have a slightly redfish interface across the server model from vendors, users are encouraged to edit +and prepare their specific validation case file for the specific server. Then it is capable to promote operator to examine hardware efficiently. + + +Features: +^^^^^^^^^ + +* open framework to support multi-vendor redfish +* support of CNTT-RI PDF2.0 format definition +* develop default HP case set supported +* documentation of user guide, developer guide + +Known issue: +^^^^^^^^^^^ + +N/A listing the known issue if any diff --git a/docs/release/userguide/index.rst b/docs/release/userguide/index.rst index bd6d785..2fad89f 100644 --- a/docs/release/userguide/index.rst +++ b/docs/release/userguide/index.rst @@ -4,3 +4,56 @@ CIRV-HDV User Guide =================== + +Requirements +^^^^^^^^^^^^ +* Python3 +* pip +* git + +Installation +^^^^^^^^^^^^^ + +Clone repo as follows: + +.. code-block:: bash + + $ git clone "https://gerrit.opnfv.org/gerrit/cirv-hdv" + + +then install required python packages: + +.. code-block:: bash + + $ pip install -r cirv-hdv/requirements.txt + +The command will install following packages + +* PyYAML +* urllib3 +* requests +* netaddr +* openpyxl +* pytest +* allure-pytest + +Run +^^^^ +The hdv tools uses PDF2.0 to get servers information and cases file to read test cases. + +Move to the ``/hdv/redfish`` directory and run Validation + +.. code-block:: bash + + $ cd /hdv/redfish + $ pytest --allure-dir= --config= --cases= hdv_redfish.py + $ allure serve + +* allure-dir: Path to name of the folder which will be used later to create graphical reports using python-allure. + +.. _link: https://github.com/opnfv/cirv-sdv/tree/master/sdv/pdf/template +* config: Path to pdf2.0 file comply CNTT-RI requirement. It is needed to access servers. For more information, follow the link - `link`_. + +* cases: Path to case file, yaml file which store all the cases to validate. + +You can look at the configuration guide for further information. \ No newline at end of file -- cgit 1.2.3-korg