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).
> > 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. > > And, yes, it is very rare, depend on the time window. (In my test, i add > a sleep of 5s > to extend the time between cancelling and cancelled.) > >> or if it would still end up resolving nicely (after all, cancelling only >> occurs for a short window before the migration aborts anyway, so it >> might just sort itself out when it finally gets to cancelled). >> > >> 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 release >> (the other direction is not okay - a new libvirt must not require > > Agreed, upgrade libvirt is reasonable. > So, should i send v3 with exposing 'cancelling'to user, and CC libvirt ? Yes, that sounds reasonable to me -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature