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