[Kimchi-devel] [RFC] VEPA network support

[Daniel Henrique Barboza]

The first version of the feature was sent to the ML but, due to the proposed
changes in the reviews,  I believe a RFC is required before sending a v2.

This would be the revised networks API:

### Collection: Networks

**URI:** /plugins/kimchi/networks

**Methods:**

* **GET**: Retrieve a summarized list of all defined Networks
* **POST**: Create a new Network
     * name: The name of the Network
     * connection: Specifies how this network should be connected to the 
other
                   networks visible to this host.
         * isolated: Create a private, isolated virtual network.
         * nat: Outgoing traffic will be routed through the host.
         * macvtap: All traffic on this network will be bridged through the
                    specified interface.
         * bridge: All traffic on this network will be bridged through a 
Linux
                   bridged, which is created upon specified interface in 
case
                   it is not already a Linux bridge.
         * vepa: All traffic will be forward to one or more physical devices
                  directly connected to a VEPA-enabled switch.
     * subnet *(optional)*: Network segment in slash-separated format 
with ip address and
                            prefix or netmask used to create nat network.
     * interfaces *(optional)*: An array of network interfaces on the host.
                               For "macvtap" and "bridge" connections, the
                               interface can be a nic, bridge or bonding 
device.
                               For "vepa" connections, at least one 
physical device
                               must be declared
     * vlan_id *(optional)*: VLAN tagging ID for the macvtap bridge network.

The changes are:

- a new mode called "vepa"

- 'interface' parameter renamed to 'interfaces', which is now an array. 
This was made
to prevent the creation of a separated parameter for VEPA devices. Of 
course, this will
change all the existing APIs for all the other networks, which would now 
read 'interface[0]'
instead of 'interface'


No changes in the 'interface' API will be required.



Daniel