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).

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

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.

On 10/04/13 21:13, harryxiyou wrote: > On Fri, Feb 8, 2013 at 4:07 PM, Michal Privoznik > <mprivozn(a)redhat.com&gt; 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. >> > Hi all, > > I've also got some ideas like following for GSOC 2013. > > Storage driver jobs. > > Currently, there is no Libvirt storage API to rename storage volume, > storage pool, snapshot, etc. There is also no Libvirt API to move > volume from one pool to another using libvirt API. Possibly those > pools could have different backend (lvm, dir, ...). So i wanna finish > these jobs for Libvirt during GSOC 2013. See following in details. > > > 1, Rename storage volume. I will develop ' virsh vol-rename xxx' > option for virsh tool. > > 2, Rename storage pool. I will develop 'virsh pool-rename xxx' > option for virsh tool. > > 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' > option for virsh tool. Not sure if you planned to request separate projects for these, but I don't think it's deserved for separate projects. They can be just one project, as the work need to do for them is similar. And not restricted to storage stuffs, if renaming API makes sense for storage volume, it makes sense for all other objects too, e.g. domain/network/interface/ nwfilter/secret/pool. What I'm thinking about is, the renaming is easy to implement for inactive objects, but for active ones, it's hard, even not possible, such as for a active domain, the domain name is refered by various places, if you change that, it will produce a big mess. > 4, Move volume from one pool to another. I will develop 'virsh > vol-move xxx' > option for virsh tool. Not sure it's deserved, the existing command create-vol-as/vol-clone can

actually copy the volume from another pool. And after that, you can just remove the original volume. Perhaps having a virsh command to wrapper the the two APIs together is enough. > > Well, currently, these are just good ideas for Libvirt GSOC 2013. I will > give detail design plan for these stuffs according to the workflow of > GSOC. > Could anyone give me some suggestions? > Thanks very much in advance. > > > > -- > Thanks > Harry Wei -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Hi all, I've also got some ideas like following for GSOC 2013. Storage driver jobs. Currently, there is no Libvirt storage API to rename storage volume, storage pool, snapshot, etc. There is also no Libvirt API to move volume from one pool to another using libvirt API. Possibly those pools could have different backend (lvm, dir, ...). So i wanna finish these jobs for Libvirt during GSOC 2013. See following in details. 1, Rename storage volume. I will develop ' virsh vol-rename xxx' option for virsh tool. 2, Rename storage pool. I will develop 'virsh pool-rename xxx' option for virsh tool. 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' option for virsh tool.

4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' option for virsh tool.

Well, currently, these are just good ideas for Libvirt GSOC 2013. I will give detail design plan for these stuffs according to the workflow of GSOC. Could anyone give me some suggestions? Thanks very much in advance.

I am not sure we want *rename virsh commands. Not only for storage, but in general. And even if we do want these, they don't require a new API. They can be implemented with simple vir*GetXML(); vir*Define(); vir*Undefine();

> > 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' > option for virsh tool. This one makes more sense, however I am worried about difficulty a bit. A GSoC project should take 3 months for a student to complete. This is something that even unexperienced user can accomplish in less than a month.

On 10.04.2013 15:13, harryxiyou wrote: > > Hi all, > > I've also got some ideas like following for GSOC 2013. > > Storage driver jobs. > > Currently, there is no Libvirt storage API to rename storage volume, > storage pool, snapshot, etc. There is also no Libvirt API to move > volume from one pool to another using libvirt API. Possibly those > pools could have different backend (lvm, dir, ...). So i wanna finish > these jobs for Libvirt during GSOC 2013. See following in details. > > > 1, Rename storage volume. I will develop ' virsh vol-rename xxx' > option for virsh tool. > > 2, Rename storage pool. I will develop 'virsh pool-rename xxx' > option for virsh tool. > > 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' > option for virsh tool. I am not sure we want *rename virsh commands. Not only for storage, but in general. And even if we do want these, they don't require a new API. They can be implemented with simple vir*GetXML(); vir*Define(); vir*Undefine();

> > 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' > option for virsh tool. This one makes more sense, however I am worried about difficulty a bit. A GSoC project should take 3 months for a student to complete. This is something that even unexperienced user can accomplish in less than a month.

Michal said earlier that virsh vol-move seemed too small a task. Do you think that these 4 tasks together merit a 12-week project?

On Fri, Apr 12, 2013 at 11:47 PM, harryxiyou <harryxiyou(a)gmail.com&gt; wrote: > On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: > [...] >> Michal said earlier that virsh vol-move seemed too small a task. >> >> Do you think that these 4 tasks together merit a 12-week project? >> > > Yes, these 4 tasks should be a whole project which may merit > almost a 12-week project. Like danpb and Osier said *rename jobs > may be realized more Libvirt interfaces. > Sorry, i just considered stefan wannted to ask my suggestions :-/

On Fri, Apr 12, 2013 at 11:57 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: [...] > Right, I'm trying to check with danpb, mprivozn, eblake, and osier > whether these tasks are worthy of a 12-week project. > > There needs to be agreement here before we can add this as a project > idea to the GSoC wiki page. > Okay, thanks. If these 4 jobs are thought less than 12-week project. I suggest we can also add following ideas into this project. The capability support for storage driver (like virsh capabilities for the hypervisor drivers, e.g. what pool types it supports, what volume types each pool type supports, even may what operations/APIs the pool type support, ...etc).

The bug has been reported here https://bugzilla.redhat.com/show_bug.cgi?id=461931

On 13/04/13 00:05, harryxiyou wrote: > > On Fri, Apr 12, 2013 at 11:57 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; > wrote: > [...] >> >> Right, I'm trying to check with danpb, mprivozn, eblake, and osier >> whether these tasks are worthy of a 12-week project. >> >> There needs to be agreement here before we can add this as a project >> idea to the GSoC wiki page. >> > Okay, thanks. If these 4 jobs are thought less than 12-week project. I > suggest > we can also add following ideas into this project. > > The capability support for storage driver (like virsh capabilities for the > hypervisor drivers, e.g. what pool types it supports, what volume types > each pool type supports, even may what operations/APIs the pool type > support, ...etc). Deserved, but at beginner level too. > > The bug has been reported here > https://bugzilla.redhat.com/show_bug.cgi?id=461931 > Regardless of the GSoC, you already found out a bunch of stuffs which we forgot in the corner for a long. If you are interested in contributing to libvirt, enjoy hacking...

On 12/04/13 23:57, Stefan Hajnoczi wrote: > On Fri, Apr 12, 2013 at 5:56 PM, harryxiyou <harryxiyou(a)gmail.com&gt; > wrote: >> On Fri, Apr 12, 2013 at 11:47 PM, harryxiyou <harryxiyou(a)gmail.com&gt; >> wrote: >>> On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi >>> <stefanha(a)gmail.com&gt; wrote: >>> [...] >>>> Michal said earlier that virsh vol-move seemed too small a task. Yes, a new virsh command wrapper existing APIs is good enough. >>>> >>>> Do you think that these 4 tasks together merit a 12-week project? >>>> >>> Yes, these 4 tasks should be a whole project which may merit >>> almost a 12-week project. Like danpb and Osier said *rename jobs >>> may be realized more Libvirt interfaces. >>> >> Sorry, i just considered stefan wannted to ask my suggestions :-/ > Right, I'm trying to check with danpb, mprivozn, eblake, and osier > whether these tasks are worthy of a 12-week project. As said before, It's hard to implement the renaming for active objects, even not possible or deserved. For inactive objects, the way to implement it for all the objects is just similar and mechanical, but per we already have a project to introduce an API to query domain IP address, having another project to introduce other APIs for beginner makes sense too. Though It should be simpler than the one to query domain IP address, it needs mechanical work time.

> > There needs to be agreement here before we can add this as a project > idea to the GSoC wiki page. > > Stefan > > -- > libvir-list mailing list > libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: > On Fri, Apr 12, 2013 at 08:34:18AM +0200, Michal Privoznik wrote: >> On 10.04.2013 15:13, harryxiyou wrote: >> > >> > Hi all, >> > >> > I've also got some ideas like following for GSOC 2013. >> > >> > Storage driver jobs. >> > >> > Currently, there is no Libvirt storage API to rename storage volume, >> > storage pool, snapshot, etc. There is also no Libvirt API to move >> > volume from one pool to another using libvirt API. Possibly those >> > pools could have different backend (lvm, dir, ...). So i wanna finish >> > these jobs for Libvirt during GSOC 2013. See following in details. >> > >> > >> > 1, Rename storage volume. I will develop ' virsh vol-rename xxx' >> > option for virsh tool. >> > >> > 2, Rename storage pool. I will develop 'virsh pool-rename xxx' >> > option for virsh tool. >> > >> > 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' >> > option for virsh tool. >> >> I am not sure we want *rename virsh commands. Not only for storage, but >> in general. And even if we do want these, they don't require a new API. >> They can be implemented with simple vir*GetXML(); vir*Define(); >> vir*Undefine(); > > Actually I disagree - I think you want explicit APIs for renames, so that > it can be done atomically / with minimal risk of failure halfway. > >> > >> > 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' >> > option for virsh tool. >> >> This one makes more sense, however I am worried about difficulty a bit. >> A GSoC project should take 3 months for a student to complete. This is >> something that even unexperienced user can accomplish in less than a month. > > Isn't all the libvirt functionality for this already existing? it it > is basically just virStorageVolCreateFrom(...original vol) and then > delete the original volume. Michal said earlier that virsh vol-move seemed too small a task. Do you think that these 4 tasks together merit a 12-week project?

On Mon, Apr 15, 2013 at 4:43 AM, harryxiyou <harryxiyou(a)gmail.com&gt; wrote: > On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: >> On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange >> <berrange(a)redhat.com&gt; wrote: >>> On Fri, Apr 12, 2013 at 08:34:18AM +0200, Michal Privoznik wrote: >>>> On 10.04.2013 15:13, harryxiyou wrote: >>>>> Hi all, >>>>> >>>>> I've also got some ideas like following for GSOC 2013. >>>>> >>>>> Storage driver jobs. >>>>> >>>>> Currently, there is no Libvirt storage API to rename storage volume, >>>>> storage pool, snapshot, etc. There is also no Libvirt API to move >>>>> volume from one pool to another using libvirt API. Possibly those >>>>> pools could have different backend (lvm, dir, ...). So i wanna finish >>>>> these jobs for Libvirt during GSOC 2013. See following in details. >>>>> >>>>> >>>>> 1, Rename storage volume. I will develop ' virsh vol-rename xxx' >>>>> option for virsh tool. >>>>> >>>>> 2, Rename storage pool. I will develop 'virsh pool-rename xxx' >>>>> option for virsh tool. >>>>> >>>>> 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' >>>>> option for virsh tool. >>>> I am not sure we want *rename virsh commands. Not only for storage, but >>>> in general. And even if we do want these, they don't require a new API. >>>> They can be implemented with simple vir*GetXML(); vir*Define(); >>>> vir*Undefine(); >>> Actually I disagree - I think you want explicit APIs for renames, so that >>> it can be done atomically / with minimal risk of failure halfway. >>> >>>>> 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' >>>>> option for virsh tool. >>>> This one makes more sense, however I am worried about difficulty a bit. >>>> A GSoC project should take 3 months for a student to complete. This is >>>> something that even unexperienced user can accomplish in less than a month. >>> Isn't all the libvirt functionality for this already existing? it it >>> is basically just virStorageVolCreateFrom(...original vol) and then >>> delete the original volume. >> Michal said earlier that virsh vol-move seemed too small a task. >> >> Do you think that these 4 tasks together merit a 12-week project? >> > Let me give a summary about my ideas for Libvirt of GSOC 2013. > > Libvirt storage jobs. > > This project includes renaming storage volume(storage pool, snapshot,etc), > moving volume from one pool to another, the capability support for storage > driver (like virsh capabilities for the hypervisor drivers, e.g. what pool types > it supports, what volume types each pool type supports, even may what > operations/APIs the pool type support, ...etc).

Thanks for posting a short summary. Can an active libvirt developer please confirm that this project idea has a reasonable scope for 12 weeks and that they are willing to mentor this project idea? Thanks, Stefan

On 15.04.2013 04:43, harryxiyou wrote: > On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: >> On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange >> <berrange(a)redhat.com&gt; wrote: >>> On Fri, Apr 12, 2013 at 08:34:18AM +0200, Michal Privoznik wrote: >>>> On 10.04.2013 15:13, harryxiyou wrote: >>>>> Hi all, >>>>> >>>>> I've also got some ideas like following for GSOC 2013. >>>>> >>>>> Storage driver jobs. >>>>> >>>>> Currently, there is no Libvirt storage API to rename storage volume, >>>>> storage pool, snapshot, etc. There is also no Libvirt API to move >>>>> volume from one pool to another using libvirt API. Possibly those >>>>> pools could have different backend (lvm, dir, ...). So i wanna finish >>>>> these jobs for Libvirt during GSOC 2013. See following in details. >>>>> >>>>> >>>>> 1, Rename storage volume. I will develop ' virsh vol-rename xxx' >>>>> option for virsh tool. >>>>> >>>>> 2, Rename storage pool. I will develop 'virsh pool-rename xxx' >>>>> option for virsh tool. >>>>> >>>>> 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' >>>>> option for virsh tool. >>>> I am not sure we want *rename virsh commands. Not only for storage, but >>>> in general. And even if we do want these, they don't require a new API. >>>> They can be implemented with simple vir*GetXML(); vir*Define(); >>>> vir*Undefine(); >>> Actually I disagree - I think you want explicit APIs for renames, so that >>> it can be done atomically / with minimal risk of failure halfway. >>> >>>>> 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' >>>>> option for virsh tool. >>>> This one makes more sense, however I am worried about difficulty a bit. >>>> A GSoC project should take 3 months for a student to complete. This is >>>> something that even unexperienced user can accomplish in less than a month. >>> Isn't all the libvirt functionality for this already existing? it it >>> is basically just virStorageVolCreateFrom(...original vol) and then >>> delete the original volume. >> Michal said earlier that virsh vol-move seemed too small a task. >> >> Do you think that these 4 tasks together merit a 12-week project? >> > Let me give a summary about my ideas for Libvirt of GSOC 2013. > > Libvirt storage jobs. > > This project includes renaming storage volume(storage pool, snapshot,etc), > moving volume from one pool to another, the capability support for storage > driver (like virsh capabilities for the hypervisor drivers, e.g. what pool types > it supports, what volume types each pool type supports, even may what > operations/APIs the pool type support, ...etc). > > If these ones(or portions of them) are deserved to do, we should add them > to our wiki of GSOC 2013. Students will submit their applications for these > ideas at April 22nd. Could anyone please review these ideas(or portions > of them)? Thanks very much in advance. > Makes sense. However, I would drop renaming limitation just for volumes. At least not specifically say in description it's just a 'volume renaming'. This as advantage that we are more flexible and if student is doing good, he/she can introduce renaming to other libvirt objects as well. If he/she doesn't have so much time, doing renaming just for volumes is fine. Just a side note, I am still not huge fan of introducing a special API for this renaming. Doing it in virsh makes sense, however introducing a new API seems like overkill to me. I mean, if mgmt application has 2 threads fighting over one domain, it has to already have a mutual exclusion procedure. If there are no such threads, then we are safe per se. But if we are ever going to have a rename API, it's gonna be hard time for everyone. We would have to move files (e.g. associated snapshots, monitor socket, logs, etc) and what if we fail somewhere in the middle of the process. We would have to perform a rollback.

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: > On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange > <berrange(a)redhat.com&gt; wrote: >> On Fri, Apr 12, 2013 at 08:34:18AM +0200, Michal Privoznik wrote: >>> On 10.04.2013 15:13, harryxiyou wrote: >>> > >>> > Hi all, >>> > >>> > I've also got some ideas like following for GSOC 2013. >>> > >>> > Storage driver jobs. >>> > >>> > Currently, there is no Libvirt storage API to rename storage volume, >>> > storage pool, snapshot, etc. There is also no Libvirt API to move >>> > volume from one pool to another using libvirt API. Possibly those >>> > pools could have different backend (lvm, dir, ...). So i wanna finish >>> > these jobs for Libvirt during GSOC 2013. See following in details. >>> > >>> > >>> > 1, Rename storage volume. I will develop ' virsh vol-rename xxx' >>> > option for virsh tool. >>> > >>> > 2, Rename storage pool. I will develop 'virsh pool-rename xxx' >>> > option for virsh tool. >>> > >>> > 3, Rename snapshot. I will develop 'virsh snapshot-rename xxx' >>> > option for virsh tool. >>> >>> I am not sure we want *rename virsh commands. Not only for storage, but >>> in general. And even if we do want these, they don't require a new API. >>> They can be implemented with simple vir*GetXML(); vir*Define(); >>> vir*Undefine(); >> >> Actually I disagree - I think you want explicit APIs for renames, so that >> it can be done atomically / with minimal risk of failure halfway. >> >>> > >>> > 4, Move volume from one pool to another. I will develop 'virsh vol-move xxx' >>> > option for virsh tool. >>> >>> This one makes more sense, however I am worried about difficulty a bit. >>> A GSoC project should take 3 months for a student to complete. This is >>> something that even unexperienced user can accomplish in less than a month. >> >> Isn't all the libvirt functionality for this already existing? it it >> is basically just virStorageVolCreateFrom(...original vol) and then >> delete the original volume. > > Michal said earlier that virsh vol-move seemed too small a task. > > Do you think that these 4 tasks together merit a 12-week project? > Let me give a summary about my ideas for Libvirt of GSOC 2013. Libvirt storage jobs. This project includes renaming storage volume(storage pool, snapshot,etc), moving volume from one pool to another, the capability support for storage driver (like virsh capabilities for the hypervisor drivers, e.g. what pool types it supports, what volume types each pool type supports, even may what operations/APIs the pool type support, ...etc).

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: [...] > I'm not hugely comfortable with the idea of "capability support" being > done by a student. IMHO to do a good job on that design-wise requires > someone with a very good understanding of libvirt architecture & application > needs. > I understand. However, i think our Libvirt is developing so we should give more choices to learners who are very interested in some field of Libvirt.(Like me, i love the storage system of Libvirt very much). Maybe this is the essence of GSOC, isn't it? Actually, some student is not only interested in Libvirt but also wanna to join this community and contribute to this community forever. (Like me, i love the community because i can learn more knowledge from it.) I believe that interest is the best teacher. No matter how the problem is difficulty i will try my best to achieve it if i am very interested in it. Another key point is that GSOC just let students join the community and finish easy jobs firstly. GSOC wanna train more core developers for our community. If i can finish a job a bit difficulty, i can also accomplish it after GSOC continuously. All in all, i think you should not worry about this matter ;-).

A project must be a 12-week effort. Are you saying you'd like to focus on just capability support for 12 weeks?

On 15/04/13 22:41, harryxiyou wrote: > > On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou(a)gmail.com&gt; wrote: >> >> On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; >> wrote: >> [...] >>> >>> I'm not hugely comfortable with the idea of "capability support" being >>> done by a student. IMHO to do a good job on that design-wise requires >>> someone with a very good understanding of libvirt architecture & >>> application >>> needs. >>> >> I understand. However, i think our Libvirt is developing so we should >> give more >> choices to learners who are very interested in some field of >> Libvirt.(Like me, i >> love the storage system of Libvirt very much). Maybe this is the essence >> of >> GSOC, isn't it? Actually, some student is not only interested in >> Libvirt but also >> wanna to join this community and contribute to this community forever. >> (Like >> me, i love the community because i can learn more knowledge from it.) >> I believe that interest is the best teacher. No matter how the problem is >> difficulty i will try my best to achieve it if i am very interested >> in it. Another >> key point is that GSOC just let students join the community and finish >> easy >> jobs firstly. GSOC wanna train more core developers for our community. If >> i >> can finish a job a bit difficulty, i can also accomplish it after GSOC >> continuously. >> All in all, i think you should not worry about this matter ;-). >> > Hi all, > > After i read all comments from Danpb, Mprivozn, Osier, i find i should > rephrase my project idea for Libvirt storage during GSOC 2013(Thanks > for Stefan Hajnoczi. He let me know this key point). I find Osier and > Mprivozn agree with the project named 'The capability support for > storage' and Danpb just feel it is a bit difficulty for students to do, > which > i have given my feedback to explain. So i rephrase my project idea for > Libvirt storage during GSOC 2013 like following. > > > Project name: The capability support for storage driver. > > Summary: The capability support for storage driver (like virsh > capabilities for the hypervisor drivers, e.g. what pool types it > supports, what volume types each pool type supports, even > may what operations/APIs the pool type support, ...etc). > > Sill level: Advanced. > > Osier said to me this is a deserved bug to fix so i think he > may wanna be the mentor for this one, right? I could be if you want, but the question is which project you are focusing on? This one or the renaming APIs? And as far as I got from the wiki page, we generally don't want the student fails, and the renaming APIs work is much simpler than this one, and thus more possible to succeed in 12 weeks. So Personally I'd suggest adding the renaming APIs as a project into the wiki instead.

On 15/04/13 23:10, Stefan Hajnoczi wrote: > > On Mon, Apr 15, 2013 at 5:00 PM, Osier Yang <jyang(a)redhat.com&gt; wrote: >> >> On 15/04/13 22:41, harryxiyou wrote: >>> >>> On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou(a)gmail.com&gt; >>> wrote: >>>> >>>> On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange >>>> <berrange(a)redhat.com&gt; >>>> wrote: >>>> [...] >>>>> >>>>> I'm not hugely comfortable with the idea of "capability support" being >>>>> done by a student. IMHO to do a good job on that design-wise requires >>>>> someone with a very good understanding of libvirt architecture & >>>>> application >>>>> needs. >>>>> >>>> I understand. However, i think our Libvirt is developing so we should >>>> give more >>>> choices to learners who are very interested in some field of >>>> Libvirt.(Like me, i >>>> love the storage system of Libvirt very much). Maybe this is the >>>> essence >>>> of >>>> GSOC, isn't it? Actually, some student is not only interested in >>>> Libvirt but also >>>> wanna to join this community and contribute to this community >>>> forever. >>>> (Like >>>> me, i love the community because i can learn more knowledge from it.) >>>> I believe that interest is the best teacher. No matter how the problem >>>> is >>>> difficulty i will try my best to achieve it if i am very interested >>>> in it. Another >>>> key point is that GSOC just let students join the community and finish >>>> easy >>>> jobs firstly. GSOC wanna train more core developers for our community. >>>> If >>>> i >>>> can finish a job a bit difficulty, i can also accomplish it after GSOC >>>> continuously. >>>> All in all, i think you should not worry about this matter ;-). >>>> >>> Hi all, >>> >>> After i read all comments from Danpb, Mprivozn, Osier, i find i should >>> rephrase my project idea for Libvirt storage during GSOC 2013(Thanks >>> for Stefan Hajnoczi. He let me know this key point). I find Osier and >>> Mprivozn agree with the project named 'The capability support for >>> storage' and Danpb just feel it is a bit difficulty for students to do, >>> which >>> i have given my feedback to explain. So i rephrase my project idea for >>> Libvirt storage during GSOC 2013 like following. >>> >>> >>> Project name: The capability support for storage driver. >>> >>> Summary: The capability support for storage driver (like virsh >>> capabilities for the hypervisor drivers, e.g. what pool types it >>> supports, what volume types each pool type supports, even >>> may what operations/APIs the pool type support, ...etc). >>> >>> Sill level: Advanced. >>> >>> Osier said to me this is a deserved bug to fix so i think he >>> may wanna be the mentor for this one, right? >> >> >> I could be if you want, but the question is which project you are >> focusing >> on? This one or the renaming APIs? And as far as I got from the wiki >> page, >> we generally don't want the student fails, and the renaming APIs work is >> much simpler than this one, and thus more possible to succeed in 12 >> weeks. >> >> So Personally I'd suggest adding the renaming APIs as a project into the >> wiki >> instead. > > Is that task reasonable for 12 weeks of full-time work? > Yes, It couldn't mean more than 3 months...

I asked because it seems like a very mechanical and relatively short thing to work on. If you still think the scope is good, then please add the project idea to the GSoC wiki using this template: http://qemu-project.org/Google_Summer_of_Code_2013#Project_idea_template

On 15/04/13 22:41, harryxiyou wrote: > > On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou(a)gmail.com&gt; wrote: >> >> On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; >> wrote: >> [...] >>> >>> I'm not hugely comfortable with the idea of "capability support" being >>> done by a student. IMHO to do a good job on that design-wise requires >>> someone with a very good understanding of libvirt architecture & >>> application >>> needs. >>> >> I understand. However, i think our Libvirt is developing so we should >> give more >> choices to learners who are very interested in some field of >> Libvirt.(Like me, i >> love the storage system of Libvirt very much). Maybe this is the essence >> of >> GSOC, isn't it? Actually, some student is not only interested in >> Libvirt but also >> wanna to join this community and contribute to this community forever. >> (Like >> me, i love the community because i can learn more knowledge from it.) >> I believe that interest is the best teacher. No matter how the problem is >> difficulty i will try my best to achieve it if i am very interested >> in it. Another >> key point is that GSOC just let students join the community and finish >> easy >> jobs firstly. GSOC wanna train more core developers for our community. If >> i >> can finish a job a bit difficulty, i can also accomplish it after GSOC >> continuously. >> All in all, i think you should not worry about this matter ;-). >> > Hi all, > > After i read all comments from Danpb, Mprivozn, Osier, i find i should > rephrase my project idea for Libvirt storage during GSOC 2013(Thanks > for Stefan Hajnoczi. He let me know this key point). I find Osier and > Mprivozn agree with the project named 'The capability support for > storage' and Danpb just feel it is a bit difficulty for students to do, > which > i have given my feedback to explain. So i rephrase my project idea for > Libvirt storage during GSOC 2013 like following. > > > Project name: The capability support for storage driver. > > Summary: The capability support for storage driver (like virsh > capabilities for the hypervisor drivers, e.g. what pool types it > supports, what volume types each pool type supports, even > may what operations/APIs the pool type support, ...etc). > > Sill level: Advanced. > > Osier said to me this is a deserved bug to fix so i think he > may wanna be the mentor for this one, right? I could be if you want, but the question is which project you are focusing on? This one or the renaming APIs? And as far as I got from the wiki page, we generally don't want the student fails, and the renaming APIs work is much simpler than this one, and thus more possible to succeed in 12 weeks. So Personally I'd suggest adding the renaming APIs as a project into the wiki instead.

> I could be if you want, but the question is which project you are focusing > on? This one or the renaming APIs? And as far as I got from the wiki page, > we generally don't want the student fails, and the renaming APIs work is > much simpler than this one, and thus more possible to succeed in 12 weeks. > > So Personally I'd suggest adding the renaming APIs as a project into the > wiki > instead. Yup, renaming APIs should be a project into the wiki. Thanks, let me rephrase my idea for Libvirt storage during GSOC again. Project name: The renaming APIs support for all objects. Summary: Adding 'rename' API support for all objects, for all objects, that is to say, not only for storage volume but also for storage pool, snapshots, etc.

Sill level: Beginner Mentor: Osier Yang. Osier, would you please give the summary in details, thanks very much in advance. Any Comments? Thanks in advance ;-)

On 04/15/2013 09:16 AM, harryxiyou wrote: >> I could be if you want, but the question is which project you are focusing >> on? This one or the renaming APIs? And as far as I got from the wiki page, >> we generally don't want the student fails, and the renaming APIs work is >> much simpler than this one, and thus more possible to succeed in 12 weeks. >> >> So Personally I'd suggest adding the renaming APIs as a project into the >> wiki >> instead. > > Yup, renaming APIs should be a project into the wiki. Thanks, let me rephrase > my idea for Libvirt storage during GSOC again. > > > Project name: The renaming APIs support for all objects. > > Summary: Adding 'rename' API support for all objects, for all objects, > that is to say, not only for storage volume but also for storage pool, > snapshots, etc. This indeed feels like a reasonable project, where there is enough work to do to fill up 12 weeks of good effort while still having something measurable to commit, and where the design is known enough in advance that it won't be stalled by developer discussion on correct design.

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: [...] > I'm not hugely comfortable with the idea of "capability support" being > done by a student. IMHO to do a good job on that design-wise requires > someone with a very good understanding of libvirt architecture & application > needs. > I understand. However, i think our Libvirt is developing so we should give more choices to learners who are very interested in some field of Libvirt.(Like me, i love the storage system of Libvirt very much). Maybe this is the essence of GSOC, isn't it? Actually, some student is not only interested in Libvirt but also wanna to join this community and contribute to this community forever. (Like me, i love the community because i can learn more knowledge from it.) I believe that interest is the best teacher. No matter how the problem is difficulty i will try my best to achieve it if i am very interested in it. Another key point is that GSOC just let students join the community and finish easy jobs firstly. GSOC wanna train more core developers for our community. If i can finish a job a bit difficulty, i can also accomplish it after GSOC continuously. All in all, i think you should not worry about this matter ;-).

I believe Google will announce GSoC again this year (there is no guarantee though) and I have created the wiki page so we can begin organizing project ideas that students can choose from.

On Tue, Feb 12, 2013 at 5:21 AM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: > On Thu, Feb 7, 2013 at 4:19 PM, Stefan Hajnoczi <stefanha(a)gmail.com&gt; wrote: >> I believe Google will announce GSoC again this year (there is >> no guarantee though) and I have created the wiki page so we can begin >> organizing project ideas that students can choose from. > > Google Summer of Code 2013 has just been announced! > > http://google-opensource.blogspot.de/2013/02/flip-bits-not-burgers-google... > > Some project ideas have already been discussed on IRC or private > emails. Please go ahead and put them on the project ideas wiki page: > > http://wiki.qemu.org/Google_Summer_of_Code_2013 > I am a senior student and wanna do some jobs about storage in Libvirt in GSOC 2013. I wonder whether Libvirt and QEMU will join GSOC 2013 together. If true, i will focus on http://wiki.qemu.org/Google_Summer_of_Code_2013 and add myself introductions to QEMU links said by Stefan Hajnoczi. Could anyone give me some suggestions? Thanks in advance.