[libvirt] [PATCH 5/6] allow non-zero success values from a domain's MigratePerform

Daniel P. Berrange berrange at redhat.com
Wed Oct 7 13:49:14 UTC 2009


On Wed, Oct 07, 2009 at 03:01:14PM +0200, Daniel Veillard wrote:
> On Thu, Oct 01, 2009 at 08:18:32PM +0200, Paolo Bonzini wrote:
> > A return code of say 1 from Perform is currently considered an error,
> > but it could also be passed simply to Finish.  This makes the v2
> > protocol much more powerful.
> > 
> > * src/remote/remote_protocol.x (remote_domain_migrate_perform_ret): New.
> > * src/qemu/qemu_driver.c (qemudDomainMigrateFinish2): Succeed if
> > qemudDomainMigratePerform returned a non-zero but positive value.
> > 
> > * daemon/remote.c (remoteDispatchDomainMigratePerform): Adjust for
> > remote_domain_migrate_perform_ret.
> > * daemon/remote_dispatch_prototypes.h: Regenerate.
> > * daemon/remote_dispatch_ret.h: Regenerate.
> > * daemon/remote_dispatch_table.h: Regenerate.
> > 
> > * src/remote/remote_driver.c (remoteDomainMigratePerform): Adjust for
> > remote_domain_migrate_perform_ret.
> > * src/remote/remote_protocol.c: Regenerate.
> > * src/remote/remote_protocol.h: Regenerate.
> 
>   Sounds fine by me, but I wonder about the change of semantic for
>   client server not at the same version level. Could you explain what
> might happen in those case ?

In the case of old server and new client, the client should get a RPC
error when trying to re-serialize the reply, because the data packet
it will be getting back from the server will be too small (ie missing
the new field this patch adds). 

The RPC protocol should be considered ABI, and no existing methods 
ever changed, only new methods can be added so NACK to this patch

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list