"Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: > 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. Sounds good. So what's best to do now to move on with the feature? Regards, Milan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
