[Engine-devel] restapi: New params for import VM/Template
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 better suggestions? Thanks, Gilad
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, as about collapse_snapshots, i don't mind, but this should be done in the way <clone> is implemented in <disks> collection
better suggestions?
Thanks, Gilad
-- Michael Pasternak RedHat, ENG-Virtualization R&D
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).
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)
better suggestions?
Thanks, Gilad
--
Michael Pasternak RedHat, ENG-Virtualization R&D
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, besides we already using <name> element existence/absence as action 'determinator' in other places in api.
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
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
On 05/16/2012 03:44 PM, Ori Liel wrote:
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.
it's just another import, see my other email on this with pseudocode. -- Michael Pasternak RedHat, ENG-Virtualization R&D
Thanks, Gilad. ----- Original Message -----
From: "Ori Liel" <oliel@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim" <iheim@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@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.
<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.
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). 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
On 05/16/2012 03:26 PM, Gilad Chaplik wrote:
Thanks, Gilad.
----- Original Message -----
From: "Ori Liel" <oliel@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim" <iheim@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com>, "Gilad Chaplik" <gchaplik@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) { 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
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@redhat.com> To: "Michael Pasternak"<mpastern@redhat.com> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<iheim@redhat.com>, "Doron Fediuck"<dfediuck@redhat.com>, "Gilad Chaplik"<gchaplik@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
{ 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
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@redhat.com> To: "Michael Pasternak"<mpastern@redhat.com> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<iheim@redhat.com>, "Doron Fediuck"<dfediuck@redhat.com>, "Gilad Chaplik"<gchaplik@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?
{ 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
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Omer Frenkel" <ofrenkel@redhat.com> Cc: "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Doron Fediuck" <dfediuck@redhat.com>, "Ori Liel" <oliel@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@redhat.com> To: "Michael Pasternak"<mpastern@redhat.com> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<iheim@redhat.com>, "Doron Fediuck"<dfediuck@redhat.com>, "Gilad Chaplik"<gchaplik@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
On 05/16/2012 04:17 PM, Michael Pasternak wrote:
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@redhat.com> To: "Michael Pasternak"<mpastern@redhat.com> Cc: "engine-devel"<engine-devel@ovirt.org>, "Itamar Heim"<iheim@redhat.com>, "Doron Fediuck"<dfediuck@redhat.com>, "Gilad Chaplik"<gchaplik@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?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about). i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
{ 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
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ... -- Michael Pasternak RedHat, ENG-Virtualization R&D
On 05/16/2012 05:08 PM, Michael Pasternak wrote:
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ...
1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work)
On 05/16/2012 05:05 PM, Itamar Heim wrote:
On 05/16/2012 05:08 PM, Michael Pasternak wrote:
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ...
1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work)
ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined). this way you does not force user to supply /X=true/ arg as it's obvious in this scenario. -- Michael Pasternak RedHat, ENG-Virtualization R&D
On 05/16/2012 05:05 PM, Itamar Heim wrote:
On 05/16/2012 05:08 PM, Michael Pasternak wrote:
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ...
1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work)
ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined). this way you does not force user to supply /X=true/ arg as it's obvious in this scenario. -- Michael Pasternak RedHat, ENG-Virtualization R&D
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Omer Frenkel" <ofrenkel@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Doron Fediuck" <dfediuck@redhat.com>, "Ori Liel" <oliel@redhat.com> Sent: Wednesday, May 16, 2012 6:06:15 PM Subject: Re: restapi: New params for import VM/Template
On 05/16/2012 05:05 PM, Itamar Heim wrote:
On 05/16/2012 05:08 PM, Michael Pasternak wrote:
On 05/16/2012 04:38 PM, Itamar Heim wrote:
please note "vm exists" is based on vm uuid, not on vm name
i think it based on name, Omer?
two different things: 1. vm name is unique. 2. import vm cannot import an existing vm based on it's uuid (which is what this feature is about).
i.e., if i create a vm X, export it, rename X to Y, i will still fail importing X without 'cloning' it (the cloning process is about changing uuid's of vm, disks, nics)
why import not changing ids by definition? this way only collision that might happen is a vm.name ..., i.e 'cannot import vm.x cause vm with same name already exist' ...
1. because we didn't have this behavior till now. 2. because for templates you may want to preserve the uuid to move over VMs/chains using it. 3. because import keeping uuid's allows to handle snapshot chains and re-use of template which does not require changing the actual images, still pointing to the low level actual file/chains (can also be fixed by separating internal uuid's and disks/snapshots uuids, but much more work)
ok, then implicit re-id can happen when importing already existent entity and only complaint will be entity name (which has to stay unique and user-defined).
this way you does not force user to supply /X=true/ arg as it's obvious in this scenario.
ok, so we agree on: 'collapse_snapshots' under vm->snapshots but I have doubt about the 'implicit clone by name': first of all I don't think it's that obvious for the user. Going FW it would be nice to override parameters in import vm/template (e.g. open similar dialog to new vm dialog in import vm - GUI-wise), and to limit the vm name uniqueness to DC/cluster level (not the entire system) - and [for both of them] not cloning the vm/template - let say because of licensing issues.
--
Michael Pasternak RedHat, ENG-Virtualization R&D
Going FW it would be nice to override parameters in import vm/template
I agree with you and that's why - As a user I don't think there should be a difference in the API between: - Importing a VM and changing it's name - Importing a VM for the second time The reason you want to add artificial difference between the two scenarios above is because currently there are implementations limitations (changing the image ID while importing is not supported yet) I think that we should solve the limitations in the implementation instead of making our API cumbersome (implicit clone by name and adding some clone entity are both bad IMO). Livnat
cc'ing Simon, Hi Simon, I remember we talked about why the engine can't decide implicitly if to clone the vm or not - it should be the user call? Can you share your opinion about that? Thanks, Gilad. ----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Michael Pasternak" <mpastern@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim" <iheim@redhat.com> Sent: Thursday, May 17, 2012 9:43:45 AM Subject: Re: [Engine-devel] restapi: New params for import VM/Template
Going FW it would be nice to override parameters in import vm/template
I agree with you and that's why -
As a user I don't think there should be a difference in the API between: - Importing a VM and changing it's name - Importing a VM for the second time
The reason you want to add artificial difference between the two scenarios above is because currently there are implementations limitations (changing the image ID while importing is not supported yet)
I think that we should solve the limitations in the implementation instead of making our API cumbersome (implicit clone by name and adding some clone entity are both bad IMO).
Livnat
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Simon Grinberg" <sgrinber@redhat.com> Cc: "Michael Pasternak" <mpastern@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim" <iheim@redhat.com>, "Livnat Peer" <lpeer@redhat.com>, "Ori Liel" <oliel@redhat.com> Sent: Thursday, May 17, 2012 10:21:51 AM Subject: Re: [Engine-devel] restapi: New params for import VM/Template
cc'ing Simon,
Hi Simon,
I remember we talked about why the engine can't decide implicitly if to clone the vm or not - it should be the user call? Can you share your opinion about that?
Sorry for missing on that. First reason informative - User should know what he and we are doing. Example: * Setup2 already has vm named Kuku imported few months back or by another admin * The admin that usually works on setup1, decides it's time to move the VM to setup2 (for any reason), so he exports kuku and then imports into setup1 * We automatically import as Kuku1 * Admin searches for the name kuku and starts it - he is now working on the old one without knowing it. The above can cause confusion, lost time to understand why kuku is not working as expected and/or lost time to fix the err when trying to merge data from the currently running kuku and kuku1 which is the VM the user actually wanted to use. We must stop and ask. The question should be very similar to file copy on decent OSs - Override, save as, cancel. So does the API for this operation. * The above also leads to also question if importing a VM with the same name as a vm in the system, even though it is clear it's a different VM (different GUID/image ID etc) Second reason - prevent user error: User writes a script, by mistake he tries to copy the same VM over and over (he meant other VMs or just wrong stop condition), he can easily fill out his storage domain, or waste a lot of time before discovering the mistake since we don't return error but silently clone as new, Again the options above should be suffice to prevent that, if the user decides to to use with the force overrider or always clone, that is his problem. Third one, convenience: Assume a user has a VM on setup1, and wants a similar but not identical setup2. The reason is that he may want some day to move the VM to setup2. There is no support at all for this scenario. it will be either, the VM is imported as is and if he wants to move over the original VM it will have to be cloned (Thus changed). Or he can import and clone now (redundant copy operation) - The use case here is similar for the clone VM functionality but the clone is into a different setup. We should not always assume that it's fine to have identical VMs on different setups. I can think of some more if it's really necessary : Bottom line: Having this now will save at least 3 RFEs coming from the reasoning above and in a very reasonable price. All we have to do is to allow a checkbox in the import menu and stop assuming that we know better then the user what he wants to do. If you have a functionality that on one hand makes a novice user life easier while on the other hand may restrict advanced users, allow to choose - just have the defaults set to the case you think is the most common. The said above assumes clone on import changes everything including image IDs otherwise all the said above is a moot point. * Now in more advanced scenarios, use may be able to change everything he's allowed to change - same as when he does "Clone VM from template". But this is extension to simple clone case, with the price of going to the VM properties and edit it is solvable. * If override is complex for now, then reject if not specifically stated to clone (in the API) and Question to Copy As or Cancel is also reasonable. The user can always choose cancel and delete before trying again.
Thanks, Gilad.
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Gilad Chaplik" <gchaplik@redhat.com> Cc: "Michael Pasternak" <mpastern@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Itamar Heim" <iheim@redhat.com> Sent: Thursday, May 17, 2012 9:43:45 AM Subject: Re: [Engine-devel] restapi: New params for import VM/Template
Going FW it would be nice to override parameters in import vm/template
I agree with you and that's why -
As a user I don't think there should be a difference in the API between: - Importing a VM and changing it's name - Importing a VM for the second time
The reason you want to add artificial difference between the two scenarios above is because currently there are implementations limitations (changing the image ID while importing is not supported yet)
I think that we should solve the limitations in the implementation instead of making our API cumbersome (implicit clone by name and adding some clone entity are both bad IMO).
Livnat
On 05/17/2012 09:43 AM, Livnat Peer wrote:
Going FW it would be nice to override parameters in import vm/template
I agree with you and that's why -
As a user I don't think there should be a difference in the API between: - Importing a VM and changing it's name - Importing a VM for the second time
The reason you want to add artificial difference between the two scenarios above is because currently there are implementations limitations (changing the image ID while importing is not supported yet)
I think that we should solve the limitations in the implementation instead of making our API cumbersome (implicit clone by name and adding some clone entity are both bad IMO).
1. please read carefully my previous email with pseudocode on this thread (it also works for if_exist by id), it's enabling parameters override and it's not /implicit clone by name/, but explicit error when clone is required. 2. the solution i suggested is in engine and not api.
Livnat
-- Michael Pasternak RedHat, ENG-Virtualization R&D
participants (6)
-
Gilad Chaplik -
Itamar Heim -
Livnat Peer -
Michael Pasternak -
Ori Liel -
Simon Grinberg