[Kimchi-devel] [RFC] VEPA network support

[Daniel Henrique Barboza]

On 02/10/2016 03:49 PM, Aline Manera wrote:
>
>
> 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
>
Alright!
>> 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
>>
>