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?
Jirka