[libvirt] [PATCH] Increased upper limit on lists of pool names

[Eric Blake]

On 03/15/2012 05:51 AM, Daniel P. Berrange wrote:
> On Thu, Mar 15, 2012 at 06:22:38AM -0500, Jesse Cook wrote:
>> Just to clarify, you would like to see:

I have not actually tried this, but based on my understanding of the RPC
famework, I'd expect:

>>
>> v0.9.10 pre-patch client talk to v0.9.10 patch server

If there are 256 or fewer names, this works as it always did.

If there are more than 256 names, then the server tries to send back
more array elements than the client is prepared to receive - the client
will treat the response as an invalid RPC, and my recollection is that
under these circumstances, the client then forcefully disconnects the
session under the assumption that the server is broken.

To avoid breaking such clients, you'd probably need some way for clients
to warn the server if they are prepared to receive more than the old max
(similar to how we had to add VIR_TYPED_PARAM_STRING_OKAY as a way for
clients to tell the server that they were prepared to handle typed
strings being returned).  Basically, any time you change the RPC to
allow more data to be returned than what was previously possible, the
server should not return that additional data unless the client has
negotiated that it is aware of the additional data.

>> v0.9.10 patch client talk to v0.9.10 pre-patch server

No problem for the client.  The server will never successfully return
more than 256 names.  However, if the client requests more than 256
names, I'm not sure whether the server will silently truncate to 256 or
whether it will return an RPC error because it was unable to provide the
reply.

> 
> And for comparison
> 
>   v0.9.10 pre-patch client talk to v0.9.10 pre-patch server

Should be the same behavior as a v0.9.10-patch client talking to a
pre-patch server - you can't successfully send more than 256 names, but
I'm not sure how the server will react if the client requests too many
names.  Actually, it might be slightly different - the client might
reject the request up front without even contacting the server.

> 
> Obviously for 
> 
>   v0.9.10 patch client talk to v0.9.10 patch server
> 
> I'd expect "just works" :-)

Of course, if both sides are prepared to handle the new RPC protocol, it
should just work.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120315/b89cc16f/attachment-0001.sig>