12:47 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>