dellcloudedge/barclamp-network — pull request #40 by VictorLowther (2012-07-30 16:21:13+00:00)
Title: Pull in complete UEFI network boot support. [1/7]

This pull requests series adds several things needed to make network
booting via UEFI operate at the same level as out current PXE support:

* Add support for managing the boot sequence when running in UEFI
mode.

Crowbar now knows how to manipulate the boot sequence using
efibootmgr when running in UEFI mode. Boot sequence manipulation
is the responsibility of the crowbar-hacks recipe in the deployer
barclamp, and it currently only knows how to switch between
nics-first and nics-last mode. The recipe records its state in
node[:crowbar_wall][:uefi][:boot], and that state includes the MAC
address of the last NIC we booted from when booting in UEFI mode.

* Use per-node OS installation config files instead of per-OS ones.

Support for installing Redhat/CentOS via a UEFI netbooted
installation is not complete, so I needed to make sure that the MAC
address information for the install was passed in a way that was
compatible with the way pxelinux does it. While I was at it, I
went ahead and modified the rest of the operating systems to also
use per-node OS installation config files to keep from having to
maintain multiple codepaths through the OS installation code.

* Have the provisioner run chef-client calls on the nodes whenever
they transition away from the execute state.

None of the UEFI compatible bootloaders seem to have pxelinux's
capability to give up tryin to netboot and fall back to booting off
the hard drive. However, since we have efibootmgr, we can emulate
that functionality by telling it to set the boot order back to
nics-first. To do that, I modified the provisioner to detect when
it is transitioning a node away from execute and have it run a
chef-client call on the node that is transitioning as part of the
transition process.

* Clean up how we handle node resets and deletes.

Making the provisioner call chef-client on nodes as part of its
transition function exposed a few bugs in how we handle node
resetting and deleting. To address those, I made the following
changes:

* The network barclamp detects when it has been asked to deallocate
the last IP address on the admin network. When that happens, it
will run dhclient on each of the nics one at a time until it gets
an IP address. This should usually result in it getting the same
IP address it had statically allocated, because the sequencing of
chef-client runs in a state transition is such that the
chef-client run on the admin node that winds up rewriting the
dhcp config files happens after the chef-client run on the node
itself. Since the node gets the same IP address it had, the
connectivity test in the recipe passes and the final chef-client
run on the node can finish.

* The nagios and ganglia barclamps have been modified to shut down
and deconfigure their services on a node that is being reset or
deleted.

* Responsibility for doing the final delete of a node's Chef node
object and role object has been pushed from the update_nodes recipe
in the deployer to the crowbar_service model in the Crowbar
barclamp. This ensures that the objects are present at all
places they are needed during the transition.

* The provisioner-server role has been reordered a bit so that
update_nodes happens after setup_base_images. This ensures that
update_nodes has all the information it needs from
setup_base_images.

* blocking_chef_client has been rewritten to make
looper_chef_client redundant. Looper_chef_client has been
removed, and single_chef_client now just calls
blocking_chef_client directly. With the new
blocking_chef_client, there can be at most 1 instance of
blocking_chef_client actually running a chef-client process, 1
instance of a blocking_chef_client waiting to run a chef-client
process, and any number of blocking_chef_client instances waiting
on the one that is waiting to run, and which will exit without
doing anything once they are no longer waiting.