diskimage-builder/elements/hwdiscovery
Gregory Haynes c4bbb6f3bc Create docs site containing element READMEs
We currently do not have the ability to create a docs site which
outlines all the elements.

Change-Id: I77ccf61e0c4b1509b3e7ce9b8f15ea5ccfd50d9b
2015-02-10 11:45:35 -08:00
..
binary-deps.d Build ramdisks in an image chroot. 2013-07-12 11:09:35 +01:00
init.d Make pxe_mac accurate in two common cases. 2013-11-17 21:43:59 -06:00
element-deps Use package-installs in more elements 2014-09-08 15:16:14 -04:00
package-installs.yaml Migrate to new package-installs 2014-12-01 21:32:13 -08:00
README.rst Create docs site containing element READMEs 2015-02-10 11:45:35 -08:00

===========
hwdiscovery
===========
A ramdisk to report the hardware of a machine to an inventory service.

This will collect up some basic information about the hardware it 
boots on:

 * CPU cores
 * RAM
 * Disk
 * NIC mac address

This information will then be collated into a JSON document, base64 
encoded and passed, via HTTP POST, to a URL that you must specify on 
the kernel commandline, thus:

HW_DISCOVERY_URL=http://1.2.3.4:56/hw_script.asp


This is currently fairly fragile as there can be a huge variability in 
the number of disks/NICs in servers and how they are configured.

If other elements wish to inject data into the hardware discovery data, 
they can - they should be specified before hwdiscovery to the image 
building script, and they should contain something like this in their 
init fragment:

_vendor_hwdiscovery_data="$_vendor_hwdiscovery_data
 \"some vendor key\" : \"some data you care about\",
 \"some other vendor key\" : \"some other data you care about\","

Note that you are essentially feeding JSON into the main hwdiscovery 
JSON.

This will allow any number of vendor specific hwdiscovery elements to 
chain together their JSON fragments and maintain consistency.