[Engine-devel] [vdsm] [RFC] New Connection Management API

[Yaniv Kaul]

On 01/26/2012 04:21 PM, Juan Hernandez wrote:
> On 01/26/2012 03:01 PM, Adam Litke wrote:
>> On Thu, Jan 26, 2012 at 12:22:42PM +0200, Livnat Peer wrote:
>>> On 25/01/12 23:35, Saggi Mizrahi wrote:
>>>> About the clear all verb.
>>>> No.
>>>> Just loop, find the connections YOU OWN and clean them. Even though you don't want to support multiple clients to VDSM API doesn't mean the engine shouldn't behave like a proper citizen.
>>>> It's the same reason why VDSM tries and not mess system resources it didn't initiate.
>>>
>>> There is a big difference, VDSM living in hybrid mode with other
>>> workload on the host is a valid use case, having more than one
>>> concurrent manager for VDSM is not.
>>> Generating a disconnect request for each connection does not seem like
>>> the right API to me, again think on the simple flow of moving host from
>>> one data center to another, the engine needs to disconnect tall storage
>>> domains (each domain can have couple of connections associated with it).
>>>
>>> I am giving example from the engine use cases as it is the main user of
>>> VDSM ATM but I am sure it will be relevant to any other user of VDSM.
>> I will speak up to represent other potential users of the VDSM API.  My vote is
>> with Saggi here to keep the API simple and have an unmanage call that operates
>> on a single connection only.  Every programming language has looping constructs
>> that make it easy to implement unmanageAll.  Why clog up vdsm's API with an
>> extra function just to avoid writing a 'for' loop?
> A very good reason to have that kind of bulk operations (in general,
> maybe not in this case) is to reduce the number of network round trips
> and thus improve performance. The loop is very easy to write, and very
> expensive to execute.

It's expensive mainly because we do not have a persistent connection 
between VDSM and Engine, and that it's not compressed (with TLS 
compression or internally).
Y.

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel