Re: [libvirt] Job Control, Google Summer of Code

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