[Engine-devel] restapi: New params for import VM/Template

[Gilad Chaplik]

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>, "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "Gilad Chaplik" <gchaplik at redhat.com>, "engine-devel" <engine-devel at ovirt.org>, "Doron Fediuck"
> <dfediuck at redhat.com>, "Ori Liel" <oliel at redhat.com>
> Sent: Wednesday, May 16, 2012 4:17:57 PM
> Subject: Re: restapi: New params for import VM/Template
> 
> On 05/16/2012 04:05 PM, Itamar Heim wrote:
> > On 05/16/2012 03:49 PM, Michael Pasternak wrote:
> >> On 05/16/2012 03:26 PM, Gilad Chaplik wrote:
> >>>
> >>>
> >>> Thanks,
> >>> Gilad.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Ori Liel"<oliel at redhat.com>
> >>>> To: "Michael Pasternak"<mpastern at redhat.com>
> >>>> Cc: "engine-devel"<engine-devel at ovirt.org>, "Itamar
> >>>> Heim"<iheim at redhat.com>, "Doron Fediuck"<dfediuck at redhat.com>,
> >>>> "Gilad Chaplik"<gchaplik at redhat.com>
> >>>> Sent: Wednesday, May 16, 2012 2:49:17 PM
> >>>> Subject: Re: restapi: New params for import VM/Template
> >>>>
> >>>>> 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),
> >>>
> >>> clone here has a different context, clone VM vs. clone disks.
> >>
> >> having two clone elements in vm will be confusing.
> >>
> >> -1
> >>
> >>>
> >>>>>
> >>>>> <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).
> >>>
> >>> +1, cloning a vm and changing the vm's metadata (i.e vm's name)
> >>> should not be inter-dependent.
> >>
> >> how exactly this is contradict changing metadata on the fly?,
> >> exactly on opposite - it works perfectly well for your use-case:
> >>
> >> BE logic:
> >> --------
> >>
> >> if (local<storage>) has vm named as on remote<storage>
> >>  (export.domain)
> > 
> > please note "vm exists" is based on vm uuid, not on vm name
> 
> i think it based on name, Omer?

I wrote the backend-side, it is by uuid.

> 
> > 
> >> {
> >>    if PARAMS<name>  != remote<name>  (export.domain)
> >>    {
> >>      copy + rename
> >>    } else {
> >>      error
> >>    }
> >> } else {
> >>    if PARAMS<name>  != remote<name>  (export.domain)
> >>    {
> >>      copy + rename
> >>    } else {
> >>      copy
> >>    }
> >> }
> >>
> >>>
> >>>>
> >>>>> 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)
> >>>
> >>> +1, I think the collapse_snapshots should be in the vm context
> >>> (snapshots is under vm).
> >>
> >> i meant<snapshots>, see my other email on this.
> >>
> >>>
> >>> Other than that, currently, if you want to clone a vm, it must be
> >>> 'collapsed snapshots', so
> >>> the flow to clone a vm (with your suggestion) will be:
> >>>
> >>> <action>
> >>>      <vm>
> >>>          <name>new_vm</..>
> >>>          <disks>
> >>>              <collapse_snapshot>true</..>
> >>>          </..>
> >>>      </..>
> >>>      <clone>true</..>
> >>> </..>
> >>>
> >>> where collapse_snapshot should be superior to clone, this
> >>> structure is a bit confusing.
> >>>
> >>>>
> >>>>>
> >>>>>
> >>>>>> better suggestions?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gilad
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Michael Pasternak
> >>>>> RedHat, ENG-Virtualization R&D
> >>>>
> >>
> >>
> > 
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
>