11:12 p.m.
On 01/08/2014 11:40 AM, Yu Xin Huo wrote:
I see quite valuable comments in previous versions of this patch,
many
thanks for team's discussion.
1. I see the future roadmap of network features.
a) add a vms field in /networks uri to get how many vms are
running on the network.
for this attribute, we tend to tell user how many ip
addresses are allocated and user can sniff something about the basic
workload of the network from it.
this will greatly decrease complexity at client side and
improve performance. it is a quite light-weight field with only
numbers of vms there, nothing unreasonable.
ACK
b) add a parameter named "ip_subnet" to /vms uri to
get the
vms in a certain ip space.
for this parameter, we tend to add some fancy feature to
network.
we can 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.
ACK
so two steps here, for this patch, only handle a), add a vms
attribute to tell how many vms running on a network. let us discuss
details of b) in next sprint as it is an advanced feature.
2. This drives us to think about the way to manage virtualization
environment.
a good perspective.
Currently, we display vm, storage, network... in a quite flat way
there, leave user to check individual attributes to get their
relationships.
I do not think this way is effective at all, I think these things
are tightly connected to construct virtualized computing environment.
So is it possible to manage virtualization by 'environment', in
each 'environment', there are vms, images, storage pool & volumes and
network connecting them.
This is strategic, I would like to listen to team's opinion.
more details.
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", 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.
On 1/7/2014 2:50 PM, shaohef(a)linux.vnet.ibm.com wrote:
> From: ShaoHe Feng <shaohef(a)linux.vnet.ibm.com>
>
> V4 -> V5
> fix typo in subject.
>
> V3 -> V4
> the subject of patch V3 3/3 is wrong.
> fix it.
>
> V2 -> V3
> update mockmodel and test case
>
> V1 -> V2
> set the flags argument of listAllDomains as 0 explicitly.
> For in some distros:
> $ pydoc libvirt.virConnect.listAllDomains
> libvirt.virConnect.listAllDomains = listAllDomains(self, flags) \
> unbound libvirt.virConnect method
>
> And in other distros:
> $ pydoc libvirt.virConnect.listAllDomains
> libvirt.virConnect.listAllDomains = listAllDomains(self, flags=0) \
> unbound libvirt.virConnect method
>
> ShaoHe Feng (3):
> network improvement: add vms field
> network improvement: update mockmodel to support vms field
> network improvement: update test case to support vms field
>
> docs/API.md | 1 +
> src/kimchi/control/networks.py | 1 +
> src/kimchi/mockmodel.py | 9 +++++++++
> src/kimchi/model.py | 15 +++++++++++++++
> tests/test_model.py | 1 +
> tests/test_rest.py | 3 +++
> 6 files changed, 30 insertions(+)
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(???)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center