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.

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(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list