health-check: An automated performance reporting tool

This new target will generated a bootable image that will compute some
system tests to estimate it's efficiency and health status.

A series of raw numbers will be generated and reported inside an
extended hw.py file.

This patch add the required makefile targets, the testing suite (make
health-check).

health-check is today only reporting the cpu performance by using
sysbench.

A typical output is like the following:
('cpu', 'physical_0', 'physid', '1'),
('cpu', 'physical_0', 'cores', '2'),
('cpu', 'physical_0', 'enabled_cores', '2'),
('cpu', 'physical_0', 'threads', '4'),
('cpu', 'physical', 'number', 1),
('cpu', 'logical', 'number', '4'),
('cpu', 'logical_0', 'bogomips', '5187.90'),
('cpu', 'logical_0', 'cache_size', '3072KB'),
('cpu', 'logical_0', 'loops_per_sec', 561),
('cpu', 'logical_1', 'bogomips', '5187.90'),
('cpu', 'logical_1', 'cache_size', '3072KB'),
('cpu', 'logical_1', 'loops_per_sec', 561),
('cpu', 'logical_2', 'bogomips', '5187.90'),
('cpu', 'logical_2', 'cache_size', '3072KB'),
('cpu', 'logical_2', 'loops_per_sec', 553),
('cpu', 'logical_3', 'bogomips', '5187.90'),
('cpu', 'logical_3', 'cache_size', '3072KB'),
('cpu', 'logical_3', 'loops_per_sec', 542),
('cpu', 'logical', 'loops_per_sec', 1604)]

Reporting is spliting physical cpu (sockets) and logical one (thoses
seen by Linux).

Detailed information about physical are only available if seen by lshw.
Bogomips & cache_size are taken from the /proc/cpuinfo while the
loops_per_sec are computed by running sysbench for 10 seconds.

Note that loops_per_sec are reported for
- each logical processor by running binding sysbench on the selected processor but also for
- all logical processors at one time by running sysbench with num-threads = the
  number of logical processors.
health-check: Adding memory performance report

This commit is using sysbench to analyze the performance of the memory
by checking several block size and from all the logical CPUs.

This could be useful to detect a processor that doesn't reach the memory at the proper speed.
NUMA systems could be affected by such behavior.

This component will help at discovering this effect.

A typical output is like :
 ('cpu', 'logical_0', 'bandwidth_1K', '3017'),
 ('cpu', 'logical_0', 'bandwidth_4K', '7037'),
 ('cpu', 'logical_0', 'bandwidth_1M', '10400'),
 ('cpu', 'logical_0', 'bandwidth_16M', '8859'),
 ('cpu', 'logical_0', 'bandwidth_128M', '9042'),
 ('cpu', 'logical_0', 'bandwidth_1G', '9012'),
 ('cpu', 'logical_1', 'bandwidth_1K', '2718'),
 ('cpu', 'logical_1', 'bandwidth_4K', '7048'),
 ('cpu', 'logical_1', 'bandwidth_1M', '10670'),
 ('cpu', 'logical_1', 'bandwidth_16M', '8764'),
 ('cpu', 'logical_1', 'bandwidth_128M', '8716'),
 ('cpu', 'logical_1', 'bandwidth_1G', '8987'),
 ('cpu', 'logical_2', 'bandwidth_1K', '3066'),
 ('cpu', 'logical_2', 'bandwidth_4K', '6913'),
 ('cpu', 'logical_2', 'bandwidth_1M', '10502'),
 ('cpu', 'logical_2', 'bandwidth_16M', '8884'),
 ('cpu', 'logical_2', 'bandwidth_128M', '8986'),
 ('cpu', 'logical_2', 'bandwidth_1G', '8853'),
 ('cpu', 'logical_3', 'bandwidth_1K', '3049'),
 ('cpu', 'logical_3', 'bandwidth_4K', '6969'),
 ('cpu', 'logical_3', 'bandwidth_1M', '10423'),
 ('cpu', 'logical_3', 'bandwidth_16M', '8878'),
 ('cpu', 'logical_3', 'bandwidth_128M', '8927'),
 ('cpu', 'logical_3', 'bandwidth_1G', '8663'),
 ('cpu', 'logical', 'bandwidth_1K', '3010'),
 ('cpu', 'logical', 'bandwidth_4K', '7000'),
 ('cpu', 'logical', 'bandwidth_1M', '10580'),
 ('cpu', 'logical', 'bandwidth_16M', '8704'),
 ('cpu', 'logical', 'bandwidth_128M', '8838'),
 ('cpu', 'logical', 'bandwidth_1G', '8941')
health-check: Adding missing file

Ooops.
health-check: Reporting DDR timings

As per some code from Cyring (http://code.cyring.fr/FTS/), it's possible
to get the DDR timing on some Intel processors.

This could be really useful to compare DDR timing from one node to
another to detect some different set of DDR memory banks.
health-check: Being verbose on stderr

By printing to stderr, it helps the main init to report the current
status while not flooding the resulting .py file.
health-check: Switching CPU benchmark to 5 seconds

5 seconds is enough to get a good overview of the CPU performance.
Dividing by 2 the time needed to get CPU perf makes the global process
faster.
health-check: Override the default resolv.conf

This is needed when moving your build machine from one network to
another.
health-check: Reporting DDR type

It could be DDR1,DDR2 or DDR3.

Could be useful to detect wrong setups.
detect.py: Adding disk's {vendor|model|rev}

This could be useful to filter the kind of storage device we shall play
with.
detect.py: Don't fail if not disk vendor information

Since last commit, we were failing if no disk's {vendor|model|rev} was
existing. That's pretty weird but when using virtualized devices, it
could happen.

Let's be safe on this topic, let's ignore if the file reading fails.
health-check: Reporting disk IOs performance

This patch add the ability to detect storage's performance by running
some fio patterns.

For a given test (4K read random or 1M read sequential), the test is
run of every disk in a standalone mode to detect the best of a device
without loading the system completly.

Then the test is run one more time on all detected's disks at the same
time to analyse how disks are performing when all the disks are
stressed. This could be useful to detect a controller not able to
substain the complete load
detect: Fixing indent to get all disk's information

The bad indent prevented from getting disk's information from all disks.
Only the last one was considered.
health-check: Adding write support

By using DESTRUCTIVE_MODE environement variable, the storage performance
mode will generate writes.

As per the read test, randwrite at 4K at seq write at 1MB loads are generated.

A typical output will be:

 ('disk', 'sdb', 'standalone_randread_4k_iops', '2408'),
 ('disk', 'sdb', 'standalone_read_1M_bwps', 162506),
 ('disk', 'sdb', 'standalone_read_1M_iops', '155'),
 ('disk', 'sdb', 'standalone_randwrite_4k_bwps', 43),
 ('disk', 'sdb', 'standalone_randwrite_4k_iops', '8'),
 ('disk', 'sdb', 'standalone_write_1M_bwps', 30425),
 ('disk', 'sdb', 'standalone_write_1M_iops', '26'),
 ('disk', 'sdb', 'standalone_randread_4k_bwps', 90),
 ('disk', 'sdb', 'standalone_randread_4k_iops', '19'),
 ('disk', 'sdb', 'standalone_read_1M_bwps', 76208),
 ('disk', 'sdb', 'standalone_read_1M_iops', '71'),
 ('disk', 'sdb', 'standalone_randwrite_4k_bwps', 79),
 ('disk', 'sdb', 'standalone_randwrite_4k_iops', '17'),
 ('disk', 'sdb', 'standalone_write_1M_bwps', 111199),
 ('disk', 'sdb', 'standalone_write_1M_iops', '105')
health-check: Reporting bandwidth unit

In fact, that's now KB per sec.
Removing a debug line that doesn't deserved to be here.
health: Adding health-img build target

This target aims at creating bootable image in the PXE booting is not
available.

As per this commit a specific partition is created to host data to
export.
init.common: Removing useless char

At the end of init.com a trailing } was generating an error message
while booting.
health-check: Saving performance to usb-key

If the health-check mode got booted from the image, exporting the
benchmark result to an edeploy server is almost unlikely.

Though, let's save information on the specific partition located on the
boot device.
health-check: Adding boot menu for destruction mode

When booting the flashable image, a menu is offering the safe mode or
the destructive mode. In case of the latter, we protect the boot device
from being overwriten by the write test.
health-check: Fixing exception on bwps matching

When getting the bwps performance, the int() conversion was generating
an exception caught by the one made for handling regexp exception.

As a result, a simple conversion error lead to no data at all.

This commit insure the try/catch is better placed and the conversion
works better.