On Fri, Feb 8, 2013 at 9:20 AM, Osier Yang <jyang@xxxxxxxxxx> wrote: > On 2013年02月08日 16:07, Michal Privoznik wrote: >> >> On 07.02.2013 16:19, Stefan Hajnoczi wrote: >>> >>> I have created the Google Summer of Code 2013 wiki page where you can >>> add project ideas: >>> >>> http://wiki.qemu.org/Google_Summer_of_Code_2013 >>> >>> Please add project ideas you are willing to mentor. If you have an >>> idea but cannot mentor this year, feel free to add it but please try >>> to find a mentor for it. >>> >>> If you want to be a mentor, please see >>> http://wiki.qemu.org/Google_Summer_of_Code_2013#Information_for_mentors. >>> >> >> I've got some ideas, but I just don't know it their size is sufficient. >> But IIUC, there are 3 levels (beginner, intermediate and advanced), so >> hopefully the ideas can land in one of them. There should be enough work to do a 12 week project. >> 1) Virsh auto completion >> >> This is something I think will be very useful for nearly all libvirt >> users. I've proposed the idea a while ago and my sense is we have some >> consensus how this should work. But I am afraid this is more mechanical >> work than real programming one. I'm not sure how involved this will be. Perhaps it can be combined with related tasks to expand the scope to a 12 week project. >> 2) Storage driver jobs >> >> This is slightly advanced one. Currently, there's no way how to cancel >> an ongoing storage driver job. For instance, libvirt starts wiping huge >> file, however user at some point decides to cancel it. And for now, >> there is no way of doing that (other than just killing 'scub' binary to >> which we offload the work to). Things get complicated, if we want to >> share job acquiring code with qemu driver, and report progress (if >> operation itself is capable of it). > > > Deserved. We lost this for long time, I filed the bug to track it > before, but have not get time to do it yet: > > https://bugzilla.redhat.com/show_bug.cgi?id=830676 I agree, that storage driver job cancellation and progress reporting is a good project idea. The scope fits and it is a useful feature to support. They can start with scrub where libvirt has 100% control. Then, depending on their level of skill and time remaining, they can tackle the QEMU commands. The next step is to find concrete problems for the project description. This will allow students to begin looking into the libvirt code so they can come up with a plan for their work. It's best if you can point out the virsh commands or virt-manager methods that current block or are uninterruptible. > Except this, glusterfs support is another thing I see we need to > do sooner or later. I have ever had a glance at the gluterfs, as > far as I see, setting up the basic is not complex, but fully support > is an advanced job. Not sure how much work is necessary here but it could also be a good project idea for GSoC. Stefan -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list