Re: [Kimchi-devel] [PATCH 1/5] clone template: update API.md

On 02/12/2014 01:46 AM, Sheldon wrote: > On 02/12/2014 08:35 AM, Aline Manera wrote: >> On 02/11/2014 10:32 PM, Aline Manera wrote: >>> On 02/11/2014 11:58 AM, shaohef(a)linux.vnet.ibm.com wrote: >>>> From: ShaoHe Feng <shaohef(a)linux.vnet.ibm.com&gt; >>>> >>>> The user may clone a template from an existing template with >>>> different >>>> name. >>>> He can update some attributes when he clone a template. >>>> And he can also customize some parts of the template to save the >>>> effort to >>>> create a full new template later. >>>> >>>> Signed-off-by: ShaoHe Feng <shaohef(a)linux.vnet.ibm.com&gt; >>>> --- >>>> docs/API.md | 27 ++++++++++++++++++++++++++- >>>> 1 file changed, 26 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/docs/API.md b/docs/API.md >>>> index 580728c..bf4dd78 100644 >>>> --- a/docs/API.md >>>> +++ b/docs/API.md >>>> @@ -257,7 +257,32 @@ A interface represents available network >>>> interface on VM. >>>> >>>> **Actions (POST):** >>>> >>>> -* *No actions defined* >>>> +* clone: clone a template from an existing template with >>>> different name. >>> >>> To clone a template the user just need to pass the template name to >>> clone from. >>> >>> So I expect: >>> POST /templates {template: /templates/my-template} > POST for collection is just for CREATE method. > POST /templates {template: /templates/my-template} can not tell the > kimchi this is a "clone" action. >> >> The API can be as you did: >> >> POST /templates/my-template/clone to create a new template from >> my-template >> >> So in this case any parameter is needed > None parameter is needed, all they are optional. > In this way, user can clone and customize some parts of the template > one time. Clone will just clone the template. To customize the cloned template user will use the edit function.

> Of course, user still can customize some parts of the template by > "UPDATE" later. > > Here is the history of RFC.| > ||| >> 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. Yeap. As Adam said the clone will just "duplicate the template" with all default in new template. And as edit flow is in place, the user an edit the cloned template accordingly. > 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. > of course, the user can modify the CPU number after he does clone. >>> >>> This will create a new template based on /templates/my-template >>> >>> To change the parameters in new template user can use the edit >>> function. >>> >>>> + * name *(optional)*: A name for the new template. >>>> + * folder *(optional)*: A virtual path which can be used to >>>> organize Templates >>>> + in a user interface. The format is an array of path >>>> components. >>>> + * icon *(optional)*: A URI to a PNG image representing this >>>> template >>>> + * os_distro *(optional)*: The operating system distribution >>>> + * os_version *(optional)*: The version of the operating >>>> system distribution >>>> + * cpus *(optional)*: The number of CPUs assigned to the VM >>>> + * memory *(optional)*: The amount of memory assigned to the VM >>>> + * cdrom *(optional)*: A volume name or URI to an ISO image >>>> + * storagepool *(optional)*: URI of the storagepool where >>>> template allocates >>>> + vm storage. >>>> + * networks *(optional)*: list of networks will be assigned to >>>> the new VM. >>>> + * disks *(optional)*: An array of requested disks with the >>>> following optional >>>> + fields (either *size* or *volume* must be specified): >>>> + * index: The device index >>>> + * size: The device size in GB >>>> + * volume: A volume name that contains the initial disk >>>> contents >>>> + * graphcis *(optional)*: A dict of graphics paramenters of >>>> this template >>>> + * type: The type of graphics. It can be VNC or spice or >>>> None. >>>> + * vnc: Graphical display using the Virtual Network >>>> + Computing protocol >>>> + * spice: Graphical display using the Simple Protocol for >>>> + Independent Computing Environments >>>> + * null: Graphics is disabled or type not supported >>>> + * listen: The network which the vnc/spice server listens on. >>>> >>>> ### Collection: Storage Pools >>>> >>> >>> _______________________________________________ >>> Kimchi-devel mailing list >>> Kimchi-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> >> >> > > > -- > Thanks and best regards! > > Sheldon Feng(???)&lt;shaohef(a)linux.vnet.ibm.com&gt; > IBM Linux Technology Center