Data-driven hardware enablement
Details of hardware such as architecture details and special preseeds are stored as configuration files on the region controller. We want to be able to have clusters contain all this knowledge and update the region as necessary. This means the region needs to keep this information in its database instead of files. What should the region allow clusters to configure?
Blueprint information
- Status:
- Complete
- Approver:
- Daniel Westervelt
- Priority:
- Essential
- Drafter:
- Gavin Panella
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Review
- Series goal:
- Accepted for 1.5
- Implementation:
-
Implemented
- Milestone target:
-
14.04
- Started by
- Julian Edwards
- Completed by
- Julian Edwards
Related branches
Related bugs
| Bug #1248475: Ubuntu version drop-downs don't reflect contents of the PXE config file | Fix Released |
Whiteboard
Technical Analysis: https:/
Implementation plan: https:/
MAAS data-driven hardware enablement
Steps to netbooting a piece of hardware:
- DHCP (or similar) request: handled on the cluster, determines:
- arch/subarch
- power type
- redirect to appropriate TFTP boot resources
- cluster is in charge of obtaining and maintaining boot resources
- TFTP server obtains kernel cmd line and preseed from region controller
What needs changing to add a new hardware type:
- power control
- preseeds
- architecture list (enum)
- simplestreams filter
Session Two
-----------
Deep dive into code to work out where hardware-specific decisions are made:
* TFTP file matching regex for pxe requests
* When using PXELINUX, plugins (aka ifcpu64.c32) can choose kernel, device-tree blob, etc.
* device-tree blob, aka DTB, is sometimes needed for ARM.
* We don't currently do any hardware detection in the DHCPd config, but we could for the sake of hardware enablement.
* Arch-specific PXE config templates live on the region's filesystem
Possible solution:
* Move all code-based hardware stuff to cluster-based configurations
* Need to move DHCP template config to cluster and render on cluster (i.e. same as the pxe template)
* "enablement package" could install new configs and run an agent that discovers and enlists nodes
* Get rid of arch enum in favour of bootimages table values
* When a cluster registers itself, it also reports architectures it discovered on simplestreams
* Get rid of auto-acceptance of first cluster on same host as region
* Region's cluster acceptance UI will now show those architectures and allow the user to select which to download, and when cluster is accepted it will start downloading right away.
* Could have agent to enlist nodes by introspecting chassis via BMC (e.g. one BMC to multiple nodes).
* Set BMC to PXE boot next boot
* An enablement package could drop probes into, say, /etc/maas/probe.d (may have to get more specific for particular architectures) and these will all get sent over to an enlisting node. Each probe would be run. The first to probe positively enlists the node and probing stops.
* Detect hardware type via BMC and look up kernel required in MAAS. MAAS to carry a hard-coded map of kernel image to hardware type
