From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSSih-0007mO-Uy for qemu-devel@nongnu.org; Mon, 02 Mar 2015 10:57:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSSib-0000VC-Qk for qemu-devel@nongnu.org; Mon, 02 Mar 2015 10:57:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSSiY-0000UK-EF for qemu-devel@nongnu.org; Mon, 02 Mar 2015 10:57:17 -0500 Message-ID: <54F48855.6070307@redhat.com> Date: Mon, 02 Mar 2015 08:57:09 -0700 From: Eric Blake MIME-Version: 1.0 References: <1425017996-6748-1-git-send-email-zhang.zhanghailiang@huawei.com> <54F09FFB.2070008@redhat.com> <20150227170727.GB2570@work-vm> <54F0ACA3.5080105@redhat.com> <54F13157.5000709@huawei.com> In-Reply-To: <54F13157.5000709@huawei.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JCpI2p75Wj8I4VEJwNCSnPPsMPoqfQ9nq" Subject: Re: [Qemu-devel] [PATCH v2] migration: Convert 'status' of MigrationInfo to use an enum type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: zhanghailiang , "Dr. David Alan Gilbert" Cc: hangaohuai@huawei.com, quintela@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, peter.huangpeng@huawei.com, lcapitulino@redhat.com, amit.shah@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JCpI2p75Wj8I4VEJwNCSnPPsMPoqfQ9nq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/27/2015 08:09 PM, zhanghailiang wrote: > On 2015/2/28 1:42, Eric Blake wrote: >> On 02/27/2015 10:07 AM, Dr. David Alan Gilbert wrote: >>>> >>>> Rather than pollute the user-exposed enum with a state that we will >>>> never report, can we come up with some internal-only method for >>>> tracking >>>> cancelling separate from the enum? >>> >>> Well I guess we could just report it; but would that break any >>> external tools? >> >> It might - I seem to recall in the past that when we added a new state= >> string, that at least libvirt choked when encountering the unknown >> string (but I don't recall if it was migration or something else). >=20 > Er, i have tested with returning 'cancelling' to users, and > only when we try to cancel a migration, libvirt sometimes will report := > Migration: [ 69 %]^Cerror: internal error: unexpected migration status > in cancelling. > But the cancelling process is still completed. >=20 > And, yes, it is very rare, depend on the time window. (In my test, i ad= d > a sleep of 5s > to extend the time between cancelling and cancelled.) >=20 >> or if it would still end up resolving nicely (after all, cancelling on= ly >> occurs for a short window before the migration aborts anyway, so it >> might just sort itself out when it finally gets to cancelled). >> >=20 >> On the other hand, we can argue that clients that are unprepared to >> handle new enum states gracefully are broken, and we also have the >> argument that it is okay for a new qemu to require a new libvirt relea= se >> (the other direction is not okay - a new libvirt must not require >=20 > Agreed, upgrade libvirt is reasonable. > So, should i send v3 with exposing 'cancelling'to user, and CC libvirt = ? Yes, that sounds reasonable to me --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --JCpI2p75Wj8I4VEJwNCSnPPsMPoqfQ9nq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEbBAEBCAAGBQJU9IhWAAoJEKeha0olJ0NqfDkH8QF2bxysDOaSR9aCI8gr9Fg+ g26QdfqxOAu+yfxgVdp8HHkDjAEKdZieSSYSWfWr8HEtMqA8sT5l6dwZDMTz7qFx 3V+lSHI/cQ2ur8mg/MeaaPBCj/bENp0p+dbI7hUe+K/3OLJCaWKOA0xsSQvCRfQu c3upU8rY8fbhKQY9cAnYC5zoJMKnttTPQvqapB0XI7GTSOtQ8D9YAqxot9KiBgzW BZBRuV0yp8YxaFYY5qPbdozWjsFvwMjrpUNqSipo8wSbjQNo986TsZS4oruLq/iZ tAQCLlC670Z6cTYp73tCf0P6MOJgGjWbhcHYrUjN1fi3hoUot7BqNGAEhIbZgA== =kNzh -----END PGP SIGNATURE----- --JCpI2p75Wj8I4VEJwNCSnPPsMPoqfQ9nq--