[libvirt] Job Control, Google Summer of Code

[David kiarie]

Success Tucker.

I am also working on snapshot support on the libvirt xenlight driver
as part of GSoC

On Tue, May 20, 2014 at 7:40 PM, Eric Blake <eblake at redhat.com> wrote:
> 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
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list