----- Original Message -----
> From: "Michael Pasternak" <mpast...@redhat.com>
> To: "Itamar Heim" <ih...@redhat.com>, "Omer Frenkel" <ofren...@redhat.com>
> Cc: "Gilad Chaplik" <gchap...@redhat.com>, "engine-devel"
> <engine-devel@ovirt.org>, "Doron Fediuck"
> <dfedi...@redhat.com>, "Ori Liel" <ol...@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"<ol...@redhat.com>
> >>>> To: "Michael Pasternak"<mpast...@redhat.com>
> >>>> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar
> >>>> Heim"<ih...@redhat.com>, "Doron Fediuck"<dfedi...@redhat.com>,
> >>>> "Gilad Chaplik"<gchap...@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
>
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
