Jiri Denemark <jdenemar@xxxxxxxxxx> writes: > On Tue, Feb 21, 2017 at 15:38:22 +0100, Milan Zamazal wrote: >> [Starting to move to the development list.] >> >> Milan Zamazal <mzamazal@xxxxxxxxxx> writes: >> >> > Jiri Denemark <jdenemar@xxxxxxxxxx> writes: >> > >> >> On Fri, Feb 17, 2017 at 12:38:24 +0100, Milan Zamazal wrote: >> >>> >> >>> There are basically two problems: >> >>> >> >>> - When the job completion callback is called, I need to distinguish what >> >>> kind of job was it to perform the appropriate actions. It would be >> >>> easier if I knew the job type directly in the callback (no need to >> >>> coordinate anything), but "external" job tracking is also possible. >> >> >> >> An immediate answer would be: "don't rely on the completion callback and >> >> just check the return value of the API which started the job", but I >> >> guess you want it because checking the return value is not possible when >> >> the process which started the job is not running anymore as described >> >> below. >> > >> > Well, avoiding using the completion callback is probably OK for me. >> >> Thinking about it more, it's not very nice: I have to use the callback >> to get the completed job stats (I'm not guaranteed the domain still >> exists on the source host when I ask it for the stats explicitly) *and* >> to track the jobs outside the callback to know whether the callback is >> related to the type of domain jobs I'm going to handle. >> >> Although not absolutely necessary, it would be much nicer if the job >> type was identified in the callback. > > The job completed event uses type parameters so adding a new parameter > describing the just completed job should not be a problem. Great, so all what remains to solve the problem is to add the parameter :-). (And I'd like to have the same info available when a job is still running for reasons already discussed.) 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? - Are there any libvirt-python updates needed or will all the things propagate to it automatically? - I think there are no documentation updates needed to perform manually for this change, right? - Should I be aware of anything else? Thanks, Milan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
