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@linux.vnet.ibm.com wrote:
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com>

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@linux.vnet.ibm.com>
---
  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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel






-- 
Thanks and best regards!

Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com>
IBM Linux Technology Center