[Kimchi-devel] [PATCH 1/5] clone template: update API.md
Sheldon
shaohef at linux.vnet.ibm.com
Thu Feb 13 05:27:31 UTC 2014
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 at linux.vnet.ibm.com wrote:
>>>>> From: ShaoHe Feng <shaohef at 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 at 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 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
>
--
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/20140213/ab588584/attachment.html>
More information about the Kimchi-devel
mailing list