New exit_on_error mode for gen_valid.py

In 'exit_on_error' mode, the validation functions will exit the program
on error instead of returning False.

- Also general cleanup and i

New exit_on_error mode for gen_valid.py

In 'exit_on_error' mode, the validation functions will exit the program
on error instead of returning False.

- Also general cleanup and improvements including:
- New functions:
- get_var_name
- process_error_message
- svalid_path
- valid_path

Change-Id: If69243f794cf880b3677336d3b5bedd2539a5de9
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

show more ...

New Valid Range keywords

Change-Id: If278430af8eb121ebc911940fd6a4c9a04fbb4d7
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

Fixed PEP 8 style using autopep8

Used autopep8 to correct styling.
Ran autopep8 on openbmc-test-automation, autopep8 is not
able to fix all styling issues. There is still around

Fixed PEP 8 style using autopep8

Used autopep8 to correct styling.
Ran autopep8 on openbmc-test-automation, autopep8 is not
able to fix all styling issues. There is still around
1000 styling violations in openbmc-test-automation.
More information on autopep8 can be found here,
https://pypi.python.org/pypi/autopep8

Change-Id: Iddc131da1d74d978eb3dd0fdd6ce5d0a0e49b0f8
Signed-off-by: Gunnar Mills <gmills@us.ibm.com>

show more ...

Remove hashtag lines from all .py files.

Change-Id: Ib2b52f6ff71c8f553e0cfb1936c8e0917e70c619
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

New functions for gen_valid.py.

- svalid_integer: Improved this to work on hex values.
- svalid_dir_path: New function.
- valid_dir_path: New function.
- svalid_file_pa

New functions for gen_valid.py.

- svalid_integer: Improved this to work on hex values.
- svalid_dir_path: New function.
- valid_dir_path: New function.
- svalid_file_path: New function.
- valid_file_path: New function.

Change-Id: If990bed0c202651b07cbf86d5c0873827ba4143c
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

show more ...

Adding new function and fixing some bugs in general purpose py files.

gen_args.py:
sprint_args()
I made corrections to col1_width processing when indent is not zero.

g

Adding new function and fixing some bugs in general purpose py files.

gen_args.py:
sprint_args()
I made corrections to col1_width processing when indent is not zero.

gen_print.py:
get_arg_name:
I fixed a bug.
sprint_varx:
I added support for printing OrderedDict objects and robot DotDict objects.
I added support for having the hex arg double as a "print None" for string objects.
sprint_pgm_header:
I added support for linefeed arg.
sissuing:
I added support for test_mode parm.
sprintn:
New function.

gen_valid.py:
svalid_value:
New function:
valid_value:
Now calls svalid_value.

svalid_integer:
New function:
valid_integer:
Now calls svalid_integer.

Change-Id: I161086d1148e4559fcc57b7d749cc3fb810dc19f
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

show more ...

Providing plug-in support:

Typically, a test program is written to perform certain basic tests on a test
machine. For example, one might write an "obmc_boot" program that performs
v

Providing plug-in support:

Typically, a test program is written to perform certain basic tests on a test
machine. For example, one might write an "obmc_boot" program that performs
various boot tests on the Open BMC machine.

Experience has shown that over time, additional testing needs often arise.
Examples of such additional testing needs might include:

- Data base logging of results
- Performance measurements
- Memory leak analysis
- Hardware verification
- Error log (sels) analysis
- SOL_console

The developer could add additional parms to obmc_boot and likewise add
supporting code in obmc_boot each time a need arises. Users would employ
these new functions as follows:

obmc_boot --perf=1 --mem_leak=1 --db_logging=1 --db_userid=xxxx

However, another option would be to add general-purpose plug-in support to
obmc_boot. This would allow the user to indicate to obmc_boot which plug-in
packages it ought to run. Such plug-in packages could be written in any
langauge whatsoever: Robot, python, bash, perl, C++.

An example call to obmc_boot would then look something like this:

obmc_boot --plug_in_dir_paths="Perf:Mem_leak:DB_logging"

Now all the obmc_boot developer needs to do is call the plug-in processing
module (process_plug_in_packages.py) at various call points which are agreed
upon by the obmc_boot developer and the plug-in developers. Example call
points which can be implemented are:

setup - Called at the start of obmc_boot
pre_boot - Called before each boot test initiated by obmc_boot
post_boot - Called after each boot test initiated by obmc_boot
cleanup - Called at the end of obmc_boot

This allows the choice of options to be passed as data to obmc_boot. The
advantages of this approach are:
- Much less maintenance of the original test program (obmc_boot).
- Since plug-ins are separate from the main test program, users are free to
have plug-ins that suit their environments. One user may wish to log results
to a database that is of no interest to the rest of the world. Such a plug-in
can be written and need never be pushed to gerrit/github.
- One can even write temporary plug-ins designed just to collect data or stop
when a particular defect occurs.

In our current environment, the concept has proven exceedingly useful. We
have over 40 permanent plug-ins and in our temp plug-in directory, we still
have over 80 plug-ins.

Change-Id: Iee0ea950cffaef202d56da4dae7c044b6366a59c
Signed-off-by: Michael Walsh <micwalsh@us.ibm.com>

show more ...