dellcloudedge/barclamp-keystone — pull request #22 by VictorLowther (2012-06-01 17:23:03+00:00)
Title: Rewrite networking barclamp to make a bit more failure-proof. [10/22]

Rewrite network barclamp to manage interfaces directly.

Making the distro tools handle reconfiguring network interfaces for us
was needlessly fragile, since we were rewriting the network config and
changing the state of the interfaces while we were in the middle of
converging the node -- if we happened to do anything that would try to
talk to the chef-server while any of the interfaces needed to talk to
the admin network was changing, we could easily wind up in a state
where manual intervention would be needed to recover.

Additionally, the network barclamp had to have a good deal of
special-casing to handle all the distro-specific caveats that went
along with using ifup/ifdown directly to manage the nics.

This code does away with all that by teaching the network barclamp how
to manage our interfaces directly, reducing the distro-specific code
to what is needed to write out the proper configuation for ifup/ifdown
on the operating system.

New features:

* All interface manipulation happens early in the compile phase of
the chef-client runs, and the recipe will pause for up to 60
seconds to verify that it can ping the node with the provisioner
role (if one is assigned). This should ensure that the chef-client
run succeeds with minimal delay even when we are forced to do
something that may trigger a spanning tree update on the
network. This frees the rest of the barclamps from having to care
about sleeping due to network configuration changes.
* The network barclamp posts its state on
node[:crowbar_wall][:network] to allow other barclamps to easily
see what interfaces are members of what network and what IP
addresses are assigned to the node.
* Switching between single, dual, and team mode is more or less
seamless now. You can easily switch network modes even when nova VMs are
up and running without dropping more than a packet or two. The sole
exception I have seen is Nova running in tenant_vlan mode.
* It is trivial to deploy with a configuration that does not use vlan
tagging at all. The network barclamp will manage our interfaces
correctly by assigning multiple IP addresses to the appropriate
interfaces for each network, and it will handle moving addresses
and routes around as needed. Debian and Redhat config file
generation has been updated to handle binding multiple IP addresses
to interfaces so that a rebooted node will come up with the proper
configuration before chef-client runs.
* Helper classes have been added to the barclamp recipe that model IP
addresses (including IP address ranges) and network interfaces.
Those helpers also inject convienenece routines into the CHef::Node
class to make it easier to find interfaces and addresses for each
of our networks.