On 01/08/2014 01: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.
OK.
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.
I am not sure I understood it correctly but we can discuss more later.
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.
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.
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