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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
