[libvirt] Job Control, Google Summer of Code

[Eric Blake]

On 05/20/2014 09:03 AM, Tucker DiNapoli wrote:
> Hello everyone,
>   My name is Tucker DiNapoli and I'm going to be working on libvirt this
> summer for the google summer of code. My project is to implement job
> control in the storage driver. In order to do that I am first going to
> create a unified api for job control in libvirt (as it is currently
> implemented seperately in both the qemu and libxl drivers). I'm currently
> working on the api for job control and I have some ideas that I'll post on
> the mailing list soon. If anyone has any ideas or requests re job control
> I'd be happy to hear them. I'm on the #virt irc channel as tuckerD, I look
> forward to working on libvrt this summer.

Welcome! I definitely have some ideas on the matter:

https://www.redhat.com/archives/libvir-list/2014-February/msg01128.html

and in notes I've taken from off-list communications:

>> For that matter, we need to overhaul the job support.  Right now,
>> virDomainBlockJob* assumes you can only have one outstanding job at a
>> time, which interferes with the notion of running fleecing from two
>> points in time.  Similarly, there can only be one virDomainGetJobInfo
>> active.  What we really need is a notion of a job id, a way to query the
>> job id most recently created by any existing job-related API, and a way
>> to query job status based on id rather than only the most-recently
>> started job.

I'd _really_ like to see a common notion of a 'job id' that EVERY job
(whether domain-level, like migration; or block-level, like
commit/pull/rebase; or storage-level, like your new proposed storage
jobs) shares a common job namespace.  The job id is a positive integer.
 Existing APIs will have to be retrofitted into the new job id notion;
any action that starts a long-running job that currently returns 0 on
success could be changed to return a positive job id; or we may need a
new API that queries the notion of the 'current job' (the job most
recently started) or even to set the 'current job' to a different job
id.  We'll need new API for querying a job by id, and to be most
portable, we should do job reporting via virTypedParameter
(virDomainGetJobInfo and virDomainGetBlockJobInfo are hardcoded into
returning a struct, so they are non-extensible; virDomainGetJobStats
almost did it right, except that the user has to call it twice, once to
learn how large to allocate, and again to pass in pre-allocated memory -
the ideal API would allocate the memory on a single call).

The fact that many jobs are exclusive (only one domain job at a time,
and only one block job per disk) is currently inherent in the design of
not having a job id; but we eventually WANT to allow parallel jobs.  So
I'm looking forward to reviewing your proposals.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140520/879664a9/attachment-0001.sig>