Re: [Kimchi-devel] [PATCH v2] [Kimchi 1/8] Changing network API 'interface' to array: docs and API

On 02/16/2016 03:46 PM, Daniel Henrique Barboza wrote: > > > On 02/16/2016 03:05 PM, Lucio Correia wrote: >> On 16-02-2016 11:08, dhbarboza82(a)gmail.com wrote: >>> From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com&gt; >>> >>> Changed docs/API.md, i18n.py and API.json to reflect the new API. >>> >>> interfaces[0] (the first element of this array) will have the >>> same effect as the former 'interface' parameter. >>> >>> This change is necessary to better adapt the backend to networks >>> that can be created with more than one interface. >>> >>> Signed-off-by: Daniel Henrique Barboza <dhbarboza82(a)gmail.com&gt; >>> --- >>> API.json | 6 +++--- >>> docs/API.md | 13 +++++++------ >>> i18n.py | 5 +++-- >>> 3 files changed, 13 insertions(+), 11 deletions(-) >>> >>> diff --git a/API.json b/API.json >>> index 294be64..bc952b2 100644 >>> --- a/API.json >>> +++ b/API.json >>> @@ -366,9 +366,9 @@ >>> "type": "string", >>> "error": "KCHNET0013E" >>> }, >>> - "interface": { >>> - "description": "The name of a network interface >>> on the host", >>> - "type": "string", >>> + "interfaces": { >>> + "description": "An array of network interfaces >>> of the host", >>> + "type": "array", >>> "error": "KCHNET0014E" >>> }, >>> "vlan_id": { >>> diff --git a/docs/API.md b/docs/API.md >>> index a46e80e..9457a4c 100644 >>> --- a/docs/API.md >>> +++ b/docs/API.md >>> @@ -675,9 +675,10 @@ A interface represents available interface on >>> host. >>> it is not already a Linux bridge. >>> * subnet *(optional)*: Network segment in slash-separated >>> format with ip address and >>> prefix or netmask used to create nat >>> network. >>> - * interface *(optional)*: The name of a network interface on >>> the host. >>> - For "macvtap" and "bridge" >>> connections, the >>> - interface can be a nic, bridge or >>> bonding device. >>> + * interfaces *(optional)*: An array of network interface on the >>> host. >>> + For "macvtap" and "bridge" >>> connections, the >>> + first interface can be a nic, bridge >>> or bonding >>> + device. >> For macvtap it cannot be a bridge. > > I guess the best move here is to eliminate this explanation in the > 'interfaces' > parameter, since we have the same explanation when describing the > connection > types. Or even better, I'll just mention 'For "macvtap" and "bridge" connections, only the first interface of the array will be considered. ' to make it clear that only the first element of this array will be used in those network types.