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.
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.
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