[RFC] define REST API for guest Network Interfaces.

now we have support network get/create/delete/activate/deactivate Now we need to support the attach/detach/ <https://github.com/kimchi-project/kimchi/wiki/customize-VM#organization-of-sub-resources-and-rest-api-exposition> a Network to a guest. And get the info of Network attached to a guest. libvirt supports several types of network interfaces: 'bridge','network','user','ethernet','direct','hostdev','mcast', 'server', 'client' but there is not a unique "name" attribute for "interface" element.(more libvirt network interfaces info <http://libvirt.org/formatdomain.html#elementsNICS>) That is not good to define our REST API. But for "network" type resource, there is a "network" attribute of "source" resource. And the value of "network" attribute is the name of network that we defined by /networks POST method. the "network" type + "network" attribute is unique. We can define the Network Interfaces like this to support "network" type Interfaces: GET /vms/*name*/Interfaces?type=network&network="default" But this is not RESTFUL. Maybe We can also name a Network Interface by the Interface mac. The mac is unique. GET /vms/*name*/Interfaces/mac The best way for user is get the NICS name in guest. such as eth0, eth1.... GET /vms/*name*/Interfaces/eth0 GET /vms/*name*/Interfaces/eth1 But there is a problem, we need get the nic name and mac from guest. and Make a map in kimchi DB. also the nic name may change, we need make the map consistence with guest nic name. -- Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center

On 12/30/2013 01:13 AM, Sheldon wrote:
now we have support network get/create/delete/activate/deactivate
Now we need to support the attach/detach/ <https://github.com/kimchi-project/kimchi/wiki/customize-VM#organization-of-sub-resources-and-rest-api-exposition> a Network to a guest. And get the info of Network attached to a guest.
libvirt supports several types of network interfaces: 'bridge','network','user','ethernet','direct','hostdev','mcast', 'server', 'client'
but there is not a unique "name" attribute for "interface" element.(more libvirt network interfaces info <http://libvirt.org/formatdomain.html#elementsNICS>)
That is not good to define our REST API.
But for "network" type resource, there is a "network" attribute of "source" resource. And the value of "network" attribute is the name of network that we defined by /networks POST method.
the "network" type + "network" attribute is unique.
We can define the Network Interfaces like this to support "network" type Interfaces: GET /vms/*name*/Interfaces?type=network&network="default" But this is not RESTFUL.
Maybe We can also name a Network Interface by the Interface mac. The mac is unique. GET /vms/*name*/Interfaces/mac
I think using the mac address is enough for us. I'd also suggest to use 'ifaces' instead of 'Interfaces' # list the iface info GET /vms/<name>/ifaces/<mac> # attach new iface POST /vms/<name>/ifaces/<mac> {network: <network-id>} # dettach a iface DELETE /vms/<name>/ifaces/<mac>
The best way for user is get the NICS name in guest. such as eth0, eth1.... GET /vms/*name*/Interfaces/eth0 GET /vms/*name*/Interfaces/eth1
But there is a problem, we need get the nic name and mac from guest. and Make a map in kimchi DB. also the nic name may change, we need make the map consistence with guest nic name.
I think it is not needed. Only the mac address should be enough. Just for reference: I also looked at virt-manager and it doesn't display information about nic name, only mac and network name and type.
-- Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center

On 01/10/2014 09:30 PM, Aline Manera wrote:
On 12/30/2013 01:13 AM, Sheldon wrote:
now we have support network get/create/delete/activate/deactivate
Now we need to support the attach/detach/ <https://github.com/kimchi-project/kimchi/wiki/customize-VM#organization-of-sub-resources-and-rest-api-exposition> a Network to a guest. And get the info of Network attached to a guest.
libvirt supports several types of network interfaces: 'bridge','network','user','ethernet','direct','hostdev','mcast', 'server', 'client'
but there is not a unique "name" attribute for "interface" element.(more libvirt network interfaces info <http://libvirt.org/formatdomain.html#elementsNICS>)
That is not good to define our REST API.
But for "network" type resource, there is a "network" attribute of "source" resource. And the value of "network" attribute is the name of network that we defined by /networks POST method.
the "network" type + "network" attribute is unique.
We can define the Network Interfaces like this to support "network" type Interfaces: GET /vms/*name*/Interfaces?type=network&network="default" But this is not RESTFUL.
Maybe We can also name a Network Interface by the Interface mac. The mac is unique. GET /vms/*name*/Interfaces/mac
I think using the mac address is enough for us.
I'd also suggest to use 'ifaces' instead of 'Interfaces'
# list the iface info GET /vms/<name>/ifaces/<mac>
# attach new iface POST /vms/<name>/ifaces/<mac> {network: <network-id>} POST /vms/<name>/ifaces/ {network: <network-id>} ?
# dettach a iface DELETE /vms/<name>/ifaces/<mac>
The best way for user is get the NICS name in guest. such as eth0, eth1.... GET /vms/*name*/Interfaces/eth0 GET /vms/*name*/Interfaces/eth1
But there is a problem, we need get the nic name and mac from guest. and Make a map in kimchi DB. also the nic name may change, we need make the map consistence with guest nic name.
I think it is not needed. Only the mac address should be enough. Just for reference: I also looked at virt-manager and it doesn't display information about nic name, only mac and network name and type.
-- Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center

On 01/13/2014 09:19 AM, Sheldon wrote:
On 01/10/2014 09:30 PM, Aline Manera wrote:
On 12/30/2013 01:13 AM, Sheldon wrote:
now we have support network get/create/delete/activate/deactivate
Now we need to support the attach/detach/ <https://github.com/kimchi-project/kimchi/wiki/customize-VM#organization-of-sub-resources-and-rest-api-exposition> a Network to a guest. And get the info of Network attached to a guest.
libvirt supports several types of network interfaces: 'bridge','network','user','ethernet','direct','hostdev','mcast', 'server', 'client'
but there is not a unique "name" attribute for "interface" element.(more libvirt network interfaces info <http://libvirt.org/formatdomain.html#elementsNICS>)
That is not good to define our REST API.
But for "network" type resource, there is a "network" attribute of "source" resource. And the value of "network" attribute is the name of network that we defined by /networks POST method.
the "network" type + "network" attribute is unique.
We can define the Network Interfaces like this to support "network" type Interfaces: GET /vms/*name*/Interfaces?type=network&network="default" But this is not RESTFUL.
Maybe We can also name a Network Interface by the Interface mac. The mac is unique. GET /vms/*name*/Interfaces/mac
I think using the mac address is enough for us.
I'd also suggest to use 'ifaces' instead of 'Interfaces'
# list the iface info GET /vms/<name>/ifaces/<mac>
# attach new iface POST /vms/<name>/ifaces/<mac> {network: <network-id>} POST /vms/<name>/ifaces/ {network: <network-id>} ?
Yeap
# dettach a iface DELETE /vms/<name>/ifaces/<mac>
The best way for user is get the NICS name in guest. such as eth0, eth1.... GET /vms/*name*/Interfaces/eth0 GET /vms/*name*/Interfaces/eth1
But there is a problem, we need get the nic name and mac from guest. and Make a map in kimchi DB. also the nic name may change, we need make the map consistence with guest nic name.
I think it is not needed. Only the mac address should be enough. Just for reference: I also looked at virt-manager and it doesn't display information about nic name, only mac and network name and type.
-- Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
participants (2)
-
Aline Manera
-
Sheldon