[Kimchi-devel] [PATCH V5 0/3] network improvment: add vms field

[Aline Manera]

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 at linux.vnet.ibm.com wrote:
>> From: ShaoHe Feng <shaohef at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>