[libvirt] Determining domain job kind from job stats?
Milan Zamazal
mzamazal at redhat.com
Wed Apr 12 07:36:20 UTC 2017
"Daniel P. Berrange" <berrange at redhat.com> 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
More information about the libvir-list
mailing list