[Kimchi-devel] [PATCH 1/5] clone template: update API.md
Aline Manera
alinefm at linux.vnet.ibm.com
Wed Feb 12 12:17:14 UTC 2014
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140212/1e250439/attachment.html>
More information about the Kimchi-devel
mailing list