[libvirt] Google Summer of Code 2013 ideas wiki open

[harryxiyou]

On Tue, Apr 16, 2013 at 12:22 AM, Eric Blake <eblake at 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=6852c88fc71a02b107d3beb90f13dce90b4784b2
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 ;-)



--
Thanks
Harry Wei