On Tue, Apr 11, 2017 at 09:49:42AM +0200, Jiri Denemark wrote:
On Mon, Apr 10, 2017 at 12:01:43 +0100, Daniel P. Berrange wrote:
On Mon, Apr 10, 2017 at 12:58:09PM +0200, Milan Zamazal wrote:
I looked how the change could be implemented. Could you please help me clarify some things?
- I think a new member should be added to _virDomainJobInfo for the purpose. What would be a good name for it? Maybe "operation"? - Do I need to care about backends other than QEMU? - Jobs are classified by qemuDomainAsyncJob, which is a QEMU specific type. Is it OK to use such structures in virsh-domain.c or is there any additional abstraction needed?
I don't much like the idea of exposing the QEMU job operation names in the public API.
Perhaps we instead need to have the method which starts the job, return an integer "job id" that is then reported against the job, so apps can match them up.
The problem with "job id" is that only the process which started the job would know what it means. Not to mention it would require a lot of API changes.
I think we should just introduce a new virDomainJobSomething enum as
VIR_DOMAIN_JOB_SOMETHING_INCOMING_MIGRATION, VIR_DOMAIN_JOB_SOMETHING_OUTGOING_MIGRATION, VIR_DOMAIN_JOB_SOMETHING_SAVE, VIR_DOMAIN_JOB_SOMETHING_RESTORE, ...
and report it in virDomainGetJobStat (definitely not in _virDomainJobInfo as it would break ABI).
I'm not sure what the best name for "Something" would be. "Operation", "Action", or something else?
IMHO It would be an "Operation", since a single logical operation can involve running multiple actions. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|