Fix reference to new_interfaces when adding default route

Signed-off-by: Tim Serong <tserong@suse.com>
fixed transitioning interfaces from SUSE's dhcp4 with dhcpcd
Initial work on support for SUSE
Write network config files before downing the interfaces.

otherwise the templates cannot be fetched.

This got broken by 8af767704121a57e5c543d179baf521c12f7f184
"Modify network barclamp to handle default route changes
gracefully."

This is a messy reinvented wheel.
avoid creating empty ifroute-* files in network barclamp
Merge pull request #27 from SUSE-Cloud/suse-pull-req-network-suse-support

SUSE support for network barclamp
Merge pull request #28 from SUSE-Cloud/suse-pull-req-network-dhclient3

Fixed transitioning interfaces from SUSE's dhcp4 with dhcpcd
Merge pull request #29 from SUSE-Cloud/suse-pull-req-network-new_interfaces

Fix reference to new_interfaces when adding default route
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.
Update barclamp to use the new network helpers
Merge pull request #30 from VictorLowther/pull-req-feature-ip-hacking-master-9a8bf6b807

Rewrite network barclamp to manage interfaces directly. [2/22]
Verbosify logging a bit.
Flatten
Merge pull request #32 from VictorLowther/pull-req-master-4ebb119038

Fix barclamp installation bug when there are no chef recipes [1/5]