[libvirt] Google Summer of Code 2013 ideas wiki open

[Daniel P. Berrange]

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