On Fri, Feb 8, 2013 at 9:20 AM, Osier Yang <jyang@redhat.com> 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

On 10/04/13 21:13, harryxiyou wrote:

On Fri, Feb 8, 2013 at 4:07 PM, Michal Privoznik <mprivozn@redhat.com> 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

On Fri, Apr 12, 2013 at 1:07 PM, Osier Yang <jyang@redhat.com> wrote: [...]

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.

Sure, they are a whole project for GSOC 2013 but separate ones.

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.

Maybe i will have a try for all of them ;-)

...

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.

Maybe we should have this virsh command to move volume from one pool to another one directly. -- Thanks Harry Wei

On Fri, Apr 12, 2013 at 2:34 PM, Michal Privoznik <mprivozn@redhat.com> wrote: Hi Michal,

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();

It was reported here https://bugzilla.redhat.com/show_bug.cgi?id=760795.

...

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.

Maybe it is a bit difficulty. However, I wanna have a try and i think other GSOCers have the same thoughts. This would be more exciting and really make more sense for our Libvirt community, isn't it? Michal, thanks for your comments. -- Thanks Harry Wei

On 12/04/13 14:34, 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();

I think this request is mainly for other managment apps' use, for virsh, it's not that deserved, "virsh destroy dom && virsh edit dom" can do the work. Currently, the program needs to do the following to rename, e.g: virDomainDestroyFlags virDomainGetXMLDesc --change XML virDomainUndefineFlags virDomainDefineFlags Having a renaming API will ease the use, but as I said, I'm not sure if it's deserved from different p.o.v, because it may only makes sense for inactive objects.

...

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.

...

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.

Michal

-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange <berrange@redhat.com> 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? Stefan

On Fri, Apr 12, 2013 at 11:47 PM, harryxiyou <harryxiyou@gmail.com> wrote:

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@gmail.com> 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 :-/ -- Thanks Harry Wei

On Fri, Apr 12, 2013 at 11:57 PM, Stefan Hajnoczi <stefanha@gmail.com> 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 -- Thanks Harry Wei

On 13/04/13 13:35, Osier Yang wrote:

On 13/04/13 00:05, harryxiyou wrote:

...

On Fri, Apr 12, 2013 at 11:57 PM, Stefan Hajnoczi <stefanha@gmail.com> 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

s/long/long time/,

to libvirt, enjoy hacking...

Osier

-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On 12/04/13 23:57, Stefan Hajnoczi wrote:

On Fri, Apr 12, 2013 at 5:56 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Fri, Apr 12, 2013 at 11:47 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@gmail.com> 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Apr 12, 2013 at 11:47 PM, harryxiyou <harryxiyou@gmail.com> wrote:

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@gmail.com> 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 :-/ -- Thanks Harry Wei

On Mon, Apr 15, 2013 at 4:43 AM, harryxiyou <harryxiyou@gmail.com> wrote:

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

...

On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange <berrange@redhat.com> 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@gmail.com> wrote:

...

On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange <berrange@redhat.com> 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. Michal

On Mon, Apr 15, 2013 at 10:34:01AM +0200, Michal Privoznik wrote:

On 15.04.2013 04:43, harryxiyou wrote:

...

On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

...

On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange <berrange@redhat.com> 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.

There rationale for a rename API isn't thread safety

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.

Sure, that's what it means to provide an atomic operation. You should not assume that dumpxml + define is more reliable though. For the QEMU/LXC drivers where XML is the canonical configuration, it may be reliable, but for VMWare / VirtualBox, the dumpxml + define pair will *loose* information for any native config declarations that libvirt does not understand. Their native APIs also already provide a rename capability, thus a libvirt rename API is unambiguously safer for those hypervisors. It is also much better from an access control POV, because the 'define' API is a highly privileged operation, whereas 'rename' is fairly low privilege. It is desirable to be able to give someone 'rename' permissions, without giving them 'define' permissions. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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 ;-). -- Thanks Harry Wei

On Mon, Apr 15, 2013 at 4:41 PM, harryxiyou <harryxiyou@gmail.com> wrote:

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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).

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

On 15/04/13 22:41, harryxiyou wrote:

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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. Osier

On 15/04/13 23:10, Stefan Hajnoczi wrote:

On Mon, Apr 15, 2013 at 5:00 PM, Osier Yang <jyang@redhat.com> wrote:

...

On 15/04/13 22:41, harryxiyou wrote:

...

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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... Osier

On 15/04/13 23:28, Stefan Hajnoczi wrote:

...

On 15/04/13 23:10, Stefan Hajnoczi wrote:

...

On Mon, Apr 15, 2013 at 5:00 PM, Osier Yang <jyang@redhat.com> wrote:

...

On 15/04/13 22:41, harryxiyou wrote:

...

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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

On Mon, Apr 15, 2013 at 5:15 PM, Osier Yang <jyang@redhat.com> wrote: thing to work on.

If only supports renaming for inactive objects, it is, and that was why I said I'm not sure if it's deserved. But if supports it for active objects too, it's not simple anymore.

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 23:28, Stefan Hajnoczi wrote:

...

On 15/04/13 23:10, Stefan Hajnoczi wrote:

...

On Mon, Apr 15, 2013 at 5:00 PM, Osier Yang <jyang@redhat.com> wrote:

...

On 15/04/13 22:41, harryxiyou wrote:

...

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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

On Mon, Apr 15, 2013 at 5:15 PM, Osier Yang <jyang@redhat.com> wrote: 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

Just got an account of the wiki, and added. Osier

On 15/04/13 23:16, harryxiyou wrote:

On Mon, Apr 15, 2013 at 11:00 PM, Osier Yang <jyang@redhat.com> wrote:

...

On 15/04/13 22:41, harryxiyou wrote:

...

On Mon, Apr 15, 2013 at 9:43 PM, harryxiyou <harryxiyou@gmail.com> wrote:

...

On Mon, Apr 15, 2013 at 5:13 PM, Daniel P. Berrange <berrange@redhat.com> 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. 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.

Project name: Add rename APIs for all objects Summary: Add rename APIs for all objects, including domain, snaphot, network, interface, nwfilter, secret, storage pool, and storage volume.

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

-- Thanks Harry Wei

On Tue, Apr 16, 2013 at 12:22 AM, Eric Blake <eblake@redhat.com> wrote: [...]

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.

I will give my design plan for this project here which developers can discuss my design so that we can get a good conclusion.

While the work should definitely start with offline renames, there is also room for some additional scope such as online rename support for hypervisors such as ESX that might already provide such functionality natively and where the existing libvirt approach of dumpxml/define may be inadequate to expose the full hypervisor capability.

Yup. Online rename support is also included for this project. Osier has rephrased the summary like following, let me add online rename support. Project name: Add rename APIs for all objects Summary: Add rename APIs for all objects, including domain, snaphot, network, interface, nwfilter, secret, storage pool, storage volume and online rename support for hypervisors, etc. [...]

Remember that not all good ideas will be selected, but I think you are finally settling into a good idea. And even if you don't get accepted by GSOC, your idea for contribution is still useful and would still be worth working on.

Sure, actually, i love the storage portions of Libvirt very much. If not accepted by GSOC, i will also finish my ideas for Libvirt. In fact, I wanna do some deserved jobs(about storage knowledge) for Libvirt community. Very thanks for your comments ;-) -- Thanks Harry Wei

On Tue, Apr 16, 2013 at 10:39 PM, harryxiyou <harryxiyou@gmail.com> wrote:

On Tue, Apr 16, 2013 at 12:22 AM, Eric Blake <eblake@redhat.com> wrote:

...

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.

I have got some ideas for realizing 'Add rename APIs for all objects'. See http://code.google.com/p/gsocxy/wiki/GeneralDesignForRenameAPIs in details. So first, i will finish *Rename storage volume* for offline storage driver(inactive object). I consider that it would be like a command like this 'virsh vol-rename xxx' so i could refer to 'virsh vol-clone xxx'. I can find patches for 'vol-clone' here. http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=6852c88fc71a02b107d3beb... I will analyze vol-clone's thoughts and design for 'Rename storage volume' and then program for my thoughts. At last, give some tests and submit my patches for 'Rename storage volume' to upstream. Are my thoughts all right? Could anyone please give me some suggestions? Thanks in advance ;-)

Of course, i will give my *Checklist* for these stuffs ;-) -- Thanks Harry Wei

On Mon, Apr 15, 2013 at 10:55 PM, Daniel P. Berrange <berrange@redhat.com> wrote: [...]

Enthusiasm of the students to learn libvirt isn't the only consideration. The project mentors have to put non-trivial effort into GSoC and want to have some level of confidence that the project will result in a positive outcome for both the student & the project.

Sure, i think so.

I think a project looking at adding 'rename' API support for all objects in libvirt has a high liklihood of success, since it is a clearly defined problem with easily measurable success criteria and a fairly unambiguous design to follow that will not require much debate.

A project looking at "capabilities" has a much lower liklihood of success because it very focused on architectural design. Getting such design right requires significant knowledge of libvirt, and will require significant debate & discussion by many parties on the list. Design discussions of this kind pay no attention to any external deadlines, that programs like GSoC have. I'm not saying a student couldn't write something, but I'm not confident that the result would be something we'd be prepared to merge, and by that benchmark could be considered a failure.

Yup, i think so too.

I think GSoC projects should focus on something where the design is clearly defined upfront, and the task is mostly about learning the libvirt codebase & getting a thorough implementation done.

Maybe it should be like this. Renaming jobs may be more comfortable for GSOC. Thanks for your comments. -- Thanks Harry Wei

On Tue, Feb 12, 2013 at 5:21 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

On Thu, Feb 7, 2013 at 4:19 PM, Stefan Hajnoczi <stefanha@gmail.com> 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-su...

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. -- Thanks Harry Wei

On Thu, Feb 14, 2013 at 11:15 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote: [...]

Hi Harry, Hi Stefan,

Thanks for your interest. You can begin thinking about ideas but please keep in mind that we are still in the very early stages of GSoC preparation.

Google will publish the list of accepted organizations on April 8th. Then there is a period of over 3 weeks to discuss your project idea with the organization.

In the meantime, the best thing to do is to get familiar with the code bases and see if you can find/fix a bug. Contributing patches is a great way to get noticed.

There is always a chance that QEMU and/or libvirt may not be among the list of accepted organizations, so don't put all your eggs in one basket :).

Thanks for your suggestions. -- Thanks Harry Wei