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-de...@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel
