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.
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.
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
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.
3) libvirt-designer
Just an rough idea to extend functionality. No concrete ideas yet.
4) libvirt-snmp
Drop autogenerated parts of code, so after each MIB addition one doesn't
have to regenerate nearly whole codebase.
What do you guys think?
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list