There are times where the server we are testing against uses different
values for parameters. Palmetto, Barreleye, Firestone and Garrison are
now all supported. It seems like the right thing to do then is to identify
the system type as part of the testing. The way I implemented this set
of changes was to follow the practice of setting a global variable to equal
the name of the py file.... i.e. export OPENBMC_MODEL=./data/Barreleye.py
This allows tests to be generic and we just add some python code to access
the correct system.py file. That file can be copied directly from the
https://github.com/openbmc/skeleton/tree/master/bin directory.
I also adjusted the tox.ini file to allow for machine models to be the
environment. That way you could run a command like "tox -e Garrison -- tests"
and the suite will run it. What's so special about that? Well you can
also run this "tox -e Garrison,Palmetto -- tests" and run the suite against
two different systems (providing you set the ip in the ini file).
There are times where the server we are testing against uses different values for parameters. Palmetto, Barreleye, Firestone and Garrison are now all supported. It seems like the right thing to do then is to identify the system type as part of the testing. The way I implemented this set of changes was to follow the practice of setting a global variable to equal the name of the py file.... i.e. export OPENBMC_MODEL=./data/Barreleye.py
This allows tests to be generic and we just add some python code to access the correct system.py file. That file can be copied directly from the https://github.com/openbmc/skeleton/tree/master/bin directory.
I also adjusted the tox.ini file to allow for machine models to be the environment. That way you could run a command like "tox -e Garrison -- tests" and the suite will run it. What's so special about that? Well you can also run this "tox -e Garrison,Palmetto -- tests" and run the suite against two different systems (providing you set the ip in the ini file).