>On 05/16/2012 02:49 PM, Ori Liel wrote: >>> On 05/16/2012 01:16 PM, Gilad Chaplik wrote: >>>> Hi All, >>>> >>>> I am adding the ability to import a VM or a Template to a storage-domain, >>>> when this VM or Template already exists in the destination storage domain. >>>> Until now, Backend failed this. Now I want to enable the user to specify >>>> that he wishes this VM/Template will be created again by a different name, >>>> i.e - cloned. >>>> >>>> [feature page: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce] >>>> >>>> I plan to achieve this using a new parameter, but I want to reach an >>>> agreement >>>> about this parameter's name. I thought simply to call it "clone". >>>> >>>> Another thing that I'll do in the patch-set is add the currently-missing >>>> ability >>>> to specify whether the snapshots of the VM, which is being imported, will >>>> be collapsed into a single snapshot (we have this ability in GUI). I am >>>> also >>>> deliberating about the name of this parameter. I thought about >>>> "collapse_snapshots" (same as in GUI). >>>> >>>> Does anyone think "clone" and "collapse_snapshots" are inappropriate and >>>> has >>> >>> /clone/ already in-use (used to clone vm from template), >>> >>> <vm> >>> <disks> >>> <clone>true|false</clone> >>> ..., >>> >>> you can simply say if imported vm has <name> element, this is import+clone, >>> otherwise import, >> >> If in the future we will want to enable overriding a VM's params on import, >> this will be confusing >> (because a user might want to import a VM and change it's name - but not >> clone it if it already exists). > >the concept of /import/ is copy vm from sd1 to sd2, then you can change vm >meta as needed,
ok >besides we already using <name> element existence/absence as action >'determinator' in other >places in api. It's true, existence of ID/name does determine behaviour elsewhere in the API. In this specific case, it feels a bit less intuitive; what do you think about the difference between the following two scenarios? If user passes clone=true, and this VM doesn't already exist on the destination storage-domain, then the operation fails - makes direct sense: you wanted to clone, but this VM doesn't already exist. If user passes name=VM1, and this VM doesn't already exist on the destination storage-domain, then the operation fails - a bit strange. The logic is more construed: you supplied a name, therefore you meant you want to clone, but this VM doesn't already exist. > >> >>> as about collapse_snapshots, i don't mind, but this should be done in the >>> way <clone> is implemented >>> in <disks> collection >> >> Semantically, a snapshot is a point in time of a VM. It not only associated >> any more only with the VM's >> disks; it includes the VM's meta-data as well. For this reason, maybe the >> parameter collapse_snapshots >> should not be in <disks> collection (although, technically, the collapse >> will be done on disks) > >obviously i meant <snapshots>, thanks. > >> >>> >>> >>>> better suggestions? >>>> >>>> Thanks, >>>> Gilad >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
