On 02/12/2014 08:17 PM, Aline Manera
wrote:
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.
OK, change it next version.
But I do not think it is a not bad thing that we allow all
parameters to be optional.
Some scenarios as follow:
1. for kimchi we can still clone a template without parameters
POST /templates/my-template/clone
to create a new template from my-template
2 .other developer parties, maybe they just want to call kimchi
API,
They may just want to use kimchi UI and do not use kimchi UI, then
the can call
POST /templates/my-template/clone {"name": "new-name", "CPUs": 4}
to create a new template from my-template and change the name and
CPUs just one
API call.
3. In our kimchi template page
There maybe many diff templates.
but all of them just display 4 information, OS, CPUs, Version,
Memory.
As we all know， the purpose of clone is to save the effort to
create a new one and
just customize some parts of the template.
Usually a user want to clone a template, he will fist view the
details of template.
he can do the follow step.
a). he can open the details page of one template
_______________________________________________________________________
Name: my-template CDROM:
F19.iso
Vendor: fedora Storage Pool:
default
Version: 19 Network:
default
CPU Number: 1
Memory: 1024
Disk(GB): 10
_______________________________________________________________________
exit clone edit.
b). change one of attribute.
if he just want to edit the CPU Number to 2, The he can change it as
follow:
_______________________________________________________________________
Name: my-template CDROM:
F19.iso
Vendor: fedora Storage Pool:
default
Version: 19 Network:
default
CPU Number: 2
Memory: 1024
Disk(GB): 10
_______________________________________________________________________
exit clone edit.
c) and click clone
VS. the "duplicate template" with default everything.
The user must do as the follow steps:
a) open the one template page the check this is he want.
b) close it.
c) click "clone" button.
d) open the new clone template
e) edit the CPU Numbe
f) save it.
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
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com>
IBM Linux Technology Center