prettier: re-format
Prettier is enabled in openbmc-build-scripts on Markdown, JSON, and YAML
files to have consistent formatting for these file types. Re-run the
formatter on the whole repository.
Change-Id: Ie200c0d0da7926b8e0dae0b44c5618762f7fd666
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 94725d3..0fa88aa 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,746 +1,856 @@
-Contributing to OpenBMC Test Automation
-=======================================
+# Contributing to OpenBMC Test Automation
+
Guide to working on OpenBMC test automation. This document will always be a
work-in-progress, feel free to propose changes.
-Submitting changes via Gerrit server
-------------------------------------
-- Reference [OpenBMC CLA](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server-to-openbmc)
-- Reference [OpenBMC docs](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server)
+## Submitting changes via Gerrit server
-Commit Message Guidelines
--------------------------
-- Reference [Formatting Commit Messages](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#formatting-commit-messages)
+- Reference
+ [OpenBMC CLA](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server-to-openbmc)
+- Reference
+ [OpenBMC docs](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server)
-Links
------
+## Commit Message Guidelines
+
+- Reference
+ [Formatting Commit Messages](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#formatting-commit-messages)
+
+## Links
- [Redfish Coding Guidelines](docs/redfish_coding_guidelines.md)
-Robot Coding Guidelines
------------------------
-- For this project, we will write Robot keyword definitions in either Robot
- or Python. Robot code should be quite simple. Therefore, if the algorithm
- in question is the least bit complex, please write it in Python.
+## Robot Coding Guidelines
- See the following for support on writing most keywords in python.
- - [Quit Writing Ugly Robot Code](https://esalagea.wordpress.com/2014/11/24/robot-framework-quit-writing-ugly-robot-code-just-write-proper-python/)
- - [Robot Dos and Don'ts](https://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts)
+- For this project, we will write Robot keyword definitions in either Robot or
+ Python. Robot code should be quite simple. Therefore, if the algorithm in
+ question is the least bit complex, please write it in Python.
-- Observe a maximum line length of 110 characters.
-- Avoid trailing space at the end of any line of Robot code.
-- Avoid the use of tabs.
-- Robot supports delimiting cells with either two or more spaces or with a
- pipe symbol (e.g. "\|"). Our team has chosen to use spaces rather than the
- pipe character. Make sure all space delimiters in Robot code are the
- **minimum** of two spaces. There may be some exceptions to this rule.
+ See the following for support on writing most keywords in python.
- Exceptions to two-space delimiter rule:
- - When you wish to line up resource, library or variable values:
- ```
- Library Lib1
- Resource Resource1
- *** Variables ***
- ${var1} ${EMPTY}
- ```
- - When you wish to line up fields for test templates:
- ```
- [Template] Set System LED State
- # LED Name LED State
- power On
- power Off
- ```
- - When you wish to indent if/else or loop bodies for visual effect:
- ```
- Run Keyword If '${this}' == '${that}'
- ... Log Bla, bla...
- ... ELSE
- ... Run Keywords Key1 parms
- ... AND Key2 parms
- ```
-- Use single spaces to make conditions more readable:
+ - [Quit Writing Ugly Robot Code](https://esalagea.wordpress.com/2014/11/24/robot-framework-quit-writing-ugly-robot-code-just-write-proper-python/)
+ - [Robot Dos and Don'ts](https://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts)
+
+- Observe a maximum line length of 110 characters.
+- Avoid trailing space at the end of any line of Robot code.
+- Avoid the use of tabs.
+- Robot supports delimiting cells with either two or more spaces or with a pipe
+ symbol (e.g. "\|"). Our team has chosen to use spaces rather than the pipe
+ character. Make sure all space delimiters in Robot code are the **minimum** of
+ two spaces. There may be some exceptions to this rule.
+
+ Exceptions to two-space delimiter rule:
+
+ - When you wish to line up resource, library or variable values:
+ ```
+ Library Lib1
+ Resource Resource1
+ *** Variables ***
+ ${var1} ${EMPTY}
+ ```
+ - When you wish to line up fields for test templates:
+ ```
+ [Template] Set System LED State
+ # LED Name LED State
+ power On
+ power Off
+ ```
+ - When you wish to indent if/else or loop bodies for visual effect:
+ ```
+ Run Keyword If '${this}' == '${that}'
+ ... Log Bla, bla...
+ ... ELSE
+ ... Run Keywords Key1 parms
+ ... AND Key2 parms
+ ```
+
+- Use single spaces to make conditions more readable:
+
+ Correct example:
+
+ ```
+ Run Keyword If '${var1}' == '${0}' My Keyword
+ ```
+
+ Incorrect example:
+
+ ```
+ Run Keyword If '${var1}'=='${0}' My Keyword
+ ```
+
+- When you define or call a Robot keyword, Robot pays no attention to spaces,
+ underscores or case. However, our team will observe the following conventions
+ in both our definitions and our calls:
+
+ - Separate words with single spaces.
+ - Capitalize the first character of each word.
+ - Capitalize all characters in any word that is an acronym (e.g. JSON, BMC,
+ etc).
+
+ Examples:
+
+ ```
+ *** Keywords ***
+
+ This Is Correct
+
+ # This keyword name is correct.
+
+ this_is_incorrect
+
+ # This keyword name is incorrect because of 1) the
+ # underscores instead of spaces and 2) the failure to
+ # capitalize each word in the keyword.
+
+ soisthis
+
+ # This keyword name is incorrect because of 1) a failure to
+ # separate words with single spaces and 2) a failure to capitalize
+ # each word in the keyword.
+
+ BMC Is An Acronym
+
+ # This keyword name is correct. Note that "BMC" is an
+ # acronym and as such is entirely uppercase.
+ ```
+
+- Documentation strings:
+
+ - Each documentation string should be phrased as an **English command**.
+ Punctuate it correctly with the first word capitalized and a period at the
+ end.
Correct example:
+
```
- Run Keyword If '${var1}' == '${0}' My Keyword
+ Boot BMC
+ [Documentation] Boot the BMC.
```
+
Incorrect example:
+
```
- Run Keyword If '${var1}'=='${0}' My Keyword
+ Boot BMC
+ [Documentation] This keyword boots the BMC.
+
+ # The doc string above is not phrased as a command.
```
-- When you define or call a Robot keyword, Robot pays no attention to spaces,
- underscores or case. However, our team will observe the following
- conventions in both our definitions and our calls:
- - Separate words with single spaces.
- - Capitalize the first character of each word.
- - Capitalize all characters in any word that is an acronym (e.g. JSON, BMC,
- etc).
- Examples:
+ - Doc strings should be just one terse, descriptive sentence. Remember that
+ this doc string shows up in the HTML log file. Put additional commentary
+ below in standard comment lines.
+
+ Correct example:
+
```
- *** Keywords ***
+ Stop SOL Console Logging
- This Is Correct
-
- # This keyword name is correct.
-
- this_is_incorrect
-
- # This keyword name is incorrect because of 1) the
- # underscores instead of spaces and 2) the failure to
- # capitalize each word in the keyword.
-
- soisthis
-
- # This keyword name is incorrect because of 1) a failure to
- # separate words with single spaces and 2) a failure to capitalize
- # each word in the keyword.
-
- BMC Is An Acronym
-
- # This keyword name is correct. Note that "BMC" is an
- # acronym and as such is entirely uppercase.
+ [Documentation] Stop system console logging and return log output.
```
-- Documentation strings:
- - Each documentation string should be phrased as an **English command**.
- Punctuate it correctly with the first word capitalized and a period at
- the end.
- Correct example:
- ```
- Boot BMC
- [Documentation] Boot the BMC.
- ```
- Incorrect example:
- ```
- Boot BMC
- [Documentation] This keyword boots the BMC.
+ Incorrect example:
- # The doc string above is not phrased as a command.
- ```
- - Doc strings should be just one terse, descriptive sentence.
- Remember that this doc string shows up in the HTML log file. Put
- additional commentary below in standard comment lines.
+ ```
+ Stop SOL Console Logging
- Correct example:
- ```
- Stop SOL Console Logging
+ [Documentation] Stop system console logging. If there are multiple
+ ... system console processes, they will all be
+ ... stopped. If there is no existing log file this
+ ... keyword will return an error message to that
+ ... effect (and write that message to targ_file_path,
+ ... if specified). NOTE: This keyword will not fail
+ ... if there is no running system console process.
- [Documentation] Stop system console logging and return log output.
- ```
- Incorrect example:
- ```
- Stop SOL Console Logging
+ # This doc string is way too long.
+ ```
- [Documentation] Stop system console logging. If there are multiple
- ... system console processes, they will all be
- ... stopped. If there is no existing log file this
- ... keyword will return an error message to that
- ... effect (and write that message to targ_file_path,
- ... if specified). NOTE: This keyword will not fail
- ... if there is no running system console process.
+- Tags:
- # This doc string is way too long.
- ```
-- Tags:
- - Create a tag for every test case with a tag name that mirrors the test case
- name as follows:
- ```
- Create Intermediate File
+ - Create a tag for every test case with a tag name that mirrors the test case
+ name as follows:
- [Tags] Create_Intermediate_File
- ```
-- Description of argument(s):
- - As shown in the following example, if your keyword has any arguments, include
- a "**Description of argument(s)**" section. This effectively serves as the
- help text for anyone wanting to use or understand your keyword. Include
- real data examples wherever possible and applicable. Leave at least 2 spaces
- between the argument name and the description. Align all description text as
- shown in the example below.
+ ```
+ Create Intermediate File
- Example:
- ```
- Get URL List
- [Documentation] Return list of URLs under given URL.
- [Arguments] ${openbmc_url} ${policy} ${verify}
+ [Tags] Create_Intermediate_File
+ ```
- # Description of argument(s):
- # openbmc_url URL for list operation (e.g.
- # "/xyz/openbmc_project/inventory").
- # policy Power restore policy (e.g "RESTORE_LAST_STATE",
- # ${RESTORE_LAST_STATE}, etc.).
- # verify Verify the results (${TRUE}/${FALSE}).
- ```
- Additional rules for example text in descriptions:
- - Put parentheses around your examples. Leave one space prior to the
- left parenthesis.
- - Use "e.g." (which effectively means "for example") to set introduce
- your examples.
- - Quote string examples.
- - Include ", etc." after multiple examples.
- - For cases where you're providing an complete list of possible values
- (${TRUE}/${FALSE} or "PASS"/"FAIL"), do NOT use "e.g." and do NOT
- use "etc.". Separate such values with a slash.
-- Variable assignments:
+- Description of argument(s):
- When assigning a variable as output from a keyword, do not precede the
- equal sign with a space.
+ - As shown in the following example, if your keyword has any arguments,
+ include a "**Description of argument(s)**" section. This effectively serves
+ as the help text for anyone wanting to use or understand your keyword.
+ Include real data examples wherever possible and applicable. Leave at least
+ 2 spaces between the argument name and the description. Align all
+ description text as shown in the example below.
+
+ Example:
+
+ ```
+ Get URL List
+ [Documentation] Return list of URLs under given URL.
+ [Arguments] ${openbmc_url} ${policy} ${verify}
+
+ # Description of argument(s):
+ # openbmc_url URL for list operation (e.g.
+ # "/xyz/openbmc_project/inventory").
+ # policy Power restore policy (e.g "RESTORE_LAST_STATE",
+ # ${RESTORE_LAST_STATE}, etc.).
+ # verify Verify the results (${TRUE}/${FALSE}).
+ ```
+
+ Additional rules for example text in descriptions:
+
+ - Put parentheses around your examples. Leave one space prior to the left
+ parenthesis.
+ - Use "e.g." (which effectively means "for example") to set introduce your
+ examples.
+ - Quote string examples.
+ - Include ", etc." after multiple examples.
+ - For cases where you're providing an complete list of possible values
+ (${TRUE}/${FALSE} or "PASS"/"FAIL"), do NOT use "e.g." and do NOT use
+ "etc.". Separate such values with a slash.
+
+- Variable assignments:
+
+ When assigning a variable as output from a keyword, do not precede the equal
+ sign with a space.
+
+ Correct examples:
+
+ ```
+ ${var1}= Set Variable ${1}
+ ${var1}= My Keyword
+ ```
+
+ Incorrect examples:
+
+ ```
+ ${var1} = Set Variable ${1}
+ ${var1} = My Keyword
+ ```
+
+- General variable naming conventions:
+
+ - Variable names should be lower case with few exceptions (listed here):
+ - Environment variables should be all upper case.
+ - Variables intended to be set by Robot -v parameters may be all upper case.
+ - Words within a variable name should be separated by underscores:
Correct examples:
+
```
- ${var1}= Set Variable ${1}
- ${var1}= My Keyword
+ ${host_name}
+ ${program_pid}
```
+
Incorrect examples:
```
- ${var1} = Set Variable ${1}
- ${var1} = My Keyword
+ ${HostName}
+ ${ProgramPid}
```
-- General variable naming conventions:
- - Variable names should be lower case with few exceptions (listed here):
- - Environment variables should be all upper case.
- - Variables intended to be set by Robot -v parameters may be all
- upper case.
- - Words within a variable name should be separated by underscores:
- Correct examples:
- ```
- ${host_name}
- ${program_pid}
- ```
- Incorrect examples:
- ```
- ${HostName}
- ${ProgramPid}
- ```
- - Use good judgement in choosing variable names that are neither way too
- short nor way too long.
+ - Use good judgement in choosing variable names that are neither way too short
+ nor way too long.
- Correct examples:
- ```
- ${host_name}
- ${program_pid}
- ```
- Incorrect examples:
- ```
- ${HostName}
- ${ProgramPid}
- ```
- - Avoid having the variable's type as a suffix portion of the name:
+ Correct examples:
- Incorrect examples:
- ```
- ${inventory_dict}
- ${led_list}
- ```
-
- Incorrect examples:
- ```
- ${inventory}
- # Use plural name to indicate that it is a list.
- ${leds}
- ```
-
- A possible exception to this rule is when your keyword or function has
- an ongoing need to refer to one piece of data in more than one format
- (e.g. date_str, date_epoch, etc.).
-
- - Consistency of variable names:
-
- Try to avoid referring to the same data entity by multiple different
- names. It creates a lot of confusion for the reader.
-
- Incorrect example:
- ```
- # Why call the receiving variable rc (return code) when the keyword is
- # supposed to return status.
- ${rc}= Run Keyword And Return Status Bla Bla
- ```
-
- Correct example:
- ```
- ${status}= Run Keyword And Return Status Bla Bla
- ```
-
-- Special variable naming conventions.
-
- For certain very commonly used kinds of variables, please observe these
- conventions in order to achieve consistency throughout the code.
-
- - hosts
-
- When a variable is intended to contain **either** an IP address **or**
- a host name (whether long or short), please give it a suffix of "_host".
-
- Examples:
- ```
- openbmc_host
- os_host
- pdu_host
- openbmc_serial_host
- ```
- - host names
-
- For host names (long or short, e.g. "bmc1" or "bmc1.example.com"), use
- a suffix of _host_name.
-
- Examples:
- ```
- openbmc_host_name
- os_host_name
- pdu_host_name
- openbmc_serial_host_name
- ```
- - Short host names
-
- For short host names (e.g. "bmc1"), use a suffix of _host_short_name.
-
- Examples:
- ```
- openbmc_host_short_name
- os_host_short_name
- pdu_host_short_name
- openbmc_serial_host_short_name
- ```
- - IP addresses
-
- For IP addresses, use a suffix of _ip.
-
- Example:
- ```
- openbmc_ip
- os_ip
- pdu_ip
- openbmc_serial_ip
- ```
- - Files and directories:
- - Files:
- - If your variable is to contain only the file's name, use a suffix
- of _file_name.
-
- Examples:
- ```
- ffdc_file_name = "bmc1.170428.120200.ffdc"
- ```
- - If your variable is to contain the path to a file, use a suffix of
- _file_path. Bear in mind that a file path can be relative or
- absolute, so that should not be a consideration in whether to use
- the "_file_path" suffix.
-
- Examples:
- ```
- status_file_path = "bmc1.170428.120200.status"
- status_file_path = "subdir/bmc1.170428.120200.status"
- status_file_path = "./bmc1.170428.120200.status"
- status_file_path = "../bmc1.170428.120200.status"
- status_file_path = "/home/user1/status/bmc1.170428.120200.status"
- ```
- To re-iterate, it doesn't matter whether the contents of the
- variable are a relative or absolute path (as shown in the
- examples above). A file path is simply a value with enough
- information in it for the program to find the file.
-
- - If the variable **must** contain an absolute path (which should be
- the rare case), use a suffix _abs_file_path.
-
- - Directories:
- - Directory variables should follow the same conventions as file
- variables.
-
- - If your variable is to contain only the directory's name, use a
- suffix of _dir_name.
-
- Example:
- ```
- ffdc_dir_name = "ffdc"
- ```
- - If your variable is to contain the path to a directory, use a
- suffix of _dir_path. Bear in mind that a dir path can be
- relative or absolute, so that should not be a consideration in
- whether to use _dir_path.
-
- Examples:
- ```
- status_dir_path = "status/"
- status_dir_path = "subdir/status"
- status_dir_path = "./status/"
- status_dir_path = "../status/"
- status_dir_path = "/home/user1/status/"
- ```
- To re-iterate, it doesn't matter whether the contents of
- the variable are a relative or absolute path (as shown in
- the examples above). A dir path is simply a value with
- enough information in it for the program to find the
- directory.
-
- - If the variable **must** contain an absolute path (which
- should be the rare case), use a suffix _abs_dir_path.
- - IMPORTANT: As a programming convention, do pre-
- processing on all dir_path variables to ensure that they
- contain a trailing slash. If we follow that convention
- religiously, then when changes are made in other parts of
- the program, the programmer can count on the value having
- a trailing slash. Therefore, they can safely do this kind
- of thing:
- ```
- my_file_path = my_dir_path + my_file_name
- ```
- - Setup/Teardown keywords
-
- Use standardized names for setup and teardown keywords:
- - Suite Setup Execution
- - Suite Teardown Execution
- - Test Setup Execution
- - Test Teardown Execution
-- Traditional comments (i.e. using the hashtag style comments)
- - Please leave one space following the hashtag.
- ```
- #wrong
-
- # Right
- ```
- - Please use proper English punctuation:
- - Capitalize the first word in the sentence or phrase.
- - End sentences (or stand-alone phrases) with a period.
-
- - Do not keep commented-out code in your program. Instead, remove it
- entirely.
-- Robot Template Test Cases
- - Follow this format for Robot template test cases:
-
- Note: Documentation, Tags and Template lines are all required and should be coded in the order shown.
- ```
- Test Case Name
- [Documentation]
- [Tags]
- [Template]
- # arg1 arg2 etc.
- <arg1> <arg2>
-
- Example:
-
- Get Response Codes
- [Documentation] REST "Get" response status test.
- [Tags] Get_Response_Codes
- [Template] Execute Get And Check Response
-
- # expected_response_code url_path
- ${HTTP_OK} /org/
- ${HTTP_OK} /xyz/
- ${HTTP_OK} /xyz/openbmc_project/
- ${HTTP_OK} /xyz/openbmc_project/state/enumerate
- ${HTTP_NOT_FOUND} /xyz/i/dont/exist/
- ```
-
- Note: Normally, a template test case would have many rows of data arguments as in the example above.
- However, contributors frequently define multiple template test cases that each have only
- one row of data which may seem to defeat the value of using templates in the first place. However,
- it is done for these reasons:
- 1) Template tests are counted as a single test. The user may wish to have separate results for
- each call to the template function.
- 2) If any call to the template function fails, one would like FFDC data collected immediately
- and would like one set of FFDC data for EACH such failure.
-
-
-Python Coding Guidelines
------------------------
-- The minimum required Python version is 2.7.x. In the very near future, we
- will stop supporting python 2 and will require python 3.
-- Run pycodestyle on all Python files and correct errors to follow the
- guidelines in https://www.python.org/dev/peps/pep-0008/. Note that when
- python code is checked into gerrit, pycodestyle is run automatically on it.
-
- Example as run from a Linux command line:
```
- pycodestyle my_pgm.py
-
- my_pgm.py:41:1: E302 expected 2 blank lines, found 1
- my_pgm.py:58:52: W291 trailing whitespace
+ ${host_name}
+ ${program_pid}
```
-- Include doc strings in every function and follow the guidelines in
- https://www.python.org/dev/peps/pep-0257/.
- Example:
+ Incorrect examples:
+
```
- r"""
- Return the function name associated with the indicated stack frame.
-
- Description of argument(s):
- stack_frame_ix The index of the stack frame whose
- function name should be returned. If
- the caller does not specify a value,
- this function will set the value to 1
- which is the index of the caller's
- stack frame. If the caller is the
- wrapper function "print_func_name",
- this function will bump it up by 1.
- """
+ ${HostName}
+ ${ProgramPid}
```
-- As shown in the prior example, if your function has any arguments, include
- a "Description of argument(s)" section. This effectively serves as the
- help text for anyone wanting to use or understand your function. Include
- real data examples wherever possible and applicable.
-- Function definitions:
- - Put each function parameter on its own line:
- ```
- def func1(parm1,
- parm2):
- ```
-- Do not keep commented-out code in your program. Instead, remove it
- entirely.
-- When you define a python function, observe the following
- conventions:
- - Separate words with single underscores.
- - Use lower-case letters.
+ - Avoid having the variable's type as a suffix portion of the name:
+
+ Incorrect examples:
+
+ ```
+ ${inventory_dict}
+ ${led_list}
+ ```
+
+ Incorrect examples:
+
+ ```
+ ${inventory}
+ # Use plural name to indicate that it is a list.
+ ${leds}
+ ```
+
+ A possible exception to this rule is when your keyword or function has an
+ ongoing need to refer to one piece of data in more than one format (e.g.
+ date_str, date_epoch, etc.).
+
+ - Consistency of variable names:
+
+ Try to avoid referring to the same data entity by multiple different names.
+ It creates a lot of confusion for the reader.
+
+ Incorrect example:
+
+ ```
+ # Why call the receiving variable rc (return code) when the keyword is
+ # supposed to return status.
+ ${rc}= Run Keyword And Return Status Bla Bla
+ ```
+
+ Correct example:
+
+ ```
+ ${status}= Run Keyword And Return Status Bla Bla
+ ```
+
+- Special variable naming conventions.
+
+ For certain very commonly used kinds of variables, please observe these
+ conventions in order to achieve consistency throughout the code.
+
+ - hosts
+
+ When a variable is intended to contain **either** an IP address **or** a
+ host name (whether long or short), please give it a suffix of "\_host".
Examples:
- ```
-
- def this_is_correct():
-
- # This function name is correct.
-
- def This_Is_Incorrect():
-
- # This keyword name is incorrect because of the upper case letters used.
-
- def soisthis():
-
- # This keyword name is incorrect because of 1) a failure to
- # separate words with underscores.
```
-- Documentation strings:
- - Each documentation string should be phrased as an **English command**.
- Punctuate it correctly with the first word capitalized and a period at
- the end.
+ openbmc_host
+ os_host
+ pdu_host
+ openbmc_serial_host
+ ```
- Correct example:
- ```
- def boot_bmc():
- r"""
- Boot the BMC.
- """
- ```
- Incorrect example:
- ```
- def boot_bmc():
- r"""
- This function boots the BMC.
- """
+ - host names
- # The doc string above is not phrased as a command.
- ```
- - Doc strings should begin with a summary line which is one terse,
- descriptive sentence. Put additional commentary below.
+ For host names (long or short, e.g. "bmc1" or "bmc1.example.com"), use a
+ suffix of \_host_name.
- Correct example:
- ```
- def stop_sol_console_logging():
- r"""
- Stop system console logging and return log output.
+ Examples:
- Additional comments...
- """
- ```
- Incorrect example:
- ```
- def stop_sol_console_logging():
- r"""
- Stop system console logging. If there are multiple system console
- processes, they will all be stopped. If there is no existing log file
- this keyword will return an error message to that effect (and write that
- message to targ_file_path, if specified). NOTE: This keyword will not
- fail if there is no running system console process.
- """
+ ```
+ openbmc_host_name
+ os_host_name
+ pdu_host_name
+ openbmc_serial_host_name
+ ```
- # This summary is way too long.
- ```
-- General variable naming conventions:
- - Variable names should be lower case with few exceptions (listed here):
- - Environment variables should be all upper case.
- - Words within a variable name should be separated by underscores:
+ - Short host names
- Correct examples:
- ```
- ${host_name}
- ${program_pid}
- ```
- Incorrect examples:
- ```
- ${HostName}
- ${ProgramPid}
- ```
-- Special variable naming conventions.
+ For short host names (e.g. "bmc1"), use a suffix of \_host_short_name.
- For certain very commonly used kinds of variables, please observe these
- conventions in order to achieve consistency throughout the code.
+ Examples:
- - hosts
+ ```
+ openbmc_host_short_name
+ os_host_short_name
+ pdu_host_short_name
+ openbmc_serial_host_short_name
+ ```
- When a variable is intended to contain **either** an IP address **or**
- a host name (either long or short), please give it a suffix of "_host".
+ - IP addresses
+
+ For IP addresses, use a suffix of \_ip.
+
+ Example:
+
+ ```
+ openbmc_ip
+ os_ip
+ pdu_ip
+ openbmc_serial_ip
+ ```
+
+ - Files and directories:
+
+ - Files:
+
+ - If your variable is to contain only the file's name, use a suffix of
+ \_file_name.
Examples:
- ```
- openbmc_host
- os_host
- pdu_host
- openbmc_serial_host
- ```
- - host names
- For host names (long or short, e.g. "bmc1" or "bmc1.example.com"), use
- a suffix of _host_name.
+ ```
+ ffdc_file_name = "bmc1.170428.120200.ffdc"
+ ```
+
+ - If your variable is to contain the path to a file, use a suffix of
+ \_file_path. Bear in mind that a file path can be relative or absolute,
+ so that should not be a consideration in whether to use the
+ "\_file_path" suffix.
Examples:
- ```
- openbmc_host_name
- os_host_name
- pdu_host_name
- openbmc_serial_host_name
- ```
- - Short host names
- For short host names (e.g. "bmc1"), use a suffix of _host_short_name.
-
- Examples:
```
- openbmc_host_short_name
- os_host_short_name
- pdu_host_short_name
- openbmc_serial_host_short_name
+ status_file_path = "bmc1.170428.120200.status"
+ status_file_path = "subdir/bmc1.170428.120200.status"
+ status_file_path = "./bmc1.170428.120200.status"
+ status_file_path = "../bmc1.170428.120200.status"
+ status_file_path = "/home/user1/status/bmc1.170428.120200.status"
```
- - IP addresses
- For IP addresses, use a suffix of _ip.
+ To re-iterate, it doesn't matter whether the contents of the variable
+ are a relative or absolute path (as shown in the examples above). A file
+ path is simply a value with enough information in it for the program to
+ find the file.
+
+ - If the variable **must** contain an absolute path (which should be the
+ rare case), use a suffix \_abs_file_path.
+
+ - Directories:
+
+ - Directory variables should follow the same conventions as file
+ variables.
+
+ - If your variable is to contain only the directory's name, use a suffix
+ of \_dir_name.
Example:
+
```
- openbmc_ip
- os_ip
- pdu_ip
- openbmc_serial_ip
+ ffdc_dir_name = "ffdc"
```
-- Files and directories:
- - Files:
- - If your variable is to contain only the file's name, use a suffix
- of _file_name.
- Examples:
- ```
- ffdc_file_name = "bmc1.170428.120200.ffdc"
- ```
- - If your variable is to contain the path to a file, use a suffix of
- _file_path. Bear in mind that a file path can be relative or
- absolute, so that should not be a consideration in whether to use
- the "_file_path" suffix.
+ - If your variable is to contain the path to a directory, use a suffix of
+ \_dir_path. Bear in mind that a dir path can be relative or absolute, so
+ that should not be a consideration in whether to use \_dir_path.
- Examples:
- ```
- status_file_path = "bmc1.170428.120200.status"
- status_file_path = "subdir/bmc1.170428.120200.status"
- status_file_path = "./bmc1.170428.120200.status"
- status_file_path = "../bmc1.170428.120200.status"
- status_file_path = "/home/user1/status/bmc1.170428.120200.status"
- ```
- To re-iterate, it doesn't matter whether the contents of the
- variable are a relative or absolute path (as shown in the
- examples above). A file path is simply a value with enough
- information in it for the program to find the file.
+ Examples:
- - If the variable **must** contain an absolute path (which should be
- the rare case), use a suffix _abs_file_path.
-
- - Directories:
- - Directory variables should follow the same conventions as file
- variables.
-
- - If your variable is to contain only the directory's name, use a
- suffix of _dir_name.
-
- Example:
- ```
- ffdc_dir_name = "ffdc"
- ```
- - If your variable is to contain the path to a directory, use a
- suffix of _dir_path. Bear in mind that a dir path can be
- relative or absolute so, that should not be a consideration in
- whether to use _dir_path.
-
- Examples:
- ```
- status_dir_path = "status/"
- status_dir_path = "subdir/status"
- status_dir_path = "./status/"
- status_dir_path = "../status/"
- status_dir_path = "/home/user1/status/"
- ```
- To re-iterate, it doesn't matter whether the contents of
- the variable are a relative or absolute path (as shown in
- the examples above). A dir path is simply a value with
- enough information in it for the program to find the
- directory.
-
- - If the variable **must** contain an absolute path (which
- should be the rare case), use a suffix _abs_dir_path.
- - IMPORTANT: As a programming convention, do pre-
- processing on all dir_path variables to ensure that they
- contain a trailing slash. If we follow that convention
- religiously, that when changes are made in other parts of
- the program, the programmer can count on the value having
- a trailing slash. Therefore they can safely do this kind
- of thing:
- ```
- my_file_path = my_dir_path + my_file_name
- ```
-- Traditional comments (i.e. using the hashtag style comments)
- - Please leave one space following the hashtag.
```
- #wrong
-
- # Right
+ status_dir_path = "status/"
+ status_dir_path = "subdir/status"
+ status_dir_path = "./status/"
+ status_dir_path = "../status/"
+ status_dir_path = "/home/user1/status/"
```
- - Please use proper English punction:
- - Capitalize the first word in the sentence or phrase.
- - End sentences (or stand-alone phrases) with a period.
- - Do not keep commented-out code in your program. Instead, remove it
- entirely.
+ To re-iterate, it doesn't matter whether the contents of the variable
+ are a relative or absolute path (as shown in the examples above). A dir
+ path is simply a value with enough information in it for the program to
+ find the directory.
-Template Usage Requirements
----------------------------
+ - If the variable **must** contain an absolute path (which should be the
+ rare case), use a suffix \_abs_dir_path.
+ - IMPORTANT: As a programming convention, do pre- processing on all
+ dir_path variables to ensure that they contain a trailing slash. If we
+ follow that convention religiously, then when changes are made in other
+ parts of the program, the programmer can count on the value having a
+ trailing slash. Therefore, they can safely do this kind of thing:
+ ```
+ my_file_path = my_dir_path + my_file_name
+ ```
+
+ - Setup/Teardown keywords
+
+ Use standardized names for setup and teardown keywords:
+
+ - Suite Setup Execution
+ - Suite Teardown Execution
+ - Test Setup Execution
+ - Test Teardown Execution
+
+- Traditional comments (i.e. using the hashtag style comments)
+
+ - Please leave one space following the hashtag.
+
+ ```
+ #wrong
+
+ # Right
+ ```
+
+ - Please use proper English punctuation:
+
+ - Capitalize the first word in the sentence or phrase.
+ - End sentences (or stand-alone phrases) with a period.
+
+ - Do not keep commented-out code in your program. Instead, remove it entirely.
+
+- Robot Template Test Cases
+
+ - Follow this format for Robot template test cases:
+
+ Note: Documentation, Tags and Template lines are all required and should be
+ coded in the order shown.
+
+ ```
+ Test Case Name
+ [Documentation]
+ [Tags]
+ [Template]
+ # arg1 arg2 etc.
+ <arg1> <arg2>
+
+ Example:
+
+ Get Response Codes
+ [Documentation] REST "Get" response status test.
+ [Tags] Get_Response_Codes
+ [Template] Execute Get And Check Response
+
+ # expected_response_code url_path
+ ${HTTP_OK} /org/
+ ${HTTP_OK} /xyz/
+ ${HTTP_OK} /xyz/openbmc_project/
+ ${HTTP_OK} /xyz/openbmc_project/state/enumerate
+ ${HTTP_NOT_FOUND} /xyz/i/dont/exist/
+ ```
+
+ Note: Normally, a template test case would have many rows of data arguments
+ as in the example above. However, contributors frequently define multiple
+ template test cases that each have only one row of data which may seem to
+ defeat the value of using templates in the first place. However, it is done
+ for these reasons: 1) Template tests are counted as a single test. The user
+ may wish to have separate results for each call to the template function. 2)
+ If any call to the template function fails, one would like FFDC data
+ collected immediately and would like one set of FFDC data for EACH such
+ failure.
+
+## Python Coding Guidelines
+
+- The minimum required Python version is 2.7.x. In the very near future, we will
+ stop supporting python 2 and will require python 3.
+- Run pycodestyle on all Python files and correct errors to follow the
+ guidelines in https://www.python.org/dev/peps/pep-0008/. Note that when python
+ code is checked into gerrit, pycodestyle is run automatically on it.
+
+ Example as run from a Linux command line:
+
+ ```
+ pycodestyle my_pgm.py
+
+ my_pgm.py:41:1: E302 expected 2 blank lines, found 1
+ my_pgm.py:58:52: W291 trailing whitespace
+ ```
+
+- Include doc strings in every function and follow the guidelines in
+ https://www.python.org/dev/peps/pep-0257/.
+
+ Example:
+
+ ```
+ r"""
+ Return the function name associated with the indicated stack frame.
+
+ Description of argument(s):
+ stack_frame_ix The index of the stack frame whose
+ function name should be returned. If
+ the caller does not specify a value,
+ this function will set the value to 1
+ which is the index of the caller's
+ stack frame. If the caller is the
+ wrapper function "print_func_name",
+ this function will bump it up by 1.
+ """
+ ```
+
+- As shown in the prior example, if your function has any arguments, include a
+ "Description of argument(s)" section. This effectively serves as the help text
+ for anyone wanting to use or understand your function. Include real data
+ examples wherever possible and applicable.
+- Function definitions:
+
+ - Put each function parameter on its own line:
+
+ ```
+ def func1(parm1,
+
+ parm2):
+ ```
+
+- Do not keep commented-out code in your program. Instead, remove it entirely.
+- When you define a python function, observe the following conventions:
+
+ - Separate words with single underscores.
+ - Use lower-case letters.
+
+ Examples:
+
+ ```
+
+ def this_is_correct():
+
+ # This function name is correct.
+
+ def This_Is_Incorrect():
+
+ # This keyword name is incorrect because of the upper case letters used.
+
+ def soisthis():
+
+ # This keyword name is incorrect because of 1) a failure to
+ # separate words with underscores.
+
+ ```
+
+- Documentation strings:
+
+ - Each documentation string should be phrased as an **English command**.
+ Punctuate it correctly with the first word capitalized and a period at the
+ end.
+
+ Correct example:
+
+ ```
+ def boot_bmc():
+ r"""
+ Boot the BMC.
+ """
+ ```
+
+ Incorrect example:
+
+ ```
+ def boot_bmc():
+ r"""
+ This function boots the BMC.
+ """
+
+ # The doc string above is not phrased as a command.
+ ```
+
+ - Doc strings should begin with a summary line which is one terse, descriptive
+ sentence. Put additional commentary below.
+
+ Correct example:
+
+ ```
+ def stop_sol_console_logging():
+ r"""
+ Stop system console logging and return log output.
+
+ Additional comments...
+ """
+ ```
+
+ Incorrect example:
+
+ ```
+ def stop_sol_console_logging():
+ r"""
+ Stop system console logging. If there are multiple system console
+ processes, they will all be stopped. If there is no existing log file
+ this keyword will return an error message to that effect (and write that
+ message to targ_file_path, if specified). NOTE: This keyword will not
+ fail if there is no running system console process.
+ """
+
+ # This summary is way too long.
+ ```
+
+- General variable naming conventions:
+
+ - Variable names should be lower case with few exceptions (listed here):
+ - Environment variables should be all upper case.
+ - Words within a variable name should be separated by underscores:
+
+ Correct examples:
+
+ ```
+ ${host_name}
+ ${program_pid}
+ ```
+
+ Incorrect examples:
+
+ ```
+ ${HostName}
+ ${ProgramPid}
+ ```
+
+- Special variable naming conventions.
+
+ For certain very commonly used kinds of variables, please observe these
+ conventions in order to achieve consistency throughout the code.
+
+ - hosts
+
+ When a variable is intended to contain **either** an IP address **or** a
+ host name (either long or short), please give it a suffix of "\_host".
+
+ Examples:
+
+ ```
+ openbmc_host
+ os_host
+ pdu_host
+ openbmc_serial_host
+ ```
+
+ - host names
+
+ For host names (long or short, e.g. "bmc1" or "bmc1.example.com"), use a
+ suffix of \_host_name.
+
+ Examples:
+
+ ```
+ openbmc_host_name
+ os_host_name
+ pdu_host_name
+ openbmc_serial_host_name
+ ```
+
+ - Short host names
+
+ For short host names (e.g. "bmc1"), use a suffix of \_host_short_name.
+
+ Examples:
+
+ ```
+ openbmc_host_short_name
+ os_host_short_name
+ pdu_host_short_name
+ openbmc_serial_host_short_name
+ ```
+
+ - IP addresses
+
+ For IP addresses, use a suffix of \_ip.
+
+ Example:
+
+ ```
+ openbmc_ip
+ os_ip
+ pdu_ip
+ openbmc_serial_ip
+ ```
+
+- Files and directories:
+
+ - Files:
+
+ - If your variable is to contain only the file's name, use a suffix of
+ \_file_name.
+
+ Examples:
+
+ ```
+ ffdc_file_name = "bmc1.170428.120200.ffdc"
+ ```
+
+ - If your variable is to contain the path to a file, use a suffix of
+ \_file_path. Bear in mind that a file path can be relative or absolute, so
+ that should not be a consideration in whether to use the "\_file_path"
+ suffix.
+
+ Examples:
+
+ ```
+ status_file_path = "bmc1.170428.120200.status"
+ status_file_path = "subdir/bmc1.170428.120200.status"
+ status_file_path = "./bmc1.170428.120200.status"
+ status_file_path = "../bmc1.170428.120200.status"
+ status_file_path = "/home/user1/status/bmc1.170428.120200.status"
+ ```
+
+ To re-iterate, it doesn't matter whether the contents of the variable are
+ a relative or absolute path (as shown in the examples above). A file path
+ is simply a value with enough information in it for the program to find
+ the file.
+
+ - If the variable **must** contain an absolute path (which should be the
+ rare case), use a suffix \_abs_file_path.
+
+ - Directories:
+
+ - Directory variables should follow the same conventions as file variables.
+
+ - If your variable is to contain only the directory's name, use a suffix of
+ \_dir_name.
+
+ Example:
+
+ ```
+ ffdc_dir_name = "ffdc"
+ ```
+
+ - If your variable is to contain the path to a directory, use a suffix of
+ \_dir_path. Bear in mind that a dir path can be relative or absolute so,
+ that should not be a consideration in whether to use \_dir_path.
+
+ Examples:
+
+ ```
+ status_dir_path = "status/"
+ status_dir_path = "subdir/status"
+ status_dir_path = "./status/"
+ status_dir_path = "../status/"
+ status_dir_path = "/home/user1/status/"
+ ```
+
+ To re-iterate, it doesn't matter whether the contents of the variable are
+ a relative or absolute path (as shown in the examples above). A dir path
+ is simply a value with enough information in it for the program to find
+ the directory.
+
+ - If the variable **must** contain an absolute path (which should be the
+ rare case), use a suffix \_abs_dir_path.
+ - IMPORTANT: As a programming convention, do pre- processing on all dir_path
+ variables to ensure that they contain a trailing slash. If we follow that
+ convention religiously, that when changes are made in other parts of the
+ program, the programmer can count on the value having a trailing slash.
+ Therefore they can safely do this kind of thing:
+ ```
+ my_file_path = my_dir_path + my_file_name
+ ```
+
+- Traditional comments (i.e. using the hashtag style comments)
+
+ - Please leave one space following the hashtag.
+
+ ```
+ #wrong
+
+ # Right
+ ```
+
+ - Please use proper English punction:
+
+ - Capitalize the first word in the sentence or phrase.
+ - End sentences (or stand-alone phrases) with a period.
+
+ - Do not keep commented-out code in your program. Instead, remove it entirely.
+
+## Template Usage Requirements
+
We have several templates in the templates/ sub-directory. If there is a
-template that applies to your programming situation (Python, bash, etc.),
-it should be used to create new programs as in the following example
+template that applies to your programming situation (Python, bash, etc.), it
+should be used to create new programs as in the following example
- Example:
- ```
- $ cd templates
- $ cp python_pgm_template] ../bin/my_new_program.py
- ```
+ ```
+ $ cd templates
+ $ cp python_pgm_template] ../bin/my_new_program.py
+ ```
-These templates have much of your preliminary work done for you and will help
-us all follow a similar structure.
+These templates have much of your preliminary work done for you and will help us
+all follow a similar structure.
See [python_pgm_template](templates/python_pgm_template) as an example.
- Features:
- - Help text and arg parsing started for you.
- - Support for "stock" parameters like "quiet", "debug", "test_mode".
- - "exit_function" pre-defined.
- - "validate_parms" function pre-defined.
- - "main" function follows conventional startup sequence:
- ```
- gen_get_options(parser, stock_list)
+ - Help text and arg parsing started for you.
+ - Support for "stock" parameters like "quiet", "debug", "test_mode".
+ - "exit_function" pre-defined.
+ - "validate_parms" function pre-defined.
+ - "main" function follows conventional startup sequence:
- validate_parms()
+ ```
+ gen_get_options(parser, stock_list)
- qprint_pgm_header()
+ validate_parms()
- # Your code here.
- ```
+ qprint_pgm_header()
+
+ # Your code here.
+ ```
diff --git a/README.md b/README.md
index 503f658..05130e8 100644
--- a/README.md
+++ b/README.md
@@ -1,336 +1,389 @@
-## Features of OpenBMC Test Automation ##
+## Features of OpenBMC Test Automation
**Interface Feature List**
-* REST
-* DMTF Redfish
-* Out-of-band IPMI
-* SSH to BMC and Host OS
+
+- REST
+- DMTF Redfish
+- Out-of-band IPMI
+- SSH to BMC and Host OS
**Key Feature List**
-* Power on/off
-* Reboot Host
-* Reset BMC
-* Code update BMC and host
-* Power management
-* Fan controller
-* HTX bootme
-* XCAT execution
-* Network
-* IPMI support (generic and DCMI compliant)
-* Factory reset
-* RAS (Reliability, availability and serviceability)
-* Web UI testing
-* Secure boot
-* SNMP (Simple Network Management Protocol)
-* Remote Logging via Rsyslog
-* LDAP (Lightweight Directory Access Protocol)
-* Certificate
-* Local User Management(Redfish/IPMI)
-* DateTime
-* Event Logging
-* PLDM (Platform Level Data Model) via pldmtool
+
+- Power on/off
+- Reboot Host
+- Reset BMC
+- Code update BMC and host
+- Power management
+- Fan controller
+- HTX bootme
+- XCAT execution
+- Network
+- IPMI support (generic and DCMI compliant)
+- Factory reset
+- RAS (Reliability, availability and serviceability)
+- Web UI testing
+- Secure boot
+- SNMP (Simple Network Management Protocol)
+- Remote Logging via Rsyslog
+- LDAP (Lightweight Directory Access Protocol)
+- Certificate
+- Local User Management(Redfish/IPMI)
+- DateTime
+- Event Logging
+- PLDM (Platform Level Data Model) via pldmtool
**Debugging Supported List**
-* SOL collection
-* FFDC collection
-* Error injection from host
-## Installation Setup Guide ##
-* [Robot Framework Install Instruction](https://github.com/robotframework/robotframework/blob/master/INSTALL.rst)
+- SOL collection
+- FFDC collection
+- Error injection from host
-* Miscellaneous
-Packages required to be installed for OpenBmc Automation.
-Install the packages and it's dependencies via `pip`
+## Installation Setup Guide
-If using Python 3.x, use the corresponding `pip3` to install packages.
-Note: Older Python 2.x is not actively supported.
+- [Robot Framework Install Instruction](https://github.com/robotframework/robotframework/blob/master/INSTALL.rst)
+
+- Miscellaneous Packages required to be installed for OpenBmc Automation.
+ Install the packages and it's dependencies via `pip`
+
+If using Python 3.x, use the corresponding `pip3` to install packages. Note:
+Older Python 2.x is not actively supported.
REST base packages:
+
```
$ pip install -U requests
$ pip install -U robotframework-requests
$ pip install -U robotframework-httplibrary
```
-Python redfish library packages:
-For more detailed intstructions see [python-redfish-library](https://github.com/DMTF/python-redfish-library)
+Python redfish library packages: For more detailed intstructions see
+[python-redfish-library](https://github.com/DMTF/python-redfish-library)
+
```
$ pip install redfish
```
-SSH and SCP base packages:
-For more detailed installation instructions see [robotframework-sshlibrary](https://pypi.python.org/pypi/robotframework-sshlibrary)
+SSH and SCP base packages: For more detailed installation instructions see
+[robotframework-sshlibrary](https://pypi.python.org/pypi/robotframework-sshlibrary)
+
```
$ pip install robotframework-sshlibrary
$ pip install robotframework-scplibrary
```
Installing requirement dependencies:
+
```
$ pip install -r requirements.txt
```
+
you'll find this file once your clone openbmc-test-automation repository.
Installing tox:
+
```
$ pip install -U tox
```
Installing expect:
+
```
$ sudo apt-get install expect (Ubuntu example)
```
-## OpenBMC Test Development ##
+## OpenBMC Test Development
These documents contain details on developing OpenBMC test code and debugging.
- - [MAINTAINERS](MAINTAINERS): OpenBMC test code maintainers information.
- - [CONTRIBUTING.md](CONTRIBUTING.md): Coding guidelines.
- - [Code Check Tools](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/code_standards_check.md): To check common code misspellings, syntax and standard checks.
- - [REST-cheatsheet.md](https://github.com/openbmc/docs/blob/master/REST-cheatsheet.md): Quick reference for some common
- curl commands required for legacy REST testing.
- - [REDFISH-cheatsheet.md](https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md): Quick reference for some common
- curl commands required for redfish testing.
- - [README.md](https://github.com/openbmc/phosphor-webui/blob/master/README.md): Web UI setup reference.
- - [Corporate CLA and Individual CLA](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server): Submitting changes via Gerrit server
+- [MAINTAINERS](MAINTAINERS): OpenBMC test code maintainers information.
+- [CONTRIBUTING.md](CONTRIBUTING.md): Coding guidelines.
+- [Code Check Tools](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/code_standards_check.md):
+ To check common code misspellings, syntax and standard checks.
+- [REST-cheatsheet.md](https://github.com/openbmc/docs/blob/master/REST-cheatsheet.md):
+ Quick reference for some common curl commands required for legacy REST
+ testing.
+- [REDFISH-cheatsheet.md](https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md):
+ Quick reference for some common curl commands required for redfish testing.
+- [README.md](https://github.com/openbmc/phosphor-webui/blob/master/README.md):
+ Web UI setup reference.
+- [Corporate CLA and Individual CLA](https://github.com/openbmc/docs/blob/master/CONTRIBUTING.md#submitting-changes-via-gerrit-server):
+ Submitting changes via Gerrit server
-## OpenBMC Test Documentation ##
+## OpenBMC Test Documentation
- - [Tools](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/openbmc_test_tools.md): Reference information for helper tools.
- - [Code Update](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/code_update.md): Currently supported BMC and PNOR update.
- - [Certificate Generate](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/certificate_generate.md): Steps to create and install CA signed certificate.
+- [Tools](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/openbmc_test_tools.md):
+ Reference information for helper tools.
+- [Code Update](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/code_update.md):
+ Currently supported BMC and PNOR update.
+- [Certificate Generate](https://github.com/openbmc/openbmc-test-automation/blob/master/docs/certificate_generate.md):
+ Steps to create and install CA signed certificate.
-## Supported Systems Architecture ##
+## Supported Systems Architecture
- OpenBMC test infrastructure is proven capable of running on:
- - POWER
- - x86
- systems running OpenBMC firmware stack.
+OpenBMC test infrastructure is proven capable of running on:
-## Testing Setup Steps ##
+- POWER
+- x86 systems running OpenBMC firmware stack.
+
+## Testing Setup Steps
To verify the installation setup is completed and ready to execute.
-* Download the openbmc-test-automation repository:
- ```
- $ git clone https://github.com/openbmc/openbmc-test-automation
- $ cd openbmc-test-automation
- ```
-* Execute basic setup test run:
- ```
- $ robot -v OPENBMC_HOST:xx.xx.xx.xx templates/test_openbmc_setup.robot
- ```
- where xx.xx.xx.xx is the BMC hostname or IP.
+- Download the openbmc-test-automation repository:
+ ```
+ $ git clone https://github.com/openbmc/openbmc-test-automation
+ $ cd openbmc-test-automation
+ ```
+- Execute basic setup test run:
+ ```
+ $ robot -v OPENBMC_HOST:xx.xx.xx.xx templates/test_openbmc_setup.robot
+ ```
+ where xx.xx.xx.xx is the BMC hostname or IP.
-## Test Layout ##
+## Test Layout
There are several sub-directories within the openbmc-test-automation base which
-contain test suites, tools, templates, etc. These sub-directories are
-classified as follows:
+contain test suites, tools, templates, etc. These sub-directories are classified
+as follows:
`tests/`: Contains the general test cases for OpenBMC stack functional
- verification. The "tests" subdirectory uses legacy REST and will be
- deprecated at some point and therefore no longer supported.
+verification. The "tests" subdirectory uses legacy REST and will be deprecated
+at some point and therefore no longer supported.
-`extended/`: Contains test cases for boot testing, code update testing using legacy REST, etc.
+`extended/`: Contains test cases for boot testing, code update testing using
+legacy REST, etc.
`systest/`: Contains test cases for HTX bootme testing.
`xcat/`: Contains test cases for XCAT automation.
-`gui/test/`: Contains test cases for testing web-based interface built on AngularJS.
+`gui/test/`: Contains test cases for testing web-based interface built on
+AngularJS.
-`gui/gui_test/`: Contains test cases for testing web-based user interface built on Vue.js.
+`gui/gui_test/`: Contains test cases for testing web-based user interface built
+on Vue.js.
-`pldm/`: Contains test cases for platform management subsystem (base, bios, fru, platform, OEM).
+`pldm/`: Contains test cases for platform management subsystem (base, bios, fru,
+platform, OEM).
`snmp/`: Contains test cases for SNMP (Simple Network Management Protocol)
- configuration testing.
+configuration testing.
`openpower/ras/`: Contains test cases for RAS (Reliability, Availability and
- Serviceability) for an OpenPOWER system.
+Serviceability) for an OpenPOWER system.
-`openpower/secureboot/`: Contains test cases for secure boot testing on a
- secure boot feature enabled OpenPOWER system only.
+`openpower/secureboot/`: Contains test cases for secure boot testing on a secure
+boot feature enabled OpenPOWER system only.
`tools/`: Contains various tools.
`templates/`: Contains sample code examples and setup testing.
-`test_list/`: Contains the argument files used for skipping test cases
- (e.g "skip_test", "skip_test_extended", etc.) or
- grouping them (e.g "HW_CI", "CT_basic_run", etc.).
+`test_list/`: Contains the argument files used for skipping test cases (e.g
+"skip_test", "skip_test_extended", etc.) or grouping them (e.g "HW_CI",
+"CT_basic_run", etc.).
+## Redfish Test Layout
-## Redfish Test Layout ##
+OpenBMC is moving steadily towards DTMF Redfish, which is an open industry
+standard specification and schema that meets the expectations of end users for
+simple, modern and secure management of scalable platform hardware.
-OpenBMC is moving steadily towards DTMF Redfish, which is an open industry standard
-specification and schema that meets the expectations of end users for simple,
-modern and secure management of scalable platform hardware.
+`redfish/`: Contains test cases for DMTF Redfish-related feature supported on
+OpenBMC.
-`redfish/`: Contains test cases for DMTF Redfish-related feature supported on OpenBMC.
+`redfish/extended/`: Contains test cases for combined legacy REST and DMTF
+Redfish-related feature supported on OpenBMC.
-`redfish/extended/`: Contains test cases for combined legacy REST and DMTF Redfish-related
- feature supported on OpenBMC.
+Note: Work in progress test development parameter
+`-v REDFISH_SUPPORT_TRANS_STATE:1` to force the test suites to execute in
+redfish mode only.
-Note: Work in progress test development parameter `-v REDFISH_SUPPORT_TRANS_STATE:1` to force
- the test suites to execute in redfish mode only.
+## Quickstart
-
-## Quickstart ##
To run openbmc-automation first you need to install the prerequisite Python
-packages which will help to invoke tests through tox (Note that tox
-version 2.3.1 or greater is required) or via Robot CLI command.
+packages which will help to invoke tests through tox (Note that tox version
+2.3.1 or greater is required) or via Robot CLI command.
**Robot Command Line**
-* Execute all test suites for `tests/`:
- ```
- $ robot -v OPENBMC_HOST:xx.xx.xx.xx tests
- ```
+- Execute all test suites for `tests/`:
-* Execute a test suite:
- ```
- $ robot -v OPENBMC_HOST:xx.xx.xx.xx redfish/extended/test_basic_ci.robot
- ```
+ ```
+ $ robot -v OPENBMC_HOST:xx.xx.xx.xx tests
+ ```
-* Initialize the following test variables which will be used during test execution:
+- Execute a test suite:
- User can forward declare as environment variables:
- ```
- $ export OPENBMC_HOST=<openbmc machine IP address/hostname>
- $ export OPENBMC_USERNAME=<openbmc username>
- $ export OPENBMC_PASSWORD=<openbmc password>
- $ export IPMI_COMMAND=<Dbus/External>
- ```
+ ```
+ $ robot -v OPENBMC_HOST:xx.xx.xx.xx redfish/extended/test_basic_ci.robot
+ ```
- or
+- Initialize the following test variables which will be used during test
+ execution:
- User can input as robot variables as part of the CLI command:
- ```
- -v OPENBMC_HOST:<openbmc machine IP address/hostname>
- -v OPENBMC_USERNAME:<openbmc username>
- -v OPENBMC_PASSWORD:<openbmc password>
- ```
+ User can forward declare as environment variables:
-* For QEMU tests, set the following environment variables as well:
- ```
- $ export SSH_PORT=<ssh port number>
- $ export HTTPS_PORT=<https port number>
- ```
+ ```
+ $ export OPENBMC_HOST=<openbmc machine IP address/hostname>
+ $ export OPENBMC_USERNAME=<openbmc username>
+ $ export OPENBMC_PASSWORD=<openbmc password>
+ $ export IPMI_COMMAND=<Dbus/External>
+ ```
-* Run tests:
- ```
- $ tox tests
- ```
+ or
-* How to run individual test:
+ User can input as robot variables as part of the CLI command:
- One specific test:
- ```
- $ tox -e default -- --include Power_On_Test tests/test_basic_poweron.robot
- ```
- No preset environment variables, default configuration for all supported
- systems:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- tests
- ```
- No preset environment variables, one test case from a test suite:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- --include Power_On_Test tests/test_basic_poweron.robot
- ```
- No preset environment variables, the entire test suite:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- tests
- ```
+ ```
+ -v OPENBMC_HOST:<openbmc machine IP address/hostname>
+ -v OPENBMC_USERNAME:<openbmc username>
+ -v OPENBMC_PASSWORD:<openbmc password>
+ ```
- No preset environment variables, the entire test suite excluding test
- cases using argument file:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/skip_test tests
- ```
+- For QEMU tests, set the following environment variables as well:
- Exclude test list for supported systems:
- ```
- Palmetto: test_lists/skip_test_palmetto
- Witherspoon: test_lists/skip_test_witherspoon
- ```
+ ```
+ $ export SSH_PORT=<ssh port number>
+ $ export HTTPS_PORT=<https port number>
+ ```
+- Run tests:
-* Run IPMI tests:
+ ```
+ $ tox tests
+ ```
- Running only out-of-band IPMI tests:
- ```
- $ robot -v IPMI_COMMAND:External -v OPENBMC_HOST:x.x.x.x --argumentfile test_lists/witherspoon/skip_inband_ipmi tests/ipmi/
- ```
+- How to run individual test:
- Running only inband IPMI tests:
- ```
- $ robot -v IPMI_COMMAND:Inband -v OPENBMC_HOST:x.x.x.x -v OS_HOST:x.x.x.x -v OS_USERNAME:xxxx -v OS_PASSWORD:xxxx --argumentfile test_lists/witherspoon/skip_oob_ipmi tests/ipmi/
- ```
+ One specific test:
+ ```
+ $ tox -e default -- --include Power_On_Test tests/test_basic_poweron.robot
+ ```
-* Run GUI tests:
+ No preset environment variables, default configuration for all supported
+ systems:
- By default, GUI runs with Firefox browser and headless mode. Example with chrome browser and header mode:
- ```
- $ robot -v OPENBMC_HOST:x.x.x.x -v GUI_BROWSER:gc -v GUI_MODE:header gui/test/
- ```
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- tests
+ ```
- Run GUI default CI test bucket:
- ```
- $ robot -v OPENBMC_HOST:x.x.x.x --argumentfile test_lists/BMC_WEB_CI gui/test/
- ```
+ No preset environment variables, one test case from a test suite:
-* Run LDAP tests:
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- --include Power_On_Test tests/test_basic_poweron.robot
+ ```
- Before using LDAP test functions, be sure appropriate LDAP user(s) and group(s) have been created on your LDAP server.
- Note: There are multiple ways to create LDAP users / groups and all depend on your LDAP server.
- One common way for openldap is ldapadd / ldapmodify refer https://linux.die.net/man/1/ldapadd
- For ldapsearch, refer to "https://linux.die.net/man/1/ldapsearch".
- Microsoft ADS: refer to https://searchwindowsserver.techtarget.com/definition/Microsoft-Active-Directory-Domain-Services-AD-DS
+ No preset environment variables, the entire test suite:
- Note: Currently, LDAP test automation for Redfish API is in progress. The format to invoke LDAP test is as follows:
- ```
- $ cd redfish/account_service/
- $ robot -v OPENBMC_HOST:x.x.x.x -v LDAP_SERVER_URI:<ldap(s)//LDAP Hostname / IP> -v LDAP_BIND_DN:<LDAP Bind DN> -v LDAP_BASE_DN:<LDAP Base DN> -v LDAP_BIND_DN_PASSWORD:<LDAP Bind password> -v LDAP_SEARCH_SCOPE:<LDAP search scope> -v LDAP_SERVER_TYPE:<LDAP server type> -v LDAP_USER:<LDAP user-id> -v LDAP_USER_PASSWORD:<LDAP PASSWORD> -v GROUP_NAME:<Group Name> -v GROUP_PRIVILEGE:<Privilege> ./test_ldap_configuration.robot
- ```
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- tests
+ ```
-* How to run CI and CT bucket test:
+ No preset environment variables, the entire test suite excluding test cases
+ using argument file:
- Default CI test bucket list:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/HW_CI tests
- ```
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/skip_test tests
+ ```
- Default CI smoke test bucket list:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/CT_basic_run tests
- ```
+ Exclude test list for supported systems:
-* Run extended tests:
+ ```
+ Palmetto: test_lists/skip_test_palmetto
+ Witherspoon: test_lists/skip_test_witherspoon
+ ```
- For-loop test (default iteration is 10):
- ```
- $ robot -v OPENBMC_HOST:x.x.x.x -v OPENBMC_SYSTEMMODEL:xxxxxx -v ITERATION:n -v LOOP_TEST_COMMAND:xxxxxx extended/full_suite_regression.robot
- ```
+- Run IPMI tests:
- Example using tox testing a test suite for 5 iterations "witherspoon":
- ```
- OPENBMC_HOST=x.x.x.x LOOP_TEST_COMMAND="tests/test_fw_version.robot" ITERATION=5 OPENBMC_SYSTEMMODEL=witherspoon tox -e witherspoon -- ./extended/full_suite_regression.robot
- ```
+ Running only out-of-band IPMI tests:
-* Host CPU architecture
+ ```
+ $ robot -v IPMI_COMMAND:External -v OPENBMC_HOST:x.x.x.x --argumentfile test_lists/witherspoon/skip_inband_ipmi tests/ipmi/
+ ```
- By default openbmc-test-automation framework assumes that host CPU is based on the POWER architecture.
- If your host CPU is x86 add `-v PLATFORM_ARCH_TYPE:x86` variable setting to your CLI commands or set an environment variable:
- ```
- $ export PLATFORM_ARCH_TYPE=x86
- ```
+ Running only inband IPMI tests:
+
+ ```
+ $ robot -v IPMI_COMMAND:Inband -v OPENBMC_HOST:x.x.x.x -v OS_HOST:x.x.x.x -v OS_USERNAME:xxxx -v OS_PASSWORD:xxxx --argumentfile test_lists/witherspoon/skip_oob_ipmi tests/ipmi/
+ ```
+
+- Run GUI tests:
+
+ By default, GUI runs with Firefox browser and headless mode. Example with
+ chrome browser and header mode:
+
+ ```
+ $ robot -v OPENBMC_HOST:x.x.x.x -v GUI_BROWSER:gc -v GUI_MODE:header gui/test/
+ ```
+
+ Run GUI default CI test bucket:
+
+ ```
+ $ robot -v OPENBMC_HOST:x.x.x.x --argumentfile test_lists/BMC_WEB_CI gui/test/
+ ```
+
+- Run LDAP tests:
+
+ Before using LDAP test functions, be sure appropriate LDAP user(s) and
+ group(s) have been created on your LDAP server. Note: There are multiple ways
+ to create LDAP users / groups and all depend on your LDAP server. One common
+ way for openldap is ldapadd / ldapmodify refer
+ https://linux.die.net/man/1/ldapadd For ldapsearch, refer to
+ "https://linux.die.net/man/1/ldapsearch". Microsoft ADS: refer to
+ https://searchwindowsserver.techtarget.com/definition/Microsoft-Active-Directory-Domain-Services-AD-DS
+
+ Note: Currently, LDAP test automation for Redfish API is in progress. The
+ format to invoke LDAP test is as follows:
+
+ ```
+ $ cd redfish/account_service/
+ $ robot -v OPENBMC_HOST:x.x.x.x -v LDAP_SERVER_URI:<ldap(s)//LDAP Hostname / IP> -v LDAP_BIND_DN:<LDAP Bind DN> -v LDAP_BASE_DN:<LDAP Base DN> -v LDAP_BIND_DN_PASSWORD:<LDAP Bind password> -v LDAP_SEARCH_SCOPE:<LDAP search scope> -v LDAP_SERVER_TYPE:<LDAP server type> -v LDAP_USER:<LDAP user-id> -v LDAP_USER_PASSWORD:<LDAP PASSWORD> -v GROUP_NAME:<Group Name> -v GROUP_PRIVILEGE:<Privilege> ./test_ldap_configuration.robot
+ ```
+
+- How to run CI and CT bucket test:
+
+ Default CI test bucket list:
+
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/HW_CI tests
+ ```
+
+ Default CI smoke test bucket list:
+
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/CT_basic_run tests
+ ```
+
+- Run extended tests:
+
+ For-loop test (default iteration is 10):
+
+ ```
+ $ robot -v OPENBMC_HOST:x.x.x.x -v OPENBMC_SYSTEMMODEL:xxxxxx -v ITERATION:n -v LOOP_TEST_COMMAND:xxxxxx extended/full_suite_regression.robot
+ ```
+
+ Example using tox testing a test suite for 5 iterations "witherspoon":
+
+ ```
+ OPENBMC_HOST=x.x.x.x LOOP_TEST_COMMAND="tests/test_fw_version.robot" ITERATION=5 OPENBMC_SYSTEMMODEL=witherspoon tox -e witherspoon -- ./extended/full_suite_regression.robot
+ ```
+
+- Host CPU architecture
+
+ By default openbmc-test-automation framework assumes that host CPU is based on
+ the POWER architecture. If your host CPU is x86 add
+ `-v PLATFORM_ARCH_TYPE:x86` variable setting to your CLI commands or set an
+ environment variable:
+
+ ```
+ $ export PLATFORM_ARCH_TYPE=x86
+ ```
**Jenkins jobs tox commands**
-* HW CI tox command:
- ```
- $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/HW_CI tests
- ```
+
+- HW CI tox command:
+ ```
+ $ OPENBMC_HOST=x.x.x.x tox -e default -- --argumentfile test_lists/HW_CI tests
+ ```
diff --git a/data/applytime_table.json b/data/applytime_table.json
index 2bd0353..374d2f2 100644
--- a/data/applytime_table.json
+++ b/data/applytime_table.json
@@ -16,4 +16,3 @@
"Immediate": "Wait State os_running_match_state 10 mins"
}
}
-
diff --git a/data/oem/nuvoton/olympus.json b/data/oem/nuvoton/olympus.json
index 7c9de53..b2ecdf0 100644
--- a/data/oem/nuvoton/olympus.json
+++ b/data/oem/nuvoton/olympus.json
@@ -1,15 +1,14 @@
{
"npcm7xx": {
- "cpld" : {
- "fw1" : "2A01.svf",
- "fw1ver" : "00 00 2a 01",
- "fw2" : "2A02.svf",
- "fw2ver" : "00 00 2a 02",
- "readid" : "readid.svf",
- "readusercode" : "read_usercode.svf"
+ "cpld": {
+ "fw1": "2A01.svf",
+ "fw1ver": "00 00 2a 01",
+ "fw2": "2A02.svf",
+ "fw2ver": "00 00 2a 02",
+ "readid": "readid.svf",
+ "readusercode": "read_usercode.svf"
},
- "jtag_dev" : "/dev/jtag0",
- "power_cycle_cmd" : "/usr/sbin/i2cset -f -y 8 0x11 0xd9"
+ "jtag_dev": "/dev/jtag0",
+ "power_cycle_cmd": "/usr/sbin/i2cset -f -y 8 0x11 0xd9"
}
}
-
diff --git a/data/resource_lock_table.json b/data/resource_lock_table.json
index 771c3fe..735ab00 100644
--- a/data/resource_lock_table.json
+++ b/data/resource_lock_table.json
@@ -2,451 +2,599 @@
"Valid Case": {
"ResourceID": 234,
"ReadCase1": {
- "Read": [{
- "LockFlag": "LockAll",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase2": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase3": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 4
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 3
- }]
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 4
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 3
+ }
+ ]
},
"ReadCase4": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 2
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase5": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 2
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase6": {
- "Read": [{
- "LockFlag": "LockSame",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase7": {
- "Read": [{
- "LockFlag": "LockAll",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
+ "Read": [
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
},
"WriteCase1": {
- "Write": [{
- "LockFlag": "LockAll",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
+ "Write": [
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
},
"WriteCase2": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
},
"WriteCase3": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 4
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 3
- }]
- },
- "WriteCase4": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 2
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase5": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 2
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase6": {
- "Write": [{
- "LockFlag": "LockAll",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
- },
- "WriteCase7": {
- "Write": [{
- "LockFlag": "LockSame",
- "SegmentLength": 2
- }, {
- "LockFlag": "DontLock",
- "SegmentLength": 1
- }]
- }
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 4
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 3
+ }
+ ]
+ },
+ "WriteCase4": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase5": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase6": {
+ "Write": [
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase7": {
+ "Write": [
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 2
+ },
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 1
+ }
+ ]
+ }
},
"Invalid Case": {
"ResourceIDInvalidDataType": "234",
"ReadCase1": {
- "read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
+ "read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase2": {
- "READ": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
+ "READ": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase3": {
- "Red": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
+ "Red": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase4": {
- "*Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
+ "*Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
},
"ReadCase5": {
- "ReaD": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "ReadCase6": {
- "Read": [{
- "LockFlag": "lockall",
- "SegmentLength": 1
- }]
- },
- "ReadCase7": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "locksame",
- "SegmentLength": 1
- }]
- },
- "ReadCase8": {
- "Read": [{
- "LockFlag": "dontlock",
- "SegmentLength": 3
- }, {
- "LockFlag": "locksame",
- "SegmentLength": 1
- }]
- },
- "ReadCase9": {
- "Read": [{
- "LockFlag": "ontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "ReadCase10": {
- "Read": [{
- "LockFlag": "*DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "ReadCase11": {
- "Read": [{
- "LockFlag": "dontlock",
- "SegmentLength": 3
- }, {
- "LockFlag": "lockall",
- "SegmentLength": 1
- }]
- },
- "ReadCase12": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 7
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 0
- }]
- },
- "ReadCase13": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 0
- }]
- },
- "ReadCase14": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 7
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "ReadCase15": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": "3"
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "ReadCase16": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": "1"
- }]
- },
- "ReadCase17": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": "Three"
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "ReadCase18": {
- "Read": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": "One"
- }]
- },
- "WriteCase1": {
- "write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase2": {
- "WRITE": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase3": {
- "*Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase4": {
- "Wrte": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase5": {
- "WritE": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockSame",
- "SegmentLength": 1
- }]
- },
- "WriteCase6": {
- "Write": [{
- "LockFlag": "lockall",
- "SegmentLength": 1
- }]
- },
- "WriteCase7": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "locksame",
- "SegmentLength": 1
- }]
- },
- "WriteCase8": {
- "Write": [{
- "LockFlag": "dontlock",
- "SegmentLength": 3
- }, {
- "LockFlag": "locksame",
- "SegmentLength": 1
- }]
- },
- "WriteCase9": {
- "Write": [{
- "LockFlag": "ontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase10": {
- "Write": [{
- "LockFlag": "*DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase11": {
- "Write": [{
- "LockFlag": "dontlock",
- "SegmentLength": 3
- }, {
- "LockFlag": "lockall",
- "SegmentLength": 1
- }]
- },
- "WriteCase12": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 7
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 0
- }]
- },
- "WriteCase13": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 0
- }]
- },
- "WriteCase14": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 7
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase15": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": "3"
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase16": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": "1"
- }]
- },
- "WriteCase17": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": "Three"
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": 1
- }]
- },
- "WriteCase18": {
- "Write": [{
- "LockFlag": "DontLock",
- "SegmentLength": 3
- }, {
- "LockFlag": "LockAll",
- "SegmentLength": "One"
- }]
- }
+ "ReaD": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase6": {
+ "Read": [
+ {
+ "LockFlag": "lockall",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase7": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "locksame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase8": {
+ "Read": [
+ {
+ "LockFlag": "dontlock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "locksame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase9": {
+ "Read": [
+ {
+ "LockFlag": "ontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase10": {
+ "Read": [
+ {
+ "LockFlag": "*DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase11": {
+ "Read": [
+ {
+ "LockFlag": "dontlock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "lockall",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase12": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 7
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 0
+ }
+ ]
+ },
+ "ReadCase13": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 0
+ }
+ ]
+ },
+ "ReadCase14": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 7
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase15": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": "3"
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase16": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": "1"
+ }
+ ]
+ },
+ "ReadCase17": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": "Three"
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "ReadCase18": {
+ "Read": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": "One"
+ }
+ ]
+ },
+ "WriteCase1": {
+ "write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase2": {
+ "WRITE": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase3": {
+ "*Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase4": {
+ "Wrte": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase5": {
+ "WritE": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockSame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase6": {
+ "Write": [
+ {
+ "LockFlag": "lockall",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase7": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "locksame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase8": {
+ "Write": [
+ {
+ "LockFlag": "dontlock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "locksame",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase9": {
+ "Write": [
+ {
+ "LockFlag": "ontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase10": {
+ "Write": [
+ {
+ "LockFlag": "*DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase11": {
+ "Write": [
+ {
+ "LockFlag": "dontlock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "lockall",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase12": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 7
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 0
+ }
+ ]
+ },
+ "WriteCase13": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 0
+ }
+ ]
+ },
+ "WriteCase14": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 7
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase15": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": "3"
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase16": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": "1"
+ }
+ ]
+ },
+ "WriteCase17": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": "Three"
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": 1
+ }
+ ]
+ },
+ "WriteCase18": {
+ "Write": [
+ {
+ "LockFlag": "DontLock",
+ "SegmentLength": 3
+ },
+ {
+ "LockFlag": "LockAll",
+ "SegmentLength": "One"
+ }
+ ]
+ }
}
}
diff --git a/data/task_state.json b/data/task_state.json
index 14accd3..2fa30c6 100644
--- a/data/task_state.json
+++ b/data/task_state.json
@@ -14,10 +14,7 @@
},
"TaskService": {
"CompletedTaskOverWritePolicy": {
- "AllowedValues": [
- "Manual",
- "Oldest"
- ]
+ "AllowedValues": ["Manual", "Oldest"]
},
"Status": {
"Health": "OK",
@@ -49,4 +46,4 @@
]
}
}
-}
\ No newline at end of file
+}
diff --git a/docs/boot_test.md b/docs/boot_test.md
index 52fa2c4..2297249 100644
--- a/docs/boot_test.md
+++ b/docs/boot_test.md
@@ -1,15 +1,19 @@
Boot test is one of the cornerstone of OpenBMC test infrastructure.
-The boot plugins are used in the test and as well can be use a stand-alone mechanism to test your system to run variety of supported boot sequences.
+The boot plugins are used in the test and as well can be use a stand-alone
+mechanism to test your system to run variety of supported boot sequences.
**Boot test sequence example:**
```
robot -v OPENBMC_HOST:xx.xx.xx.xx -v 'boot_stack:<boot1>:<boot2>:<bootn>:' extended/obmc_boot_test.robot
```
-Where <bootx> is the supported boot type listed in the [data/boot_lists/All](https://github.com/openbmc/openbmc-test-automation/blob/master/data/boot_lists/All)
+
+Where <bootx> is the supported boot type listed in the
+[data/boot_lists/All](https://github.com/openbmc/openbmc-test-automation/blob/master/data/boot_lists/All)
**Example:**
+
```
robot -v OPENBMC_HOST:xx.xx.xx.xx -v 'boot_stack:Redfish Power On:Redfish Power Off' extended/obmc_boot_test.robot
```
diff --git a/docs/certificate_generate.md b/docs/certificate_generate.md
index 2a184ef..ff6c934 100644
--- a/docs/certificate_generate.md
+++ b/docs/certificate_generate.md
@@ -10,22 +10,21 @@
D. Install CA signed server certificate
-
**Create your own SSL certificate authority**
1. Create private key for certificate authority(CA).
+`openssl genrsa -des3 -out rootCA.key 2048`
-```openssl genrsa -des3 -out rootCA.key 2048```
-
-Note: You will be prompted to give a password for private key. This password will be used whenever the private key is used.
-
+Note: You will be prompted to give a password for private key. This password
+will be used whenever the private key is used.
2. Create a root CA certificate using the private key created in step 1.
-```openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem```
+`openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.pem`
-This will start an interactive script to enter information that will be incorporated into your certificate request.
+This will start an interactive script to enter information that will be
+incorporated into your certificate request.
```
You are about to be asked to enter information that will be incorporated
@@ -64,6 +63,7 @@
```
Example:
+
```
{
"City": "Austin",
@@ -115,14 +115,17 @@
**Create CA signed server certificate using CSR request**
-1. Use BMC generated CSR request (device.csr) to generate CA signed certificate (device.crt).
+1. Use BMC generated CSR request (device.csr) to generate CA signed certificate
+ (device.crt).
+
```
openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 500 -sha256
```
+
Note: You will be prompted to give a password for private key.
-
-2. Create JSON file (certificate.json) with the device.crt file created in step 1.
+2. Create JSON file (certificate.json) with the device.crt file created in
+ step 1.
```
$ cat certificate.json
@@ -136,10 +139,10 @@
}
```
-
**Install CA signed server certificate**
-Replace server certificate using JSON file (above) with CA signed certificate details (certificate.json).
+Replace server certificate using JSON file (above) with CA signed certificate
+details (certificate.json).
```
$ curl -c cjar -b cjar -k -H "X-Auth-Token: $bmc_token" -X POST https://${BMC_IP}/redfish/v1/CertificateService/Actions/CertificateService.ReplaceCertificate/ -d @certificate.json
diff --git a/docs/code_standards_check.md b/docs/code_standards_check.md
index 8b5e957..f5d7744 100644
--- a/docs/code_standards_check.md
+++ b/docs/code_standards_check.md
@@ -7,13 +7,15 @@
### 1. codespell
-Project [codespell](https://github.com/codespell-project/codespell) designed primarily for checking misspelled words in source code
+Project [codespell](https://github.com/codespell-project/codespell) designed
+primarily for checking misspelled words in source code
```
$ pip install codespell
```
Example:
+
```
$ codespell templates/test_openbmc_setup.robot
templates/test_openbmc_setup.robot:13: setings ==> settings
@@ -21,26 +23,31 @@
### 2. robotframework-lint
-Project [robotframework-lint](https://pypi.org/project/robotframework-lint/) for static analysis for robot framework plain text files.
+Project [robotframework-lint](https://pypi.org/project/robotframework-lint/) for
+static analysis for robot framework plain text files.
```
$ pip install –upgrade robotframework-lint
- ```
+```
Example:
+
```
$ rflint redfish/service_root/test_service_root_security.robot
+ redfish/service_root/test_service_root_security.robot
W: 19, 100: Line is too long (exceeds 100 characters) (LineTooLong)
```
-You can refer a script with example as well [custom rules](https://github.com/openbmc/openbmc-test-automation/blob/master/robot_custom_rules.py)
+You can refer a script with example as well
+[custom rules](https://github.com/openbmc/openbmc-test-automation/blob/master/robot_custom_rules.py)
### 3. robot tags check
-Project [check_robot_tags](https://github.com/generatz/check_robot_tags) Checks that Tags are equivalent to test case names or task names.
+Project [check_robot_tags](https://github.com/generatz/check_robot_tags) Checks
+that Tags are equivalent to test case names or task names.
Example:
+
```
$ git clone https://github.com/generatz/check_robot_tags
$ cd check_robot_tags/
diff --git a/docs/code_update.md b/docs/code_update.md
index b3fbc84..90c2ef5 100644
--- a/docs/code_update.md
+++ b/docs/code_update.md
@@ -1,203 +1,211 @@
-## Code Update ##
+## Code Update
-#### Redfish Code Update ####
+#### Redfish Code Update
-Currently supported BMC and PNOR update formats are UBI.
-For code update information, please refer to [code-update.md](https://github.com/openbmc/docs/blob/master/code-update/code-update.md)
+Currently supported BMC and PNOR update formats are UBI. For code update
+information, please refer to
+[code-update.md](https://github.com/openbmc/docs/blob/master/code-update/code-update.md)
-* UBI Format
+- UBI Format
- For BMC code update, download the system type *.ubi.mdt.tar image from
- https://jenkins.openbmc.org/job/latest-master/ and run as follows:
+ For BMC code update, download the system type \*.ubi.mdt.tar image from
+ https://jenkins.openbmc.org/job/latest-master/ and run as follows:
- For Witherspoon system:
- ```
- * Code Update with OnReset Policy
+ For Witherspoon system:
- $ cd redfish/update_service/test_redfish_bmc_code_update.robot
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include Redfish_Code_Update_With_ApplyTime_OnReset redfish/update_service/test_redfish_bmc_code_update.robot
+ ```
+ * Code Update with OnReset Policy
- * Code Update with Immediate Policy
+ $ cd redfish/update_service/test_redfish_bmc_code_update.robot
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include Redfish_Code_Update_With_ApplyTime_OnReset redfish/update_service/test_redfish_bmc_code_update.robot
- $ cd redfish/update_service/test_redfish_bmc_code_update.robot
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include Redfish_Code_Update_With_ApplyTime_Immediate redfish/update_service/test_redfish_bmc_code_update.robot
- ```
+ * Code Update with Immediate Policy
- For host code update, download the system type *.pnor.squashfs.tar image
- from https://openpower.xyz/job/openpower-op-build/ and run as follows:
+ $ cd redfish/update_service/test_redfish_bmc_code_update.robot
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include Redfish_Code_Update_With_ApplyTime_Immediate redfish/update_service/test_redfish_bmc_code_update.robot
+ ```
- For Witherspoon system:
- ```
- * Code Update with OnReset Policy
+ For host code update, download the system type \*.pnor.squashfs.tar image from
+ https://openpower.xyz/job/openpower-op-build/ and run as follows:
- $ cd redfish/update_service/test_redfish_host_code_update.robot
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include Redfish_Code_Update_With_ApplyTime_OnReset redfish/update_service/test_redfish_host_code_update.robot
+ For Witherspoon system:
- * Code Update with Immediate Policy
+ ```
+ * Code Update with OnReset Policy
- $ cd redfish/update_service/test_redfish_host_code_update.robot
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include Redfish_Code_Update_With_ApplyTime_Immediate redfish/update_service/test_redfish_host_code_update.robot
- ```
+ $ cd redfish/update_service/test_redfish_host_code_update.robot
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include Redfish_Code_Update_With_ApplyTime_OnReset redfish/update_service/test_redfish_host_code_update.robot
-#### REST Code Update ####
+ * Code Update with Immediate Policy
-Currently supported BMC and PNOR update formats are UBI and non-UBI.
-For code update information, please refer to [code-update.md](https://github.com/openbmc/docs/blob/master/code-update/code-update.md)
+ $ cd redfish/update_service/test_redfish_host_code_update.robot
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include Redfish_Code_Update_With_ApplyTime_Immediate redfish/update_service/test_redfish_host_code_update.robot
+ ```
+#### REST Code Update
-* UBI Format
+Currently supported BMC and PNOR update formats are UBI and non-UBI. For code
+update information, please refer to
+[code-update.md](https://github.com/openbmc/docs/blob/master/code-update/code-update.md)
- For BMC code update, download the system type *.ubi.mdt.tar image from
- https://jenkins.openbmc.org/job/latest-master/ and run as follows:
+- UBI Format
- For Witherspoon system:
- ```
- $ cd extended/code_update/
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include REST_BMC_Code_Update bmc_code_update.robot
- ```
+ For BMC code update, download the system type \*.ubi.mdt.tar image from
+ https://jenkins.openbmc.org/job/latest-master/ and run as follows:
- For host code update, download the system type *.pnor.squashfs.tar image
- from https://openpower.xyz/job/openpower-op-build/ and run as follows:
+ For Witherspoon system:
- For Witherspoon system:
- ```
- $ cd extended/code_update/
- $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include REST_Host_Code_Update host_code_update.robot
- ```
+ ```
+ $ cd extended/code_update/
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/obmc-phosphor-image-witherspoon.ubi.mtd.tar --include REST_BMC_Code_Update bmc_code_update.robot
+ ```
-* Non-UBI Format
+ For host code update, download the system type \*.pnor.squashfs.tar image from
+ https://openpower.xyz/job/openpower-op-build/ and run as follows:
- For BMC code update, download the system type *all.tar image from
- https://jenkins.openbmc.org/job/latest-master/ and run as follows:
+ For Witherspoon system:
- For a Zaius system:
- ```
- $ cd extended/code_update/
- $ robot -v OPENBMC_HOST:x.x.x.x -v FILE_PATH:<image path>/zaius-<date time>.all.tar --include Initiate_Code_Update_BMC update_bmc.robot
- ```
+ ```
+ $ cd extended/code_update/
+ $ robot -v OPENBMC_HOST:x.x.x.x -v IMAGE_FILE_PATH:<image path>/witherspoon.pnor.squashfs.tar --include REST_Host_Code_Update host_code_update.robot
+ ```
- For host code update, download the system type *.pnor from
- https://openpower.xyz/job/openpower-op-build/ and run as follows:
+- Non-UBI Format
- For a Zaius system:
- ```
- $ cd extended/
- $ robot -v OPENBMC_HOST:x.x.x.x -v PNOR_IMAGE_PATH:<image path>/zaius.pnor test_bios_update.robot
- ```
+ For BMC code update, download the system type \*all.tar image from
+ https://jenkins.openbmc.org/job/latest-master/ and run as follows:
-#### Generating Bad Firmware Image for testing ####
+ For a Zaius system:
-Procedure is to create bad firmware image for BMC and same steps applicable for Host image.
+ ```
+ $ cd extended/code_update/
+ $ robot -v OPENBMC_HOST:x.x.x.x -v FILE_PATH:<image path>/zaius-<date time>.all.tar --include Initiate_Code_Update_BMC update_bmc.robot
+ ```
-* No MANIFEST file
+ For host code update, download the system type \*.pnor from
+ https://openpower.xyz/job/openpower-op-build/ and run as follows:
- ```
- Command to list the content of the firmware image.
+ For a Zaius system:
- tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
- -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
- -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
- -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
- -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
- -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
- -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
+ ```
+ $ cd extended/
+ $ robot -v OPENBMC_HOST:x.x.x.x -v PNOR_IMAGE_PATH:<image path>/zaius.pnor test_bios_update.robot
+ ```
- Delete MANIFEST file from the tar firmware image.
+#### Generating Bad Firmware Image for testing
- tar --delete -vf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar MANIFEST
+Procedure is to create bad firmware image for BMC and same steps applicable for
+Host image.
- tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
- -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
- -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
- -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
- -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
- -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
+- No MANIFEST file
- Command to re-name tar firmware image.
+ ```
+ Command to list the content of the firmware image.
- mv obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar bmc_bad_manifest.ubi.mtd.tar
- ```
+ tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
+ -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
+ -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
+ -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
+ -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
+ -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
+ -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
-* No kernel image
+ Delete MANIFEST file from the tar firmware image.
- ```
- Command to list the content of the firmware image.
+ tar --delete -vf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar MANIFEST
- tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
- -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
- -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
- -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
- -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
- -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
- -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
+ tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
+ -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
+ -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
+ -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
+ -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
+ -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
- Delete image-kernel file from the tar firmware image.
+ Command to re-name tar firmware image.
- tar --delete -vf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar image-kernel
+ mv obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar bmc_bad_manifest.ubi.mtd.tar
+ ```
- tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
- -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
- -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
- -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
- -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
- -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
- -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
+- No kernel image
- Command to re-name tar firmware image.
+ ```
+ Command to list the content of the firmware image.
- mv obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar bmc_nokernel_image.ubi.mtd.tar
- ```
+ tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
+ -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
+ -rw-r--r-- jenkins-op/jenkins-op 3039300 2021-05-12 03:32 image-kernel
+ -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
+ -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
+ -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
+ -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
-* Invalid key image
+ Delete image-kernel file from the tar firmware image.
- ```
- Command to untar the firmware image.
+ tar --delete -vf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar image-kernel
- tar -xvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar -C /directory_path/untar_files/
- image-u-boot
- image-kernel
- image-rofs
- image-rwfs
- MANIFEST
- publickey
- image-u-boot.sig
- image-kernel.sig
- image-rofs.sig
- image-rwfs.sig
- MANIFEST.sig
- publickey.sig
- image-full.sig
+ tar -tvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar
+ -rw-r--r-- jenkins-op/jenkins-op 306804 2021-05-15 22:00 image-u-boot
+ -rw-r--r-- jenkins-op/jenkins-op 19861504 2021-05-15 22:00 image-rofs
+ -rw-r--r-- jenkins-op/jenkins-op 850304 2021-05-15 22:00 image-rwfs
+ -rw-r--r-- jenkins-op/jenkins-op 176 2021-05-15 22:00 MANIFEST
+ -rw-r--r-- jenkins-op/jenkins-op 272 2021-05-15 22:00 publickey
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-u-boot.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-kernel.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rofs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-rwfs.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 MANIFEST.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 publickey.sig
+ -rw-r--r-- jenkins-op/jenkins-op 128 2021-05-15 22:00 image-full.sig
- Change few random characters in public key file that in turn corrupts the public key file.
+ Command to re-name tar firmware image.
- Command to tar the firmware image files.
+ mv obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar bmc_nokernel_image.ubi.mtd.tar
+ ```
- tar -cvf bmc_invalid_key.ubi.mtd.tar *
- ```
+- Invalid key image
+
+ ```
+ Command to untar the firmware image.
+
+ tar -xvf obmc-phosphor-image-witherspoon-20210516025203.ubi.mtd.tar -C /directory_path/untar_files/
+ image-u-boot
+ image-kernel
+ image-rofs
+ image-rwfs
+ MANIFEST
+ publickey
+ image-u-boot.sig
+ image-kernel.sig
+ image-rofs.sig
+ image-rwfs.sig
+ MANIFEST.sig
+ publickey.sig
+ image-full.sig
+
+ Change few random characters in public key file that in turn corrupts the public key file.
+
+ Command to tar the firmware image files.
+
+ tar -cvf bmc_invalid_key.ubi.mtd.tar *
+ ```
diff --git a/docs/openbmc_test_architecture.md b/docs/openbmc_test_architecture.md
index ad9ec37..292bd8f 100644
--- a/docs/openbmc_test_architecture.md
+++ b/docs/openbmc_test_architecture.md
@@ -22,8 +22,8 @@
```
-NOTE: Legacy REST will be deprecated at some point and therefore no longer supported.
-
+NOTE: Legacy REST will be deprecated at some point and therefore no longer
+supported.
### OpenBMC Test Method Supports
diff --git a/docs/openbmc_test_tools.md b/docs/openbmc_test_tools.md
index 796710b..3fba3b3 100644
--- a/docs/openbmc_test_tools.md
+++ b/docs/openbmc_test_tools.md
@@ -1,155 +1,171 @@
-## Tools used in OpenBMC Test Automation ##
+## Tools used in OpenBMC Test Automation
-## IPMItool considerations: ##
+## IPMItool considerations:
IPMItool version 1.8.18 or later.
+
```
$ ipmitool -V
ipmitool version 1.8.18
```
-## Hardware Test Executive (HTX): ##
+## Hardware Test Executive (HTX):
-HTX is a suite of test tools for stressing system hardware. It is routinely
-used by the test suites under `systest/`. Refer to [README](https://github.com/open-power/HTX)
+HTX is a suite of test tools for stressing system hardware. It is routinely used
+by the test suites under `systest/`. Refer to
+[README](https://github.com/open-power/HTX)
-## Remote Logging via Rsyslog ##
+## Remote Logging via Rsyslog
-Refer to [README](https://github.com/openbmc/phosphor-logging/blob/master/README.md#remote-logging-via-rsyslog)
+Refer to
+[README](https://github.com/openbmc/phosphor-logging/blob/master/README.md#remote-logging-via-rsyslog)
-## Converting SELs to readable format: ##
+## Converting SELs to readable format:
Pre-requisite: A Power Linux system is required.
-* Obtain the SEL (System Error Log) parser tools:
- - Go to https://openpower.xyz/job/openpower/job/openpower-op-build/
- - Click the link for the BMC system of interest (e.g. witherspoon)
- - Click the "host_fw_debug.tar" link in order to download the tar file.
- - On your Power Linux system, untar the file with the following command:
- ```
- $ tar -xvf host_fw_debug.tar
- ```
+- Obtain the SEL (System Error Log) parser tools:
- - Rename the untarred files with:
- ```
- $ for file_name in host_fw_debug* ; do mv $file_name ${file_name#host_fw_debug} ; done
- ```
+ - Go to https://openpower.xyz/job/openpower/job/openpower-op-build/
+ - Click the link for the BMC system of interest (e.g. witherspoon)
+ - Click the "host_fw_debug.tar" link in order to download the tar file.
+ - On your Power Linux system, untar the file with the following command:
- The files of interest are:
- eSEL.pl
- hbotStringFile
- hbicore.syms
+ ```
+ $ tar -xvf host_fw_debug.tar
+ ```
-* The error log binary parser is also required:
- - Go to https://sourceforge.net/projects/linux-diag/files/ppc64-diag/
- - Download the latest release version of the source tar zipped.
- - Extract the tarball and compile. Refer to README in the source.
- - On successful compilation, get `opal-elog-parse` binary.
+ - Rename the untarred files with:
-* To generate a readable error log from binary SEL data:
+ ```
+ $ for file_name in host_fw_debug* ; do mv $file_name ${file_name#host_fw_debug} ; done
+ ```
- Create a directory and copy the binary files there. Next,
+ The files of interest are: eSEL.pl hbotStringFile hbicore.syms
- ```
- $ export PATH=$PATH:<path to directory>
- ```
- And run
- ```
- $ eSEL.pl -l SEL_data -p decode_obmc_data --op
- ```
- where `SEL_data` is the file containing SEL binary data and option "--op"
- will refer "opal-elog-parse" instead or errl.
+- The error log binary parser is also required:
- The output file `SEL_data.txt` contains the readable error log (SEL) data.
+ - Go to https://sourceforge.net/projects/linux-diag/files/ppc64-diag/
+ - Download the latest release version of the source tar zipped.
+ - Extract the tarball and compile. Refer to README in the source.
+ - On successful compilation, get `opal-elog-parse` binary.
+- To generate a readable error log from binary SEL data:
-## The opal-prd Tool: ##
-opal-prd is a tool used by the Energy Scale and RAS tests. It should be
+ Create a directory and copy the binary files there. Next,
+
+ ```
+ $ export PATH=$PATH:<path to directory>
+ ```
+
+ And run
+
+ ```
+ $ eSEL.pl -l SEL_data -p decode_obmc_data --op
+ ```
+
+ where `SEL_data` is the file containing SEL binary data and option "--op" will
+ refer "opal-elog-parse" instead or errl.
+
+ The output file `SEL_data.txt` contains the readable error log (SEL) data.
+
+## The opal-prd Tool:
+
+opal-prd is a tool used by the Energy Scale and RAS tests. It should be
installed on the OS of the system under test before running those tests.
-opal-prd may be installed on Ubuntu with:
- ```
- apt install opal-prd
- ```
- and on RedHat with:
- ```
- yum install opal-prd
- ```
+opal-prd may be installed on Ubuntu with: ` apt install opal-prd ` and on RedHat
+with: ` yum install opal-prd `
-
-## Obtain a copy of GitHub issues in CSV format: ##
+## Obtain a copy of GitHub issues in CSV format:
Note: You will be prompted to enter your GitHub password.
Usage:
+
```
$ cd tools/
$ python github_issues_to_csv <github user> <github repo>
```
+
Example for getting openbmc issues:
+
```
$ python github_issues_to_csv <github user> openbmc/openbmc
```
+
Example for getting openbmc-test-automation issues:
+
```
$ python github_issues_to_csv <github user> openbmc/openbmc-test-automation
```
-
-## Generate Documentation for Robot Test Cases: ##
+## Generate Documentation for Robot Test Cases:
Usage:
+
```
$ ./tools/generate_test_document <Robot test directory path> <test case document file path>
```
Example for generating tests cases documentation for tests directory:
+
```
$ ./tools/generate_test_document tests testsdirectoryTCdocs.html
```
-Example for generating tests cases documentation:
-Note: Invoke the tool without arguments:
+Example for generating tests cases documentation: Note: Invoke the tool without
+arguments:
+
```
$ ./tools/generate_test_document
```
+## Non-Volatile Memory Express Command Line Interface (nvme-cli):
-## Non-Volatile Memory Express Command Line Interface (nvme-cli): ##
-
-nvme-cli is a linux command line tool for accessing Non-Volatile Storage (NVM) media attached via PCIe bus.
+nvme-cli is a linux command line tool for accessing Non-Volatile Storage (NVM)
+media attached via PCIe bus.
Source: https://github.com/linux-nvme/nvme-cli
To install nvme-cli on RedHat:
+
```
yum install name-cli
```
+
To install nvme-cli on Ubuntu:
+
```
sudo apt-get install nvme-cli
```
-* Obtaining the PPA for Ubuntu
- - Add the sbates PPA to your sources: https://launchpad.net/~sbates/+archive/ubuntu/ppa
+- Obtaining the PPA for Ubuntu
+ - Add the sbates PPA to your sources:
+ https://launchpad.net/~sbates/+archive/ubuntu/ppa
+## The Hdparm tool:
-## The Hdparm tool: ##
-
-hdparm is a command line utility for setting and viewing hardware parameters of hard disk drives.
+hdparm is a command line utility for setting and viewing hardware parameters of
+hard disk drives.
To install hdparm on RedHat:
+
```
yum install hdparm
```
+
To install hdparm on Ubuntu:
+
```
sudo apt-get update
sudo apt-get install hdparm
```
## OpenSSL tool:
-OpenSSL is an open-source command line tool that is commonly used to generate certificates and private keys, create CSRs and identify certificate information.
+
+OpenSSL is an open-source command line tool that is commonly used to generate
+certificates and private keys, create CSRs and identify certificate information.
To generate a self-signed certificate with a private key:
@@ -158,19 +174,26 @@
```
_Example:_
+
```
openssl req -x509 -sha256 -newkey rsa:2048 -nodes -days 365 -keyout certificate.pem -out certificate.pem -subj "/O=XYZ Corporation /CN=www.xyz.com"
```
To view installed certificates on a OpenBMC system:
+
```
openssl s_client -connect <BMC_IP>:443 -showcerts
```
-Refer to the [OpenSSL manual](https://www.openssl.org/docs/manmaster/man1/req.html) for more details.
+Refer to the
+[OpenSSL manual](https://www.openssl.org/docs/manmaster/man1/req.html) for more
+details.
-## peltool: ##
-peltool is an open-source platform event log(PEL) tool generally used to view and delete pel logs that are generated on the BMC system. Also, provides various pel related operations as mentioned in the 'peltool --help'.
+## peltool:
+
+peltool is an open-source platform event log(PEL) tool generally used to view
+and delete pel logs that are generated on the BMC system. Also, provides various
+pel related operations as mentioned in the 'peltool --help'.
```
peltool -h
@@ -196,10 +219,14 @@
--archive List or display archived PELs
```
-## guard tool: ##
-guard tool on BMC provides an option to create, view and delete the faulty units.
-Refer to [README](https://github.com/open-power/guard#readme)
+## guard tool:
-## pldmtool: ##
-pldmtool is an open-source client tool that acts as a PLDM requester which runs on the BMC. pldmtool supports the subcommands for PLDM types such as base, platform, bios, fru, and oem-ibm as mentioned in the 'pldmtool --help'.
-Refer to [README](https://github.com/openbmc/pldm/tree/master/pldmtool#README.md)
+guard tool on BMC provides an option to create, view and delete the faulty
+units. Refer to [README](https://github.com/open-power/guard#readme)
+
+## pldmtool:
+
+pldmtool is an open-source client tool that acts as a PLDM requester which runs
+on the BMC. pldmtool supports the subcommands for PLDM types such as base,
+platform, bios, fru, and oem-ibm as mentioned in the 'pldmtool --help'. Refer to
+[README](https://github.com/openbmc/pldm/tree/master/pldmtool#README.md)
diff --git a/docs/redfish_coding_guidelines.md b/docs/redfish_coding_guidelines.md
index 6646052..17989b3 100644
--- a/docs/redfish_coding_guidelines.md
+++ b/docs/redfish_coding_guidelines.md
@@ -1,131 +1,131 @@
-Redfish Coding Guidelines
-=========================
+# Redfish Coding Guidelines
-- For robot programs wishing to run Redfish commands, include the following in
- your robot file:
+- For robot programs wishing to run Redfish commands, include the following in
+ your robot file:
- ```
- *** Settings ***
+ ```
+ *** Settings ***
- Resource bmc_redfish_resource.robot
- ```
-- This git repository has some redfish wrapper modules:
+ Resource bmc_redfish_resource.robot
+ ```
- - [redfish_plus.py](../lib/redfish_plus.py)
- - [bmc_redfish.py](../lib/bmc_redfish.py)
- - [bmc_redfish_utils.py](../lib/bmc_redfish_utils.py)
- - Redfish wrapper module features:
+- This git repository has some redfish wrapper modules:
- For all Redfish REST requests (get, head, post, put, patch, delete):
+ - [redfish_plus.py](../lib/redfish_plus.py)
+ - [bmc_redfish.py](../lib/bmc_redfish.py)
+ - [bmc_redfish_utils.py](../lib/bmc_redfish_utils.py)
+ - Redfish wrapper module features:
- - Support for python-like strings for all arguments which allows
- callers to easily specify complex arguments such as lists or
- dictionaries.
+ For all Redfish REST requests (get, head, post, put, patch, delete):
- So instead of coding this:
+ - Support for python-like strings for all arguments which allows callers to
+ easily specify complex arguments such as lists or dictionaries.
- ```
- ${ldap_type_dict}= Create Dictionary ServiceEnabled=${False}
- ${body}= Create Dictionary ${LDAP_TYPE}=${ldap_type_dict}
- Redfish.Patch ${REDFISH_BASE_URI}AccountService body=${body}
- ```
+ So instead of coding this:
- You can do it in one fell swoop like this:
+ ```
+ ${ldap_type_dict}= Create Dictionary ServiceEnabled=${False}
+ ${body}= Create Dictionary ${LDAP_TYPE}=${ldap_type_dict}
+ Redfish.Patch ${REDFISH_BASE_URI}AccountService body=${body}
+ ```
- ```
- Redfish.Patch ${REDFISH_BASE_URI}AccountService body={'${LDAP_TYPE}': {'ServiceEnabled': ${False}}}
- ```
- - Support for **valid_status_codes** argument and auto-failure:
+ You can do it in one fell swoop like this:
- As mentioned above, this argument may be either an actual
- robot/python list or it may be a string value which python can
- translate into a list.
+ ```
+ Redfish.Patch ${REDFISH_BASE_URI}AccountService body={'${LDAP_TYPE}': {'ServiceEnabled': ${False}}}
+ ```
- The default value is [${HTTP_OK}].
+ - Support for **valid_status_codes** argument and auto-failure:
- This means that the Redfish REST request will fail
- **automatically** if the resulting status code is not found in the
- valid_status_codes list.
+ As mentioned above, this argument may be either an actual robot/python
+ list or it may be a string value which python can translate into a list.
- So instead of having to do this:
+ The default value is [${HTTP_OK}].
- ```
- ${resp}= Redfish.Get ${EVENT_LOG_URI}Entries
- Should Be Equal As Strings ${resp.status_code} ${HTTP_OK}
- ```
+ This means that the Redfish REST request will fail **automatically** if
+ the resulting status code is not found in the valid_status_codes list.
- You can simply do this:
+ So instead of having to do this:
- ```
- ${resp}= Redfish.Get ${EVENT_LOG_URI}Entries
- ```
+ ```
+ ${resp}= Redfish.Get ${EVENT_LOG_URI}Entries
+ Should Be Equal As Strings ${resp.status_code} ${HTTP_OK}
+ ```
- If, for some reason, you **expect** your command to fail, you can
- specify the expected status code or codes:
+ You can simply do this:
- ```
- Redfish.Patch ${REDFISH_BASE_URI}UpdateService body={'ApplyTime' : 'Invalid'} valid_status_codes=[${HTTP_BAD_REQUEST}]
- ```
- - Login defaults for path, username and password are
- https://${OPENBMC_HOST}, ${OPENBMC_USERNAME}, ${OPENBMC_PASSWORD}.
- - Many utility functions are available. Examples:;
+ ```
+ ${resp}= Redfish.Get ${EVENT_LOG_URI}Entries
+ ```
- - get_properties
- - get_attributes
- - get_session_info
- - list_request
- - enumerate_request
+ If, for some reason, you **expect** your command to fail, you can specify
+ the expected status code or codes:
-Rules for use of Redfish.Login and Redfish.Logout
-=================================================
+ ```
+ Redfish.Patch ${REDFISH_BASE_URI}UpdateService body={'ApplyTime' : 'Invalid'} valid_status_codes=[${HTTP_BAD_REQUEST}]
+ ```
+
+ - Login defaults for path, username and password are https://${OPENBMC_HOST},
+ ${OPENBMC_USERNAME}, ${OPENBMC_PASSWORD}.
+ - Many utility functions are available. Examples:;
+
+ - get_properties
+ - get_attributes
+ - get_session_info
+ - list_request
+ - enumerate_request
+
+# Rules for use of Redfish.Login and Redfish.Logout
It is desirable to avoid excessive redfish logins/logouts for the following
reasons:
-- It simplifies the code base.
-- It allows calling keywords and testcases to keep control over login
- parameters like USERNAME, PASSWORD, etc. Consider the following example:
- ```
- # Login to redfish with non-standard username/password.
- Redfish.Login ${LDAP_USER} ${LDAP_USER_PASSWORD}
- # Run 'Some Keyword' while logged in as ${LDAP_USER}/${LDAP_USER_PASSWORD}.
- Some Keyword
- ```
- If 'Some Keyword' in the example above does its own Redfish.Login, it will
- thwart the stated purpose of the caller.
+- It simplifies the code base.
+- It allows calling keywords and testcases to keep control over login parameters
+ like USERNAME, PASSWORD, etc. Consider the following example:
+
+ ```
+ # Login to redfish with non-standard username/password.
+ Redfish.Login ${LDAP_USER} ${LDAP_USER_PASSWORD}
+ # Run 'Some Keyword' while logged in as ${LDAP_USER}/${LDAP_USER_PASSWORD}.
+ Some Keyword
+ ```
+
+ If 'Some Keyword' in the example above does its own Redfish.Login, it will
+ thwart the stated purpose of the caller.
**Rules:**
-- Login should be done once in Suite Setup:
+- Login should be done once in Suite Setup:
- ```
- *** Keywords ***
- Suite Setup Execution
- Redfish.Login
- ```
-- Logout should be done once in Suite Teardown:
- ```
- *** Keywords ***
- Suite Teardown Execution
- Redfish.Logout
- ```
-- As a result of the first two rules, all keywords and testcases that call
- upon redfish functions (e.g. Redfish.Get, Redfish.Patch, etc.) have a right
- to expect that login/logout have already been handled. Therefore, such
- keywords and testcases should NOT do logins and logouts themselves.
-- There may be exceptions to the above but they require justification (e.g. a
- test whose purpose is to verify that it can login with an **alternate**
- username, etc.).
-- Any keyword or test case which breaks the above rules is responsible for
- setting things right (i.e. back to a logged in state).
+ ```
+ *** Keywords ***
+ Suite Setup Execution
+ Redfish.Login
+ ```
-Rules for use of data/variables.py
-==================================
+- Logout should be done once in Suite Teardown:
+ ```
+ *** Keywords ***
+ Suite Teardown Execution
+ Redfish.Logout
+ ```
+- As a result of the first two rules, all keywords and testcases that call upon
+ redfish functions (e.g. Redfish.Get, Redfish.Patch, etc.) have a right to
+ expect that login/logout have already been handled. Therefore, such keywords
+ and testcases should NOT do logins and logouts themselves.
+- There may be exceptions to the above but they require justification (e.g. a
+ test whose purpose is to verify that it can login with an **alternate**
+ username, etc.).
+- Any keyword or test case which breaks the above rules is responsible for
+ setting things right (i.e. back to a logged in state).
+
+# Rules for use of data/variables.py
Avoid defining variables in data/variables.py for Redfish URIs.
-There's no obvious benefit to using such variables. Conversely, with literal values,
-it is much easier for the programmer to interpret the code.
+There's no obvious benefit to using such variables. Conversely, with literal
+values, it is much easier for the programmer to interpret the code.
Consider the following example.
diff --git a/docs/redfish_request_via_mTLS.md b/docs/redfish_request_via_mTLS.md
index daeb7f8..39b9459 100644
--- a/docs/redfish_request_via_mTLS.md
+++ b/docs/redfish_request_via_mTLS.md
@@ -1,81 +1,78 @@
-Redfish Request Via mTLS
-=========================
+# Redfish Request Via mTLS
When the BMC only enables mTLS type for authentication. Redfish request in robot
test should be tested normally.
## Required environment variables in Robot
- - **MTLS_ENABLED** indicates whether mTLS is enabled in BMC.
- False by default:
+- **MTLS_ENABLED** indicates whether mTLS is enabled in BMC. False by default:
- ```
- ${MTLS_ENABLED} False
- ```
+ ```
+ ${MTLS_ENABLED} False
+ ```
- - **VALID_CERT** indicates valid mTLS certificate for authentication.
- When a redfish request doesn't specify a certificate, no certificate by
- default.
+- **VALID_CERT** indicates valid mTLS certificate for authentication. When a
+ redfish request doesn't specify a certificate, no certificate by default.
- ```
- ${VALID_CERT} ${EMPTY}
- ```
+ ```
+ ${VALID_CERT} ${EMPTY}
+ ```
- - **CERT_DIR_PATH** indicates path of mTLS certificates directory:
+- **CERT_DIR_PATH** indicates path of mTLS certificates directory:
- ```
- ${CERT_DIR_PATH} ${EMPTY}
- ```
+ ```
+ ${CERT_DIR_PATH} ${EMPTY}
+ ```
+
## How to send a redfish request with certificate
- When a redfish request is executed, it will be executed through the python
- library **requests** with certificate. It supports for all Redfish REST
- requests (get, head, post, put, patch, delete):
+ library **requests** with certificate. It supports for all Redfish REST
+ requests (get, head, post, put, patch, delete):
- ```
- import requests
+ ```
+ import requests
- cert_dict = kwargs.pop('certificate', {"certificate_name":VALID_CERT})
- response = requests.get(
- url='https://'+ host + args[0],
- cert=CERT_DIR_PATH + '/' + cert_dict['certificate_name'],
- verify=False,
- headers={"Cache-Control": "no-cache"})
- ```
+ cert_dict = kwargs.pop('certificate', {"certificate_name":VALID_CERT})
+ response = requests.get(
+ url='https://'+ host + args[0],
+ cert=CERT_DIR_PATH + '/' + cert_dict['certificate_name'],
+ verify=False,
+ headers={"Cache-Control": "no-cache"})
+ ```
- Original robot code of redfish request doesn’t need to modify. It will send
- the request with the default certificate ${VALID_CERT}.
+ the request with the default certificate ${VALID_CERT}.
- The example provides Redfish request to use other certificate in the Robot
code below:
- ```
- ${certificate_dict}= Create Dictionary certificate_name=${CERT}
- Redfish.Get ${VALID_URL} certificate=&{certificate_dict}
- ... valid_status_codes=[${HTTP_OK}]
- ```
+ ```
+ ${certificate_dict}= Create Dictionary certificate_name=${CERT}
+ Redfish.Get ${VALID_URL} certificate=&{certificate_dict}
+ ... valid_status_codes=[${HTTP_OK}]
+ ```
## Test Cases for mTLS authentication
mTLS authentication is only a means to connect to the BMC, not for testing
purposes. Therefore, some test cases need to write a new one to match it for
mTLS authentication. (Requires test certificate with different privileges or
-username) Some cases don’t need to be tested because the purpose of
-them are inapplicable to mTLS. Case studies are as follows:
+username) Some cases don’t need to be tested because the purpose of them are
+inapplicable to mTLS. Case studies are as follows:
- **Create_IPMI_User_And_Verify_Login_Via_Redfish**
- In this case, it uses IPMI to create a random user with password and
- privilege, and then verifies the login via Redfish. Therefore, it will
- logout the default user and then login with the user just created by IPMI.
- So it does not need to use mTLS to authenticate login and logout.
- It can be replaced as follows: Prepare a certificate with the user name
- "admin_user" in advance. Use IPMI to create a user named admin_user. Then
- you can use the Redfish request with the admin_user certificate to provide
- the server for verification.
+ In this case, it uses IPMI to create a random user with password and
+ privilege, and then verifies the login via Redfish. Therefore, it will logout
+ the default user and then login with the user just created by IPMI. So it does
+ not need to use mTLS to authenticate login and logout. It can be replaced as
+ follows: Prepare a certificate with the user name "admin_user" in advance. Use
+ IPMI to create a user named admin_user. Then you can use the Redfish request
+ with the admin_user certificate to provide the server for verification.
- **Attempt_Login_With_Expired_Session**
- Most cases related to sessions don't require mTLS because Redfish requests
- don't need to create a session first. Therefore, there is no need to test
- these cases when mTLS is enabled.
+ Most cases related to sessions don't require mTLS because Redfish requests
+ don't need to create a session first. Therefore, there is no need to test
+ these cases when mTLS is enabled.
diff --git a/ffdc/docs/plugin.md b/ffdc/docs/plugin.md
index 13fc72a..35f283b 100644
--- a/ffdc/docs/plugin.md
+++ b/ffdc/docs/plugin.md
@@ -1,13 +1,17 @@
### Plugin
-Plugin feature for the log collector is to load a user python functions at runtime by the engine and execute it.
+Plugin feature for the log collector is to load a user python functions at
+runtime by the engine and execute it.
-The design infrastructure allows user to extend or call their existing python scripts without needing to expose
-the implementation. This enriches the log collection and mechanize the work flow as per user driven as per
-their requirement,
+The design infrastructure allows user to extend or call their existing python
+scripts without needing to expose the implementation. This enriches the log
+collection and mechanize the work flow as per user driven as per their
+requirement,
### Understanding Plugin
-The plugin works like any stand-alone piece of python script or library function.
+
+The plugin works like any stand-alone piece of python script or library
+function.
The main components in plugin infrastructure are:
@@ -16,10 +20,13 @@
- plugin parser in the collector engine
### Plugin Directory
-Python module script are added or copied to `plugins` directory and the log engine loads these plugins during
-runtime and on demand from the YAML else they are not invoked automatically.
+
+Python module script are added or copied to `plugins` directory and the log
+engine loads these plugins during runtime and on demand from the YAML else they
+are not invoked automatically.
Example:
+
```
plugins/
├── foo_func.py
@@ -31,6 +38,7 @@
### Plugin Template Example
Stand-alone functions: plugins/foo_func.py
+
```
# Sample for documentation plugin
@@ -44,6 +52,7 @@
Class function(s): plugins/plugin_class.py
Example:
+
```
class plugin_class:
@@ -56,6 +65,7 @@
Static Class function(s): plugins/plugin_class.py
Example:
+
```
class plugin_class:
@@ -64,13 +74,14 @@
print(msg)
```
-This is to avoid passing object self in plugin args YAML when calling the class function(s).
-However python class static method has its own limitation, do not use unless needed.
-
+This is to avoid passing object self in plugin args YAML when calling the class
+function(s). However python class static method has its own limitation, do not
+use unless needed.
You can add your own plugin modules to extend further.
Test your plugin:
+
```
python3 plugins/foo_func.py
```
@@ -78,6 +89,7 @@
### YAML Syntax
Plugin function without return statement.
+
```
- plugin:
- plugin_name: plugin.foo_func.print_vars
@@ -86,17 +98,19 @@
```
Plugin function with return statement.
+
```
- plugin:
- plugin_name: return_value = plugin.foo_func.return_vars
- plugin_args:
```
-when the return directive is used by implying "=" , the `return_value`
-can be accessed within the same block by another following plugins
-by using the variable name directly.
+when the return directive is used by implying "=" , the `return_value` can be
+accessed within the same block by another following plugins by using the
+variable name directly.
Example:
+
```
- plugin:
- plugin_name: plugin.foo_func.print_vars
@@ -104,20 +118,23 @@
- return_value
```
-To accept multiple return values by using coma "," separated statement
+To accept multiple return values by using coma "," separated statement
+
```
- plugin_name: return_value1,return_value2 = plugin.foo_func.print_vars
```
Accessing a class method:
-The rule remains same as other functions, however for a class object plugin syntax
+The rule remains same as other functions, however for a class object plugin
+syntax
```
- plugin_name: plugin.<file_name>.<class_object>.<class_method>
```
Example: (from the class example previously mentioned)
+
```
- plugin:
- plugin_name: plugin.plugin_class.plugin_class.plugin_print_msg
@@ -128,7 +145,6 @@
### Plugin execution output for sample
-
```
[PLUGIN-START]
Call func: plugin.foo_func.print_vars("Hello plugin")
@@ -156,6 +172,7 @@
```
Else, plugin response will be skipped and not written to any file.
+
```
FILES:
- None
@@ -164,12 +181,14 @@
### Plugin ERROR Direcive
Error directive on plugin supported
-- exit_on_error : If there was an error in a plugin stacked, the subsequent
- plugin would not be executed if this is declared.
-- continue_on_error : If there was an error and user declare this directive,
- then the plugin block will continue to execute.
+
+- exit_on_error : If there was an error in a plugin stacked, the subsequent
+ plugin would not be executed if this is declared.
+- continue_on_error : If there was an error and user declare this directive,
+ then the plugin block will continue to execute.
Example:
+
```
- plugin:
- plugin_name: plugin.foo_func.print_vars
@@ -178,19 +197,21 @@
- plugin_error: exit_on_error
```
-This error directive would come into force only if there is an error detected
-by the plugin during execution and not the error response returned from the plugin
+This error directive would come into force only if there is an error detected by
+the plugin during execution and not the error response returned from the plugin
function in general.
-To go further, there is another directive for plugin to check if the plugin function
-returned a valid data or not.
+To go further, there is another directive for plugin to check if the plugin
+function returned a valid data or not.
The directive statement is
+
```
- plugin_expects_return: <data type>
```
Example:
+
```
- plugin:
- plugin:
@@ -204,10 +225,11 @@
- plugin_expects_return: str
```
-The above example states that, the plugin function is expecting a return data of type
-string. If the plugin function does not return data or the returned data is not of type
-string, then it would throw an error and sets the plugin_error flag exit_on_error as True.
+The above example states that, the plugin function is expecting a return data of
+type string. If the plugin function does not return data or the returned data is
+not of type string, then it would throw an error and sets the plugin_error flag
+exit_on_error as True.
-This directive helps in validating plugin return data to handle different plugin blocks
-stacked together which are depending on the success of the previous plugin execution to do
-further processing correctly.
+This directive helps in validating plugin return data to handle different plugin
+blocks stacked together which are depending on the success of the previous
+plugin execution to do further processing correctly.
diff --git a/ffdc/docs/yaml_syntax_rules.md b/ffdc/docs/yaml_syntax_rules.md
index 349f5a2..546da52 100644
--- a/ffdc/docs/yaml_syntax_rules.md
+++ b/ffdc/docs/yaml_syntax_rules.md
@@ -1,13 +1,14 @@
### YAML Configuration
-YAML is a human friendly data serialization standard for all programming languages.
+YAML is a human friendly data serialization standard for all programming
+languages.
Refer: https://yaml.org/
YAML is the main orchestrator in terms of how the user arranges the data to be
collected in this log collection tool. The better context and syntax usage would
-improve the execution, parsing and data collection feeds to the collector engine.
-
+improve the execution, parsing and data collection feeds to the collector
+engine.
### YAML Rules
@@ -30,8 +31,8 @@
COMMANDS, FILES, PROTOCOL is mandatory for all YAML block.
-Note: The FILES directive is not needed for protocol using SCP (Refer YAML Block Example)
-
+Note: The FILES directive is not needed for protocol using SCP (Refer YAML Block
+Example)
### YAML Block Examples
diff --git a/ffdc/ffdc_config.yaml b/ffdc/ffdc_config.yaml
index 8897a3b..0ca91af 100644
--- a/ffdc/ffdc_config.yaml
+++ b/ffdc/ffdc_config.yaml
@@ -17,320 +17,360 @@
# Filename is <OS>_general.txt, where <OS> is in [OPENBMC, RHEL, UBUNTU]
GENERAL:
COMMANDS:
- - 'rm -rf /tmp/*BMC_* /tmp/PEL_* /tmp/pldm* /tmp/PLDM* /tmp/GUARD* /tmp/fan_* /tmp/DEVTREE /tmp/bmcweb_*'
- - 'echo "++++++++++ cat /etc/os-release ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'cat /etc/os-release >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ cat /etc/timestamp ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'cat /etc/timestamp >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ uname -a ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'uname -a >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ cat /etc/timestamp ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'cat /etc/timestamp >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ uptime;cat /proc/uptime ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'uptime >> /tmp/OPENBMC_general.txt'
- - 'cat /proc/uptime >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ df -hT ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'df -hT >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ date;/sbin/hwclock --show ++++++++++" >> /tmp/OPENBMC_general.txt'
- - 'date >> /tmp/OPENBMC_general.txt'
- - '/sbin/hwclock --show >> /tmp/OPENBMC_general.txt'
- - '/usr/bin/timedatectl >> /tmp/OPENBMC_general.txt'
- - 'echo -e "\n++++++++++ /usr/bin/obmcutil state ++++++++++" >> /tmp/OPENBMC_general.txt'
- - '/usr/bin/obmcutil state >> /tmp/OPENBMC_general.txt'
+ - "rm -rf /tmp/*BMC_* /tmp/PEL_* /tmp/pldm* /tmp/PLDM* /tmp/GUARD*
+ /tmp/fan_* /tmp/DEVTREE /tmp/bmcweb_*"
+ - 'echo "++++++++++ cat /etc/os-release ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "cat /etc/os-release >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ cat /etc/timestamp ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "cat /etc/timestamp >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ uname -a ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "uname -a >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ cat /etc/timestamp ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "cat /etc/timestamp >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ uptime;cat /proc/uptime ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "uptime >> /tmp/OPENBMC_general.txt"
+ - "cat /proc/uptime >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ df -hT ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "df -hT >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ date;/sbin/hwclock --show ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "date >> /tmp/OPENBMC_general.txt"
+ - "/sbin/hwclock --show >> /tmp/OPENBMC_general.txt"
+ - "/usr/bin/timedatectl >> /tmp/OPENBMC_general.txt"
+ - 'echo -e "\n++++++++++ /usr/bin/obmcutil state ++++++++++" >>
+ /tmp/OPENBMC_general.txt'
+ - "/usr/bin/obmcutil state >> /tmp/OPENBMC_general.txt"
FILES:
- - '/tmp/OPENBMC_general.txt'
+ - "/tmp/OPENBMC_general.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
OPENBMC_LOGS:
COMMANDS:
- - 'cat /sys/class/watchdog/watchdog1/bootstatus >/tmp/BMC_flash_side.txt'
- - 'grep -r . /sys/class/hwmon/* >/tmp/BMC_hwmon.txt'
- - 'top -n 1 -b >/tmp/BMC_proc_list.txt'
- - 'ls -Al /proc/*/fd/ >/tmp/BMC_proc_fd_active_list.txt'
- - 'journalctl --no-pager >/tmp/BMC_journalctl_nopager.txt'
- - 'journalctl -o json-pretty >/tmp/BMC_journalctl_pretty.json'
- - 'dmesg >/tmp/BMC_dmesg.txt'
- - 'cat /proc/cpuinfo >/tmp/BMC_procinfo.txt'
- - 'cat /proc/meminfo >/tmp/BMC_meminfo.txt'
- - 'systemctl status --all >/tmp/BMC_systemd.txt'
- - 'systemctl list-units --failed >/tmp/BMC_failed_service.txt'
- - 'systemctl list-jobs >/tmp/BMC_list_service.txt'
- - 'cat /var/log/obmc-console.log >/tmp/BMC_obmc_console.txt'
- - 'cat /var/log/obmc-console1.log >/tmp/BMC_obmc_console1.txt'
- - 'peltool -l >/tmp/PEL_logs_list.json'
- - {'peltool -a >/tmp/PEL_logs_display.json':600}
- - {'peltool -l -a -f >/tmp/PEL_logs_complete_list.json 2>&1':1200}
- - {'peltool -a -f -h>/tmp/PEL_logs_complete_display.json 2>&1':1200}
- - {'strace -p $(pidof pldmd) -o /tmp/pldmd_strace.txt & sleep 60 ; kill $!':70}
- - 'hexdump -C /var/lib/phosphor-logging/extensions/pels/badPEL >/tmp/PEL_logs_badPEL.txt'
- - 'guard -l >/tmp/GUARD_list.txt'
- - 'pldmtool fru getfrurecordtable>/tmp/PLDM_fru_record.txt'
- - 'killall -s SIGUSR1 pldmd; sleep 5'
- - 'fanctl dump'
- - 'cat /var/lib/phosphor-software-manager/pnor/rw/DEVTREE > /tmp/DEVTREE'
- - 'cat /home/root/bmcweb_persistent_data.json > /tmp/bmcweb_persistent_data.json'
+ - "cat /sys/class/watchdog/watchdog1/bootstatus
+ >/tmp/BMC_flash_side.txt"
+ - "grep -r . /sys/class/hwmon/* >/tmp/BMC_hwmon.txt"
+ - "top -n 1 -b >/tmp/BMC_proc_list.txt"
+ - "ls -Al /proc/*/fd/ >/tmp/BMC_proc_fd_active_list.txt"
+ - "journalctl --no-pager >/tmp/BMC_journalctl_nopager.txt"
+ - "journalctl -o json-pretty >/tmp/BMC_journalctl_pretty.json"
+ - "dmesg >/tmp/BMC_dmesg.txt"
+ - "cat /proc/cpuinfo >/tmp/BMC_procinfo.txt"
+ - "cat /proc/meminfo >/tmp/BMC_meminfo.txt"
+ - "systemctl status --all >/tmp/BMC_systemd.txt"
+ - "systemctl list-units --failed >/tmp/BMC_failed_service.txt"
+ - "systemctl list-jobs >/tmp/BMC_list_service.txt"
+ - "cat /var/log/obmc-console.log >/tmp/BMC_obmc_console.txt"
+ - "cat /var/log/obmc-console1.log >/tmp/BMC_obmc_console1.txt"
+ - "peltool -l >/tmp/PEL_logs_list.json"
+ - { "peltool -a >/tmp/PEL_logs_display.json": 600 }
+ - {
+ "peltool -l -a -f >/tmp/PEL_logs_complete_list.json 2>&1": 1200,
+ }
+ - {
+ "peltool -a -f -h>/tmp/PEL_logs_complete_display.json 2>&1": 1200,
+ }
+ - {
+ "strace -p $(pidof pldmd) -o /tmp/pldmd_strace.txt & sleep 60
+ ; kill $!": 70,
+ }
+ - "hexdump -C /var/lib/phosphor-logging/extensions/pels/badPEL
+ >/tmp/PEL_logs_badPEL.txt"
+ - "guard -l >/tmp/GUARD_list.txt"
+ - "pldmtool fru getfrurecordtable>/tmp/PLDM_fru_record.txt"
+ - "killall -s SIGUSR1 pldmd; sleep 5"
+ - "fanctl dump"
+ - "cat /var/lib/phosphor-software-manager/pnor/rw/DEVTREE >
+ /tmp/DEVTREE"
+ - "cat /home/root/bmcweb_persistent_data.json >
+ /tmp/bmcweb_persistent_data.json"
FILES:
- - '/tmp/BMC_flash_side.txt'
- - '/tmp/BMC_hwmon.txt'
- - '/tmp/BMC_proc_list.txt'
- - '/tmp/BMC_proc_fd_active_list.txt'
- - '/tmp/BMC_journalctl_nopager.txt'
- - '/tmp/BMC_journalctl_pretty.json'
- - '/tmp/BMC_dmesg.txt'
- - '/tmp/BMC_procinfo.txt'
- - '/tmp/BMC_meminfo.txt'
- - '/tmp/BMC_systemd.txt'
- - '/tmp/BMC_failed_service.txt'
- - '/tmp/BMC_list_service.txt'
- - '/tmp/BMC_obmc_console.txt'
- - '/tmp/BMC_obmc_console1.txt'
- - '/tmp/PEL_logs_list.json'
- - '/tmp/PEL_logs_complete_list.json'
- - '/tmp/PEL_logs_complete_display.json'
- - '/tmp/PEL_logs_display.json'
- - '/tmp/pldmd_strace.txt'
- - '/tmp/PEL_logs_badPEL.txt'
- - '/tmp/GUARD_list.txt'
- - '/tmp/PLDM_fru_record.txt'
- - '/tmp/pldm_flight_recorder'
- - '/tmp/fan_control_dump.json'
- - '/tmp/DEVTREE'
- - '/tmp/bmcweb_persistent_data.json'
+ - "/tmp/BMC_flash_side.txt"
+ - "/tmp/BMC_hwmon.txt"
+ - "/tmp/BMC_proc_list.txt"
+ - "/tmp/BMC_proc_fd_active_list.txt"
+ - "/tmp/BMC_journalctl_nopager.txt"
+ - "/tmp/BMC_journalctl_pretty.json"
+ - "/tmp/BMC_dmesg.txt"
+ - "/tmp/BMC_procinfo.txt"
+ - "/tmp/BMC_meminfo.txt"
+ - "/tmp/BMC_systemd.txt"
+ - "/tmp/BMC_failed_service.txt"
+ - "/tmp/BMC_list_service.txt"
+ - "/tmp/BMC_obmc_console.txt"
+ - "/tmp/BMC_obmc_console1.txt"
+ - "/tmp/PEL_logs_list.json"
+ - "/tmp/PEL_logs_complete_list.json"
+ - "/tmp/PEL_logs_complete_display.json"
+ - "/tmp/PEL_logs_display.json"
+ - "/tmp/pldmd_strace.txt"
+ - "/tmp/PEL_logs_badPEL.txt"
+ - "/tmp/GUARD_list.txt"
+ - "/tmp/PLDM_fru_record.txt"
+ - "/tmp/pldm_flight_recorder"
+ - "/tmp/fan_control_dump.json"
+ - "/tmp/DEVTREE"
+ - "/tmp/bmcweb_persistent_data.json"
PROTOCOL:
- - 'SSH'
+ - "SSH"
# DUMP_LOGS: This section provides option to 'SCP if file exist'.
# COMMANDS: filename is preceded by ls -AX '.
# FILES: is not needed and is ignored if exists.
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /var/lib/systemd/coredump/core.*'
- - 'ls -AX /var/lib/phosphor-debug-collector/dumps/*/*'
- - 'ls -AX /var/lib/phosphor-debug-collector/hostbootdump/*/*'
+ - "ls -AX /var/lib/systemd/coredump/core.*"
+ - "ls -AX /var/lib/phosphor-debug-collector/dumps/*/*"
+ - "ls -AX /var/lib/phosphor-debug-collector/hostbootdump/*/*"
PROTOCOL:
- - 'SCP'
+ - "SCP"
# URLs and Files for OPENBMC redfish
# URLs and Files are one-to-one corresponding.
# File contains the data returned from 'redfishtool GET URL'
REDFISH_LOGS:
COMMANDS:
- - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always raw GET /redfish/v1/AccountService/Accounts
- - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always raw GET /redfish/v1/Managers/bmc/LogServices/Dump/Entries
- - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always raw GET /redfish/v1/Systems/system/LogServices/Dump/Entries
- - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always raw GET /redfish/v1/Systems/system/LogServices/EventLog/Entries
+ - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always
+ raw GET /redfish/v1/AccountService/Accounts
+ - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always
+ raw GET /redfish/v1/Managers/bmc/LogServices/Dump/Entries
+ - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always
+ raw GET /redfish/v1/Systems/system/LogServices/Dump/Entries
+ - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always
+ raw GET /redfish/v1/Systems/system/LogServices/EventLog/Entries
- plugin:
- - plugin_name: plugin.redfish.enumerate_request
- - plugin_args:
- - ${hostname}
- - ${username}
- - ${password}
- - /redfish/v1/
- - json
+ - plugin_name: plugin.redfish.enumerate_request
+ - plugin_args:
+ - ${hostname}
+ - ${username}
+ - ${password}
+ - /redfish/v1/
+ - json
FILES:
- - 'REDFISH_bmc_user_accounts.json'
- - 'REDFISH_bmc_dump_entries.json'
- - 'REDFISH_system_dumps_entries.json'
- - 'REDFISH_event_log_entries.json'
- - 'REDFISH_enumerate_v1.json'
+ - "REDFISH_bmc_user_accounts.json"
+ - "REDFISH_bmc_dump_entries.json"
+ - "REDFISH_system_dumps_entries.json"
+ - "REDFISH_event_log_entries.json"
+ - "REDFISH_enumerate_v1.json"
PROTOCOL:
- - 'REDFISH'
+ - "REDFISH"
# Commands and Files to collect for via out of band IPMI.
IPMI_LOGS:
COMMANDS:
- - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H ${hostname} lan print
- - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H ${hostname} fru list
- - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H ${hostname} user list
+ - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H
+ ${hostname} lan print
+ - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H
+ ${hostname} fru list
+ - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H
+ ${hostname} user list
FILES:
- - 'IPMI_LAN_print.txt'
- - 'IPMI_FRU_list.txt'
- - 'IPMI_USER_list.txt'
+ - "IPMI_LAN_print.txt"
+ - "IPMI_FRU_list.txt"
+ - "IPMI_USER_list.txt"
PROTOCOL:
- - 'IPMI'
+ - "IPMI"
# Commands and Files to collect for all Linux distributions
LINUX:
LINUX_LOGS:
COMMANDS:
- - 'cat /sys/firmware/opal/msglog >/tmp/OS_msglog.txt'
- - 'ppc64_cpu --frequency >/tmp/OS_cpufrequency.txt'
- - 'dmesg >/tmp/OS_dmesg.txt'
- - 'cat /var/log/opal-prd* >/tmp/OS_opal_prd.txt'
- - 'cat /var/log/boot.log >/tmp/OS_boot.txt'
- - 'cat /proc/cpuinfo >/tmp/OS_procinfo.txt'
- - 'cat /proc/meminfo >/tmp/OS_meminfo.txt'
- - 'netstat -a >/tmp/OS_netstat.txt'
- - 'lspci >/tmp/OS_lspci.txt'
- - 'lscpu >/tmp/OS_lscpu.txt'
- - 'lscfg >/tmp/OS_lscfg.txt'
- - 'journalctl --no-pager -b > /tmp/OS_journalctl_nopager.txt '
+ - "cat /sys/firmware/opal/msglog >/tmp/OS_msglog.txt"
+ - "ppc64_cpu --frequency >/tmp/OS_cpufrequency.txt"
+ - "dmesg >/tmp/OS_dmesg.txt"
+ - "cat /var/log/opal-prd* >/tmp/OS_opal_prd.txt"
+ - "cat /var/log/boot.log >/tmp/OS_boot.txt"
+ - "cat /proc/cpuinfo >/tmp/OS_procinfo.txt"
+ - "cat /proc/meminfo >/tmp/OS_meminfo.txt"
+ - "netstat -a >/tmp/OS_netstat.txt"
+ - "lspci >/tmp/OS_lspci.txt"
+ - "lscpu >/tmp/OS_lscpu.txt"
+ - "lscfg >/tmp/OS_lscfg.txt"
+ - "journalctl --no-pager -b > /tmp/OS_journalctl_nopager.txt "
FILES:
- - '/tmp/OS_msglog.txt'
- - '/tmp/OS_cpufrequency.txt'
- - '/tmp/OS_dmesg.txt'
- - '/tmp/OS_opal_prd.txt'
- - '/tmp/OS_boot.txt'
- - '/tmp/OS_procinfo.txt'
- - '/tmp/OS_meminfo.txt'
- - '/tmp/OS_netstat.txt'
- - '/tmp/OS_lspci.txt'
- - '/tmp/OS_lscpu.txt'
- - '/tmp/OS_lscfg.txt'
- - '/tmp/OS_journalctl_nopager.txt'
+ - "/tmp/OS_msglog.txt"
+ - "/tmp/OS_cpufrequency.txt"
+ - "/tmp/OS_dmesg.txt"
+ - "/tmp/OS_opal_prd.txt"
+ - "/tmp/OS_boot.txt"
+ - "/tmp/OS_procinfo.txt"
+ - "/tmp/OS_meminfo.txt"
+ - "/tmp/OS_netstat.txt"
+ - "/tmp/OS_lspci.txt"
+ - "/tmp/OS_lscpu.txt"
+ - "/tmp/OS_lscfg.txt"
+ - "/tmp/OS_journalctl_nopager.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
# Commands and Files to collect for Ubuntu Linux only
UBUNTU:
GENERAL:
COMMANDS:
- - 'rm -rf /tmp/UBUNTU_general.txt'
- - 'echo "++++++++++ UBUNTU Rleasae ++++++++++" > /tmp/UBUNTU_general.txt'
- - 'cat /etc/os-release >> /tmp/UBUNTU_general.txt'
- - 'echo "\n++++++++++ Time stamp ++++++++++" >> /tmp/UBUNTU_general.txt'
- - 'date >> /tmp/UBUNTU_general.txt'
- - 'echo "\n++++++++++ uname -a ++++++++++" >> /tmp/UBUNTU_general.txt'
- - 'uname -a >> /tmp/UBUNTU_general.txt'
+ - "rm -rf /tmp/UBUNTU_general.txt"
+ - 'echo "++++++++++ UBUNTU Rleasae ++++++++++" >
+ /tmp/UBUNTU_general.txt'
+ - "cat /etc/os-release >> /tmp/UBUNTU_general.txt"
+ - 'echo "\n++++++++++ Time stamp ++++++++++" >>
+ /tmp/UBUNTU_general.txt'
+ - "date >> /tmp/UBUNTU_general.txt"
+ - 'echo "\n++++++++++ uname -a ++++++++++" >>
+ /tmp/UBUNTU_general.txt'
+ - "uname -a >> /tmp/UBUNTU_general.txt"
- 'echo "\n++++++++++ uptime ++++++++++" >> /tmp/UBUNTU_general.txt'
- - 'uptime >> /tmp/UBUNTU_general.txt'
+ - "uptime >> /tmp/UBUNTU_general.txt"
FILES:
- - '/tmp/UBUNTU_general.txt'
+ - "/tmp/UBUNTU_general.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
UBUNTU_LOGS:
COMMANDS:
- - '{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt'
- - 'tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt'
- - 'rm -rf /tmp/sosreport*FFDC*'
- - {'sosreport --batch --tmp-dir /tmp --label FFDC >/tmp/OS_sosreport.txt': 1200}
- - 'tar -zcvf /tmp/crash.tar.gz /var/crash'
+ - "{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt"
+ - "tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt"
+ - "rm -rf /tmp/sosreport*FFDC*"
+ - {
+ "sosreport --batch --tmp-dir /tmp --label FFDC
+ >/tmp/OS_sosreport.txt": 1200,
+ }
+ - "tar -zcvf /tmp/crash.tar.gz /var/crash"
FILES:
- - '/tmp/OS_info.txt'
- - '/tmp/OS_syslog.txt'
- - '/tmp/OS_sosreport.txt'
- - '/tmp/sosreport*.tar.xz'
- - '/tmp/crash.tar.gz'
+ - "/tmp/OS_info.txt"
+ - "/tmp/OS_syslog.txt"
+ - "/tmp/OS_sosreport.txt"
+ - "/tmp/sosreport*.tar.xz"
+ - "/tmp/crash.tar.gz"
PROTOCOL:
- - 'SSH'
+ - "SSH"
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /tmp/htx/htxerr'
- - 'ls -AX /tmp/htx/htxmsg'
+ - "ls -AX /tmp/htx/htxerr"
+ - "ls -AX /tmp/htx/htxmsg"
PROTOCOL:
- - 'SCP'
+ - "SCP"
# Commands and Files to collect for RHE Linux only
RHEL:
GENERAL:
COMMANDS:
- - 'rm -rf /tmp/RHEL_general.txt'
+ - "rm -rf /tmp/RHEL_general.txt"
- 'echo "++++++++++ RHEL Rleasae ++++++++++" > /tmp/RHEL_general.txt'
- - 'cat /etc/os-release >> /tmp/RHEL_general.txt'
- - 'echo -e "\n++++++++++ Time stamp ++++++++++" >> /tmp/RHEL_general.txt'
- - 'date >> /tmp/RHEL_general.txt'
- - 'echo -e "\n++++++++++ uname -a ++++++++++" >> /tmp/RHEL_general.txt'
- - 'uname -a >> /tmp/RHEL_general.txt'
+ - "cat /etc/os-release >> /tmp/RHEL_general.txt"
+ - 'echo -e "\n++++++++++ Time stamp ++++++++++" >>
+ /tmp/RHEL_general.txt'
+ - "date >> /tmp/RHEL_general.txt"
+ - 'echo -e "\n++++++++++ uname -a ++++++++++" >>
+ /tmp/RHEL_general.txt'
+ - "uname -a >> /tmp/RHEL_general.txt"
- 'echo -e "\n++++++++++ uptime ++++++++++" >> /tmp/RHEL_general.txt'
- - 'uptime >> /tmp/RHEL_general.txt'
+ - "uptime >> /tmp/RHEL_general.txt"
FILES:
- - '/tmp/RHEL_general.txt'
+ - "/tmp/RHEL_general.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
RHEL_LOGS:
COMMANDS:
- - '{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt'
- - 'tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt'
- - 'rm -rf /tmp/sosreport*FFDC*'
- - {'sosreport --batch --tmp-dir /tmp --label FFDC >/tmp/OS_sosreport.txt': 1200}
- - 'tar -zcvf /tmp/crash.tar.gz /var/crash'
+ - "{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt"
+ - "tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt"
+ - "rm -rf /tmp/sosreport*FFDC*"
+ - {
+ "sosreport --batch --tmp-dir /tmp --label FFDC
+ >/tmp/OS_sosreport.txt": 1200,
+ }
+ - "tar -zcvf /tmp/crash.tar.gz /var/crash"
FILES:
- - '/tmp/OS_info.txt'
- - '/tmp/OS_syslog.txt'
- - '/tmp/OS_sosreport.txt'
- - '/tmp/sosreport*.tar.xz'
- - '/tmp/crash.tar.gz'
+ - "/tmp/OS_info.txt"
+ - "/tmp/OS_syslog.txt"
+ - "/tmp/OS_sosreport.txt"
+ - "/tmp/sosreport*.tar.xz"
+ - "/tmp/crash.tar.gz"
PROTOCOL:
- - 'SSH'
+ - "SSH"
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /tmp/htx/htxerr'
- - 'ls -AX /tmp/htx/htxmsg'
+ - "ls -AX /tmp/htx/htxerr"
+ - "ls -AX /tmp/htx/htxmsg"
PROTOCOL:
- - 'SCP'
+ - "SCP"
# Commands and Files to collect for SLES Linux only
SLES:
GENERAL:
COMMANDS:
- - 'rm -rf /tmp/SLES_general.txt'
+ - "rm -rf /tmp/SLES_general.txt"
- 'echo "++++++++++ SLES Rleasae ++++++++++" > /tmp/SLES_general.txt'
- - 'cat /etc/os-release >> /tmp/SLES_general.txt'
- - 'echo "\n++++++++++ Time stamp ++++++++++" >> /tmp/SLES_general.txt'
- - 'date >> /tmp/SLES_general.txt'
+ - "cat /etc/os-release >> /tmp/SLES_general.txt"
+ - 'echo "\n++++++++++ Time stamp ++++++++++" >>
+ /tmp/SLES_general.txt'
+ - "date >> /tmp/SLES_general.txt"
- 'echo "\n++++++++++ uname -a ++++++++++" >> /tmp/SLES_general.txt'
- - 'uname -a >> /tmp/SLES_general.txt'
+ - "uname -a >> /tmp/SLES_general.txt"
- 'echo "\n++++++++++ uptime ++++++++++" >> /tmp/SLES_general.txt'
- - 'uptime >> /tmp/SLES_general.txt'
+ - "uptime >> /tmp/SLES_general.txt"
FILES:
- - '/tmp/SLES_general.txt'
+ - "/tmp/SLES_general.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
SLES_LOGS:
COMMANDS:
- - '{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt'
- - 'tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt'
- - 'rm -rf /tmp/scc*.txz.md5'
- - {'supportconfig >/tmp/OS_supportconfig.txt': 1200}
- - 'cp /var/log/scc*.txz.md5 /tmp/'
- - 'tar -zcvf /tmp/crash.tar.gz /var/crash'
+ - "{ cat /etc/os-release; uname -a; rpm -qa ; } >/tmp/OS_info.txt"
+ - "tail -n 200000 /var/log/messages >/tmp/OS_syslog.txt"
+ - "rm -rf /tmp/scc*.txz.md5"
+ - { "supportconfig >/tmp/OS_supportconfig.txt": 1200 }
+ - "cp /var/log/scc*.txz.md5 /tmp/"
+ - "tar -zcvf /tmp/crash.tar.gz /var/crash"
FILES:
- - '/tmp/OS_info.txt'
- - '/tmp/OS_syslog.txt'
- - '/tmp/OS_supportconfig.txt'
- - '/tmp/scc*.txz.md5'
- - '/tmp/crash.tar.gz'
+ - "/tmp/OS_info.txt"
+ - "/tmp/OS_syslog.txt"
+ - "/tmp/OS_supportconfig.txt"
+ - "/tmp/scc*.txz.md5"
+ - "/tmp/crash.tar.gz"
PROTOCOL:
- - 'SSH'
+ - "SSH"
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /tmp/htx/htxerr'
- - 'ls -AX /tmp/htx/htxmsg'
+ - "ls -AX /tmp/htx/htxerr"
+ - "ls -AX /tmp/htx/htxmsg"
PROTOCOL:
- - 'SCP'
+ - "SCP"
# Commands and Files to collect for AIX only
AIX:
GENERAL:
COMMANDS:
- - 'rm -rf /tmp/AIX_general.txt'
+ - "rm -rf /tmp/AIX_general.txt"
- 'echo "++++++++++ AIX Release ++++++++++" > /tmp/AIX_general.txt'
- - 'cat /proc/version | tail -1 >> /tmp/AIX_general.txt'
+ - "cat /proc/version | tail -1 >> /tmp/AIX_general.txt"
- 'echo "\n++++++++++ Time stamp ++++++++++" >> /tmp/AIX_general.txt'
- - 'date >> /tmp/AIX_general.txt'
+ - "date >> /tmp/AIX_general.txt"
- 'echo "\n++++++++++ uname -a ++++++++++" >> /tmp/AIX_general.txt'
- - 'uname -a >> /tmp/AIX_general.txt'
+ - "uname -a >> /tmp/AIX_general.txt"
- 'echo "\n++++++++++ uptime ++++++++++" >> /tmp/AIX_general.txt'
- - 'uptime >> /tmp/AIX_general.txt'
- - 'echo "\n++++++++++ System Info ++++++++++" >> /tmp/AIX_general.txt'
- - 'prtconf | head -15 >> /tmp/AIX_general.txt'
+ - "uptime >> /tmp/AIX_general.txt"
+ - 'echo "\n++++++++++ System Info ++++++++++" >>
+ /tmp/AIX_general.txt'
+ - "prtconf | head -15 >> /tmp/AIX_general.txt"
FILES:
- - '/tmp/AIX_general.txt'
+ - "/tmp/AIX_general.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
AIX_LOGS:
COMMANDS:
- - 'errpt -a >/tmp/OS_errpt.txt ; errclear 0;'
- - 'bindprocessor -q >/tmp/OS_processors.txt'
+ - "errpt -a >/tmp/OS_errpt.txt ; errclear 0;"
+ - "bindprocessor -q >/tmp/OS_processors.txt"
FILES:
- - '/tmp/OS_errpt.txt'
- - '/tmp/OS_processors.txt'
+ - "/tmp/OS_errpt.txt"
+ - "/tmp/OS_processors.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /tmp/htx/htxerr'
- - 'ls -AX /tmp/htx/htxmsg'
+ - "ls -AX /tmp/htx/htxerr"
+ - "ls -AX /tmp/htx/htxmsg"
PROTOCOL:
- - 'SCP'
+ - "SCP"
diff --git a/ffdc/templates/log_collector_config_template.yaml b/ffdc/templates/log_collector_config_template.yaml
index 7e5f156..a418a8c 100644
--- a/ffdc/templates/log_collector_config_template.yaml
+++ b/ffdc/templates/log_collector_config_template.yaml
@@ -6,46 +6,48 @@
MY_BLOCK:
MY_LOGS:
COMMANDS:
- - 'dmesg >/tmp/dmesg.txt'
+ - "dmesg >/tmp/dmesg.txt"
FILES:
- - '/tmp/dmesg.txt'
+ - "/tmp/dmesg.txt"
PROTOCOL:
- - 'SSH'
+ - "SSH"
REDFISH_LOGS:
COMMANDS:
- - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always raw GET /redfish/v1/AccountService/Accounts
+ - redfishtool -u ${username} -p ${password} -r ${hostname} -S Always
+ raw GET /redfish/v1/AccountService/Accounts
FILES:
- - 'REDFISH_bmc_user_accounts.json'
+ - "REDFISH_bmc_user_accounts.json"
PROTOCOL:
- - 'REDFISH'
+ - "REDFISH"
IPMI_LOGS:
COMMANDS:
- - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H ${hostname} lan print
+ - ipmitool -I lanplus -C 17 -U ${username} -P ${password} -H
+ ${hostname} lan print
FILES:
- - 'IPMI_LAN_print.txt'
+ - "IPMI_LAN_print.txt"
PROTOCOL:
- - 'IPMI'
+ - "IPMI"
SHELL_LOGS:
COMMANDS:
- plugin:
- - plugin_name: plugin.ssh_execution.ssh_execute_cmd
- - plugin_args:
- - ${hostname}
- - ${username}
- - ${password}
- - cat /etc/os-release
- - 3
- - plugin_error: exit_on_error
+ - plugin_name: plugin.ssh_execution.ssh_execute_cmd
+ - plugin_args:
+ - ${hostname}
+ - ${username}
+ - ${password}
+ - cat /etc/os-release
+ - 3
+ - plugin_error: exit_on_error
FILES:
- plugin_release.txt
PROTOCOL:
- - 'SHELL'
+ - "SHELL"
DUMP_LOGS:
COMMANDS:
- - 'ls -AX /var/lib/systemd/coredump/core.*'
+ - "ls -AX /var/lib/systemd/coredump/core.*"
PROTOCOL:
- - 'SCP'
+ - "SCP"