[Kimchi-devel] [PATCH V4 1/3] network improvment: add vms field
Sheldon
shaohef at linux.vnet.ibm.com
Wed Jan 8 04:56:48 UTC 2014
On 01/08/2014 02:24 AM, Aline Manera wrote:
> On 01/07/2014 06:27 AM, Royce Lv wrote:
>> On 2014年01月06日 16:49, shaohef at linux.vnet.ibm.com wrote:
>>> From: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>>
>>> Add vms field for network GET method
>>> update API.md
>>>
>>> add a function to get all vms attach to a network
>>> update model
>>>
>>> add vms field for Network Resource property
>>> update controller
>>>
>>> Now get the info of default network:
>>> $ curl -u <user>:<password> -H 'Content-type: application/json' -H
>>> 'Accept:
>>> application/json' -X GET http://localhost:8000/networks/default
>>> {
>>> "subnet":"192.168.122.0/24",
>>> "connection":"nat",
>>> "name":"default",
>>> "autostart":true,
>>> "state":"active",
>>> "interface":"virbr0",
>>> "dhcp":{
>>> "start":"192.168.122.2",
>>> "end":"192.168.122.254"
>>> },
>>> "vms":[
>>> "rhel6",
>>> "opensuse12"
>>> ]
>>> }
>>> we can see, there are two vms attched to this network
>>>
>>> Signed-off-by: ShaoHe Feng <shaohef at linux.vnet.ibm.com>
>>> ---
>>> docs/API.md | 1 +
>>> src/kimchi/control/networks.py | 1 +
>>> src/kimchi/model.py | 15 +++++++++++++++
>>> 3 files changed, 17 insertions(+)
>>>
>>> diff --git a/docs/API.md b/docs/API.md
>>> index 0013e86..32045ac 100644
>>> --- a/docs/API.md
>>> +++ b/docs/API.md
>>> @@ -364,6 +364,7 @@ A interface represents available interface on host.
>>> * active: The Network is ready for use
>>> * inactive: The Network is not available
>>> * autostart: Network autostart onboot
>>> + * vms: all vms attached to this network
>>> * subnet: Network segment in slash-separated format with ip
>>> address and prefix
>>> * dhcp: DHCP services on the virtual network is enabled.
>>> * start: start boundary of a pool of addresses to be
>>> provided to DHCP clients.
>>> diff --git a/src/kimchi/control/networks.py
>>> b/src/kimchi/control/networks.py
>>> index ad95d69..f3f0b41 100644
>>> --- a/src/kimchi/control/networks.py
>>> +++ b/src/kimchi/control/networks.py
>>> @@ -40,6 +40,7 @@ class Network(Resource):
>>> @property
>>> def data(self):
>>> return {'name': self.ident,
>>> + 'vms': self.info['vms'],
>> Shuming suggested to use /vms?network='net1' to query vm attatched to
>> a network instead of using /networks/net1/vms
>> Personally, previous URI is clearer and also can be integrated to vm
>> query.
>> I'd like we have some discussion with guys about which URL is to use.
>
> I also prefer to use /vms?network='net1' to query which vms are using
> network 'net1'
yes.
this patch set is the first step.
/vms?network='net1' is the next step.
let us discuss details of the next step in next sprint as it is an
advanced feature.
But we will know the network is not a VM's attribute, it is just a VM's
interface kind.
Not sure it is good as a query param.
step 1:
I have discussed with Yu Xin before. And at the beginning, Yu Xin and I
think just need to show the numbers of vms.
it is a quite light-weight field with only numbers of vms there.
This is the first UI design of network. but for let last release,
backend do not support VMS numbers, so yuxing remove the it.
--------------------------------------------------------------------------------------------------------------------------------
| Network Name | VMS | State | Network Type | Interface |
Address Space | Actions |
--------------------------------------------------------------------------------------------------------------------------------
| default | 254 | o | NAT | virbr |
192.168.122.0/24 | Actions |
--------------------------------------------------------------------------------------------------------------------------------
| net1 | 0 | o | NAT | virbr |
192.168.122.0/24 | Actions |
--------------------------------------------------------------------------------------------------------------------------------
The number of vms is a quite intuitive view of the network environment
and user can do some convenient operation directly.
For example, if a user wants to delete a network, it is easy to do his
choice by checking the number of this network.
The vms of net1 is "0", user can delete this network safely.
Also the vms of default is "254", if user just can choose net1 attached
to his VM.
Also a VMs number greatly decrease complexity at client side and improve
performance.
After add this vms muber filed, UI can just get /networks once to
finish network web page.
step 2:
we will draw a network topology with a switch in center and vms around
with all available information(name, interface, ip address...) of vm
that is helpful.
by this way, user can have a quite intuitive view of the network
environment and do some convenient operation directly there.
--------- --------- --------- ---------
| vm1 | | vm2 | | vm3 | | vm4|
--------- --------- --------- ---------
| | | |
| | | |
----------------------------------------------------------------
| |
| network1 |
| |
----------------------------------------------------------------
| | | |
| | | |
--------- --------- --------- ---------
| vm5 | | vm6 | | vm7 | | vm8|
--------- --------- --------- ---------
And the user click the vm5, the details will display:
----------------------------------------------------------------
| name | CPUS | memory | status | ... |
----------------------------------------------------------------
| VM1 | 1 | 1G | o | ... |
----------------------------------------------------------------
summary:
we can design our URL by:
a)
1. get the VMS numbers and network topology by:
get /networks/
[
{''net1": {bridge: brg1, vms: [vm1, vm2]},
{''net2": {bridge: brg2, vms: [vm3, vm4, vm5]}
]
The numbers field is: len(net1.vms)
The network topology is: net1.vms
2. get the vms info
get /vms/vm1
get /vms/vm2
b)get the VMS numbers
1.
get /networks/
[
{''net1": {bridge: brg1, vms: 2},
{''net2": {bridge: brg2, vms: 3}
]
2. get the network topology and vms info:
/vms?network='net1'
[
"vm1": {"CPUS": 1, "memory": 1G, "status": "running"},
"vm2": {"CPUS": 1, "memory": 1G, "status": "running"},
]
the network topology is net1.keys()
/vms?network='net2'
[
"vm3": {"CPUS": 1, "memory": 1G, "status": "running"},
"vm4": {"CPUS": 1, "memory": 1G, "status": "running"},
"vm5": {"CPUS": 1, "memory": 1G, "status": "running"},
]
the network topology is net2.keys()
But we will know the network is not a VM's attribute, it is just a VM's
interface kind.
>
>>
>>> 'autostart': self.info['autostart'],
>>> 'connection': self.info['connection'],
>>> 'interface': self.info['interface'],
>>> diff --git a/src/kimchi/model.py b/src/kimchi/model.py
>>> index a21fcf7..3e61390 100644
>>> --- a/src/kimchi/model.py
>>> +++ b/src/kimchi/model.py
>>> @@ -547,6 +547,11 @@ class Model(object):
>>> xpath = "/domain/devices/disk[@device='disk']/source/@file"
>>> return xmlutils.xpath_get_text(xml, xpath)
>>>
>>> + def _vm_get_networks(self, dom):
>>> + xml = dom.XMLDesc(0)
>>> + xpath =
>>> "/domain/devices/interface[@type='network']/source/@network"
>>> + return xmlutils.xpath_get_text(xml, xpath)
>>> +
>>> def vm_delete(self, name):
>>> if self._vm_exists(name):
>>> conn = self.conn.get()
>>> @@ -859,6 +864,15 @@ class Model(object):
>>> conn = self.conn.get()
>>> return sorted(conn.listNetworks() +
>>> conn.listDefinedNetworks())
>>>
>>> + def _get_vms_attach_to_a_network(self, network):
>>> + vms = []
>>> + conn = self.conn.get()
>>> + for dom in conn.listAllDomains(0):
>>> + networks = self._vm_get_networks(dom)
>>> + if network in networks:
>>> + vms.append(dom.name())
>>> + return vms
>>> +
>>> def network_lookup(self, name):
>>> network = self._get_network(name)
>>> xml = network.XMLDesc(0)
>>> @@ -887,6 +901,7 @@ class Model(object):
>>> 'interface': interface,
>>> 'subnet': subnet,
>>> 'dhcp': dhcp,
>>> + 'vms': self._get_vms_attach_to_a_network(name),
>>> 'autostart': network.autostart() == 1,
>>> 'state': network.isActive() and "active" or
>>> "inactive"}
>>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140108/db070959/attachment.html>
More information about the Kimchi-devel
mailing list