Jiri Denemark <jdenemar(a)redhat.com> writes:
On Tue, Feb 21, 2017 at 15:38:22 +0100, Milan Zamazal wrote:
> [Starting to move to the development list.]
>
> Milan Zamazal <mzamazal(a)redhat.com> writes:
>
> > Jiri Denemark <jdenemar(a)redhat.com> 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