On Fri, Mar 16, 2012 at 7:35 AM, Eric Blake wrote:
> On 03/15/2012 08:26 PM, Jesse Cook wrote:
>>
>> 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 con
On 03/15/2012 08:26 PM, Jesse Cook wrote:
>
> 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-pat
On Thu, Mar 15, 2012 at 9:43 AM, Eric Blake 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,
On Thu, Mar 15, 2012 at 1:10 PM, Eric Blake wrote:
> On 03/15/2012 11:48 AM, Daniel P. Berrange wrote:
>> Using the sequence of RPC calls to iterate over this is only
>> addressing that second part of memory usage. So I'm not really
>> feeling that's a huge win, given the complexity it introduces.
On 03/15/2012 11:48 AM, Daniel P. Berrange wrote:
> Using the sequence of RPC calls to iterate over this is only
> addressing that second part of memory usage. So I'm not really
> feeling that's a huge win, given the complexity it introduces.
>
> I'm inclined to say, that if people are creating se
On Thu, Mar 15, 2012 at 10:47:25AM -0600, Eric Blake wrote:
> On 03/15/2012 08:31 AM, Eric Blake wrote:
> > It may also be worth considering the addition of _just_ a new ranged RPC
> > call, but no new public API, by making the public API smart enough to
> > automatically call the ranged RPC multip
On 03/15/2012 11:30 AM, Jesse Cook wrote:
>> At any rate, I don't have code to back this up, but it's certainly food
>> for thought on whether it makes sense to try and enhance our use of RPC
>> to support transactions without also having to add new public API.
>>
>
> Your solution seems reasonab
On Thu, Mar 15, 2012 at 11:47 AM, Eric Blake wrote:
> On 03/15/2012 08:31 AM, Eric Blake wrote:
>> It may also be worth considering the addition of _just_ a new ranged RPC
>> call, but no new public API, by making the public API smart enough to
>> automatically call the ranged RPC multiple times t
On 03/15/2012 08:31 AM, Eric Blake wrote:
> It may also be worth considering the addition of _just_ a new ranged RPC
> call, but no new public API, by making the public API smart enough to
> automatically call the ranged RPC multiple times to build up a single
> return to the user. After all, if w
On 03/15/2012 08:41 AM, Daniel P. Berrange wrote:
> On Thu, Mar 15, 2012 at 08:31:32AM -0600, Eric Blake wrote:
>> On 03/14/2012 07:42 PM, Jesse J. Cook wrote:
>>> 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits)
>>> is a
>>> more appropriate limit and should be sufficient
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
On Thu, Mar 15, 2012 at 08:31:32AM -0600, Eric Blake wrote:
> On 03/14/2012 07:42 PM, Jesse J. Cook wrote:
> > 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits)
> > is a
> > more appropriate limit and should be sufficient. You are more likely to run
> > into other system li
On 03/14/2012 07:42 PM, Jesse J. Cook wrote:
> 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits) is a
> more appropriate limit and should be sufficient. You are more likely to run
> into other system limitations first, such as the 31998 inode link limit on
> ext3.
> ---
> s
Just to clarify, you would like to see:
v0.9.10 pre-patch client talk to v0.9.10 patch server
v0.9.10 patch client talk to v0.9.10 pre-patch server
Would the test code I used in my cover letter be sufficient? If so, I
could probably test this fairly easily and quickly today.
On Thu, Mar 15, 201
On Thu, Mar 15, 2012 at 5:14 AM, Daniel P. Berrange wrote:
>
> On Wed, Mar 14, 2012 at 08:42:35PM -0500, Jesse J. Cook wrote:
> > 256 (8 bits) is insufficient for large scale deployments. 65536 (16
> > bits) is a
> > more appropriate limit and should be sufficient. You are more likely to
> > run
>
On Thu, Mar 15, 2012 at 3:42 AM, Osier Yang wrote:
> On 03/15/2012 09:42 AM, Jesse J. Cook wrote:
>>
>> 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits)
>> is a
>> more appropriate limit and should be sufficient. You are more likely to
>> run
>> into other system limitatio
On Thu, Mar 15, 2012 at 06:22:38AM -0500, Jesse Cook wrote:
> Just to clarify, you would like to see:
>
> v0.9.10 pre-patch client talk to v0.9.10 patch server
> v0.9.10 patch client talk to v0.9.10 pre-patch server
And for comparison
v0.9.10 pre-patch client talk to v0.9.10 pre-patch server
On Wed, Mar 14, 2012 at 08:42:35PM -0500, Jesse J. Cook wrote:
> 256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits) is a
> more appropriate limit and should be sufficient. You are more likely to run
> into other system limitations first, such as the 31998 inode link limit on
On 03/15/2012 09:42 AM, Jesse J. Cook wrote:
256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits) is a
more appropriate limit and should be sufficient. You are more likely to run
into other system limitations first, such as the 31998 inode link limit on
ext3.
---
src/remote
256 (8 bits) is insufficient for large scale deployments. 65536 (16 bits) is a
more appropriate limit and should be sufficient. You are more likely to run
into other system limitations first, such as the 31998 inode link limit on
ext3.
---
src/remote/remote_protocol.x |2 +-
1 files changed, 1
20 matches
Mail list logo
