Bug 1119353

For HA we need by default the following networks:
•	Nova Network Private vLAN– Sets up the backend network for nova and the VM’s to use
•	Nova Network Public vLAN – Sets up the front network for routable traffic to individual VMs
•	Provisioning Network vLAN—Connects all nodes NICs into the fabric used for setup and provisioning of the servers. There can be more than one provisioning network vLAN.
•	Private API Network Cluster Management vLAN— Used for communication between OS controllers and nodes for RESTFUL API and Cluster Heartbeat. 
•	Public API Network Access vLAN – Sets up access to the RESTFUL API, and the Horizon GUI.
•	Storage Network vLAN– Used by all the nodes for  data plane writes/reads to communicate to OS storage
•	Storage Clustering Network vLAN – Used by all the storage nodes for replication and data checks (for Ceph Clustering)

The setup should be based on node type:
For controller nodes:
* Create bond1 on first 2 10GbE networks
* Create Public API access network vLAN over bond1(vLAN # specified by the admin user to match what is created on switches)
* Create bond0 on the next 2 10GbE networks (different from the ones used for bond1)
* Create Private API network cluster management vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches)
* Do not touch iDRAC network
* Create Provision network vLAN on 1GbE (vLAN # specified by the admin user to match what is created on switches).

For compute nodes:
* Create bond1 on first 2 10GbE networks
* Create Nova-Network Public vLAN over bond1 (vLAN # specified by the admin user to match what is created on switches)
* Create bond0 on the next 2 10GbE networks (different from the ones used for bond1)
* Create Private API network cluster management vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches - matches the one for controller nodes)
* Create Nova-Network Private vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches)
* Create Storage Network vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches)
* Do not touch iDRAC network
* Create Provision network vLAN on 1GbE (vLAN # specified by the admin user to match what is created on switches  - matches the one for controller nodes).

For admin nodes:
* Create bond1 on first 2 10GbE networks
* Create Public API access network vLAN over bond1 (vLAN # specified by the admin user to match what is created on switches  - matches the one for controller and compute nodes)
* Create bond0 on the next 2 10GbE networks (different from the ones used for bond1)
* Create Private API network cluster management vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches - matches the one for controller, compute nodes)
* Create Provision network vLAN on 10GbE over bond0 (vLAN # specified by the admin user to match what is created on switches - matches the one for controller and compute nodes)
* Create Storage Provision network vLAN on 10GbE over bond0 (vLAN # specified by the admin user to match what is created on switches)
* Do not touch iDRAC network

For storage nodes:
* Create bond1 on first 2 10GbE networks
* Create Storage Clustering vLAN over bond1 (vLAN # specified by the admin user to match what is created on switches)
* Create bond0 on the next 2 10GbE networks (different from the ones used for bond1)
* Create Private API network cluster management vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches - matches the one for controller, compute and admin nodes)
* Create Storage Network vLAN over bond0 (vLAN # specified by the admin user to match what is created on switches)
* Create Storage Provision network vLAN on 1GbE (vLAN # specified by the admin user to match what is created on switches - matches the one for admin node)
* Do not touch iDRAC network

In general, we need support for flexibility to specify bond names, vlan #s, tagged vs. untagged vLANs, multiple IP addresses per interface, and flexibility to set up networking to adjust to Customer environment.

all network bonds should be created across different physical network interface cards, 
so bond 1 is port 1 on two different cards in the system and bond 0 is port 2 on the two different nics.

If there is only a single nic then the above rule cannot be enforced, of course.

*** Bug 1119874 has been marked as a duplicate of this bug. ***

*** Bug 1127859 has been marked as a duplicate of this bug. ***

Everything _but_ bonding should be done.  We will leave the bug open and continue to monitor progress but we can test on non-bonded interfaces to make sure the network management in general.

Everything is fixed in A2 including bonding.

Verified:
rhel-osp-installer-0.4.2-1.el6ost.noarch
ruby193-rubygem-foreman_openstack_simplify-0.0.6-8.el6ost.noarch
openstack-puppet-modules-2014.1-23.el6ost.noarch
openstack-foreman-installer-2.0.29-1.el6ost.noarch


Verified that there are 9 network traffic types that can go into different subnets and the ability to configure bonding.

This was done in A1 and documented there

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2014-1800.html