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

Jesse Cook crashenx at gmail.com
Fri Mar 16 02:26:07 UTC 2012


On Thu, Mar 15, 2012 at 9:43 AM, Eric Blake <eblake at redhat.com> wrote:
> 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
>

v0.9.10 client did not want to play nicely with the v0.9.10 server via
qemu+ssh.  I got frustrated and just tried running the test from a
client running an older version of libvirt.  When connecting to
v0.9.10, it behaved the same way the pre-patched did in my cover
letter.  I don't have full test results because of the communication
errors I was getting. I'll try to either figure it out tomorrow or
just use the older version as the client (pre-patch and patch).

-- Jesse




More information about the libvir-list mailing list