[Kimchi-devel] [RFC]: for template cloning.

[Sheldon]

On 01/29/2014 11:06 PM, Adam King wrote:
>
> On 1/28/2014 10:11 AM, Sheldon wrote:
>>
>>
>>         template cloning:
>>         <https://github.com/kimchi-project/kimchi/wiki/template-cloning-and-customization#wiki-template-cloning>
>>
>> |1|||clone a template|  from|||template|
>> The user may clone a template from an existing template with different name.
>> Later he can customize some parts of the template to save the effort to create a full new template.
>> For example, he can update the network of the template cloned to have a new different template.|
> |Can we provide a reasonable default the name of the clone|? 
How about we set the default name of the clone as follow?
if the template name is "kimchi-template", then the default name is 
"kimchi-template-clone1".
and user will clone this template twice, then the default name is 
"kimchi-template-clone2".
> With the full edit flow in place, its tempting to just add
> a "duplicate template" action to template. The action default 
> everything in the new template.
  Do you means we let the user pre-edit the template.
for if user want to clone a template with name "template1", but he just 
want a CPU numbers are different.
He just modify the current template( "template1") , and press "clone", 
then kimchi generate "template1-clone1" template.
We will not save the "template1" what he modify.
and all the attributes of new "template1-clone1" template are same with  
"template1" except name and CPU number.

Right?

of course, the user can modify the CPU number after he does clone.

>> |
>>
>>
>> 2.||we should also also user||||clone a template|  from vm|
>> |I just concern the image volume.
>> For vm may has no CDROM attribute.
>> Then does the template need to copy the image volume.
>> |For VM clone, can we make the the vm image as a backing file(or we can
>> call it base image).
>>
>> Then we can create two new images for this vm and new vm.
>>
>> All these two new images are a read/write snapshot of the original image,
>>
>> -- any changes to new images will not be reflected in original image.
>>
>>
>> http://libvirt.org/formatstorage.html#StorageVolBacking
>>
>> http://wiki.qemu.org/Documentation/CreateSnapshot
>> |
> Section 2 of the RFC gets very interesting, but somewhat more 
> complicated than clone template.
> I suggest we treat this scenario as a create template scenario, and 
> separately from clone template.
ACK
>
>> |
>> |
>> -- 
>> Thanks and best regards!
>>
>> Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
>> IBM Linux Technology Center
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
> -- 
> Adam King<rak at linux.vnet.ibm.com>
> IBM CSI
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel


-- 
Thanks and best regards!

Sheldon Feng(???)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140210/ace6eea5/attachment.html>