Re: [Kimchi-devel] [RFC] VEPA network support

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 _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel