[Kimchi-devel] [RFC] VEPA network support

[Aline Manera]

On 02/10/2016 02:46 PM, Daniel Henrique Barboza wrote:
> 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'
>
>

+1 but make sure to raise an error when more than one interface is 
specified for non-vepa networks

> No changes in the 'interface' API will be required.
>
>
>
> Daniel
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>