Data-driven hardware enablement

Registered by Julian Edwards on 2013-10-09

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

Daniel Westervelt
Gavin Panella
Series goal:
Accepted for 1.5
Milestone target:
milestone icon 14.04
Started by
Julian Edwards on 2014-01-29
Completed by
Julian Edwards on 2014-04-02


Technical Analysis:

Implementation plan:

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


Work Items