Re: Google Summer of Code 2013 ideas wiki open

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/04/13 15:56, Stefan Hajnoczi wrote:
On Mon, Apr 15, 2013 at 4:43 AM, harryxiyou <harryxiyou@xxxxxxxxx> wrote:
On Fri, Apr 12, 2013 at 11:29 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote:
On Fri, Apr 12, 2013 at 10:58 AM, Daniel P. Berrange
<berrange@xxxxxxxxxx> 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).

"Moving volume from one pool to another" is not deserved to be included
in the project. As said times, a new virsh command to wrap the existing
APIs is good enough.

EIther the renaming APIs (for all objects, not only for storage volume),
or the capability support for storage driver can be a project, but not
together.

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

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]