Create a ramdisk which posts hw data back to the API
Some environments may not support HW interrogation / enrollment over the control plane, or this may be insufficient for some purposes. This blueprint is for a separate ramdisk which would interrogate hardware on which it boots, and post that information back to Ironic.
* This ramdisk may be served to DHCP BOOT requests from unrecognized MAC addresses.
* There should be a means to pass a short-lived authentication token to the ramdisk securely.
* The ramdisk interrogates the HW, eg. runs "lshw", "lspci", and so on, to determine, at a minimum: CPU arch and count, total RAM, and available disk space. Additional device information would be beneficial as well.
* This data is posted back to the Ironic API, using the provided auth token. The auth token is invalidated once this data is received.
* The machine is rebooted after this is complete, or optionally, if the deploy agent is present, that agent is started and awaits further commands.
Blueprint information
- Status:
- Complete
- Approver:
- aeva black
- Priority:
- Medium
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- Ling Gao
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- aeva black
Related branches
Related bugs
Sprints
Whiteboard
Note: ramdisk should be built with stackforge/
There is an element named as "hwdiscovery" existing in the diskimage-builder project, it can collect the hw info(CPU cores, RAM, Disk, NIC mac address) for the hw it boots on. Currently, the collected info is collated into a JSON document, base64 encoded and passed, via HTTP POST, to a URL which is specified on the kernel cmdline.
-------
One question about "* This ramdisk may be served to DHCP BOOT requests from unrecognized MAC addresses.":
In nova baremetal, the user needs to configure dnsmasq manually to specify the IP range for the baremetal nodes, so once a baremetal node rebooted from network, it can get an IP address from the dnsmasq server, i.e. it can be served DHCP BOOT requests from unrecognized MAC addresses.
My question is, in ironic, do we still need the user to run dnsmasq manually? or have it been implemented in neutron project? does it keep using IP range in dnsmasq for baremetal deployment? or fixed-address for deployment, IP range for hwinfo discovery?
Thx. --Sun Jing
-------
Sun,
There has been work done to add PXE BOOT options to network port management in Neutron in patch https:/
--Devananda
-------
Devananda,
Can you clarify what you mean by "HW interrogation / enrollment over the control plane"? Is this through the more advanced driver API detailed here: https:/
- Richard
-------
@Richard,
In Ironic's context, "control plane" == the out-of-band hardware management (eg, IPMI) network.
It is often, but not always, possible to ask the BMC for information about the hardware. Many manufacturers support device enumeration via IPMI, and some extend this with their own protocols (eg, iLO or DRAC).
This blueprint is proposing an approach that does not depend on OOB management interfaces, which should provide a better (more generic) reference implementation.
--Devananda, 2012-11-21
