Documention and minor changes for easy installation

Signed-off-by: Shubham Mishra <shivam828787@gmail.com>
Change-Id: I42caa10e0b775724c0304107b565695825a73d65

4 files changed, 207 insertions, 1 deletions

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=<output_directory> --config=<pdf_file> --cases=<cases_file> hdv_redfish.py

+      $ allure serve <output_directory>

+

+* 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