[Engine-devel] the future of template cloning
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template. so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Jon Choate" <jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, January 12, 2012 8:44:56 AM Subject: Re: [Engine-devel] the future of template cloning
On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/12/2012 03:50 PM, Jon Choate wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, January 12, 2012 8:44:56 AM Subject: Re: [Engine-devel] the future of template cloning
On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
yes, since I may want to create virtual machines from this template where the 2nd disk is sometimes on SD1 and sometime on SD2 (just like today, where i can instantiate a VM from the template on multiple storage domains) The new feature will just allow me to not clone all the disks of the template to all storage domains, rather a subset.
On 01/12/2012 03:50 PM, Jon Choate wrote:
On Thu, Jan 12, 2012 at 8:44:56PM, Itamar Heim wrote: On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
yes, since I may want to create virtual machines from this template where the 2nd disk is sometimes on SD1 and sometime on SD2 (just like today, where i can instantiate a VM from the template on multiple storage domains) The new feature will just allow me to not clone all the disks of the template to all storage domains, rather a subset. But would this be interesting to the user or would it be better to do
On Thu, Jan 12, 2012 at 03:56:05PM +0200, Itamar Heim wrote: this transparently so the user doesn't have to care? The user just wants to use template X and store it on storage domain Y with COW. The system could deduce it has to be cloned first and not bother the user.
On 01/12/2012 04:04 PM, Ewoud Kohl van Wijngaarden wrote:
On 01/12/2012 03:50 PM, Jon Choate wrote:
On Thu, Jan 12, 2012 at 8:44:56PM, Itamar Heim wrote: On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
yes, since I may want to create virtual machines from this template where the 2nd disk is sometimes on SD1 and sometime on SD2 (just like today, where i can instantiate a VM from the template on multiple storage domains) The new feature will just allow me to not clone all the disks of the template to all storage domains, rather a subset. But would this be interesting to the user or would it be better to do
On Thu, Jan 12, 2012 at 03:56:05PM +0200, Itamar Heim wrote: this transparently so the user doesn't have to care? The user just wants to use template X and store it on storage domain Y with COW. The system could deduce it has to be cloned first and not bother the user.
that means a user would be able to affect where the template resides. user may not have permissions to do so, would require to configure which quota this will happen from, etc. so I'm not sure doing it implicitly based on a user trying to create a disk on a domain.
On Thu, Jan 12, 2012 at 05:50:56PM +0200, Itamar Heim wrote:
On 01/12/2012 04:04 PM, Ewoud Kohl van Wijngaarden wrote:
On 01/12/2012 03:50 PM, Jon Choate wrote:
On Thu, Jan 12, 2012 at 8:44:56PM, Itamar Heim wrote: On 01/12/2012 02:19 PM, Jon Choate wrote:
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
yes, since I may want to create virtual machines from this template where the 2nd disk is sometimes on SD1 and sometime on SD2 (just like today, where i can instantiate a VM from the template on multiple storage domains) The new feature will just allow me to not clone all the disks of the template to all storage domains, rather a subset. But would this be interesting to the user or would it be better to do
On Thu, Jan 12, 2012 at 03:56:05PM +0200, Itamar Heim wrote: this transparently so the user doesn't have to care? The user just wants to use template X and store it on storage domain Y with COW. The system could deduce it has to be cloned first and not bother the user.
that means a user would be able to affect where the template resides. user may not have permissions to do so, would require to configure which quota this will happen from, etc. so I'm not sure doing it implicitly based on a user trying to create a disk on a domain. For my point of view I assume templates are immutable so a copy only wastes space but I don't see how that matters in this case. If the user has no permission to copy a template, [s]he has to make full copy of the template to create the VM anyway. Making a copy and then create a thin COW VM consumes the same amount of space with as benefit that additional VMs based on the template can also use COW.
Side note: I haven't at oVirt and my experience is based on RHEV 2.2, so maybe I've overlooking several new features that would limit this.
On 01/12/2012 06:47 PM, Ewoud Kohl van Wijngaarden wrote:
On Thu, Jan 12, 2012 at 05:50:56PM +0200, Itamar Heim wrote:
On 01/12/2012 04:04 PM, Ewoud Kohl van Wijngaarden wrote:
On 01/12/2012 03:50 PM, Jon Choate wrote:
On Thu, Jan 12, 2012 at 8:44:56PM, Itamar Heim wrote: On 01/12/2012 02:19 PM, Jon Choate wrote: > We are going to be able to store the disks for a template on > different storage domains due to the multiple storage domain > feature. Cloning a template will still be possible, but will it > provide any value? Thoughts?
you would want to clone the disks to the storage domains you would want to create thinly provisioned disks from for this template.
so a template could have disk1 and disk2 on SD1, then disk2 cloned to SD2 to allow creating a VM with thin COW for disk2 on SD2 as well.
But with the ability to create a template with disk 1 on SD1 and disk2 on SD2 is that still a compelling feature?
yes, since I may want to create virtual machines from this template where the 2nd disk is sometimes on SD1 and sometime on SD2 (just like today, where i can instantiate a VM from the template on multiple storage domains) The new feature will just allow me to not clone all the disks of the template to all storage domains, rather a subset. But would this be interesting to the user or would it be better to do
On Thu, Jan 12, 2012 at 03:56:05PM +0200, Itamar Heim wrote: this transparently so the user doesn't have to care? The user just wants to use template X and store it on storage domain Y with COW. The system could deduce it has to be cloned first and not bother the user.
that means a user would be able to affect where the template resides. user may not have permissions to do so, would require to configure which quota this will happen from, etc. so I'm not sure doing it implicitly based on a user trying to create a disk on a domain. For my point of view I assume templates are immutable so a copy only wastes space but I don't see how that matters in this case. If the user has no permission to copy a template, [s]he has to make full copy of the template to create the VM anyway. Making a copy and then create a thin COW VM consumes the same amount of space with as benefit that additional VMs based on the template can also use COW.
my point is there would be a difference between the admin pre-populating the template on the storage domains they wish to allow thinly provisioned VMs from it, from the admin quota.
Side note: I haven't at oVirt and my experience is based on RHEV 2.2, so maybe I've overlooking several new features that would limit this.
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
I see no relation between the two options. Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains. Scenario 2: same thing with multiple disks on same domain. Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts?
I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon, After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have. This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb. The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). Livnat
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
Livnat
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk)
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message -----
We are going to be able to store the disks for a template on different storage domains due to the multiple storage domain feature. Cloning a template will still be possible, but will it provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
----- Original Message -----
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message ----- > We are going to be able to store the disks for a template on > different storage domains due to the multiple storage domain > feature. Cloning a template will still be possible, but will > it > provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
Just bear in mind that user should still be able to export an entire template (should be single action to choose export domain and that's it). When importing a template, user should be able to specify per disk the destination domain. (default should keep all disks in same domain) When creating a VM from template there should still be a default for each disk, preferably user configurable default (it would be very annoying to deploy 20 VMs from the template and changing the default every time). Clone VM from template should allow user to choose per disk *any* storage domain even if it doesn't have a copy of the template disk. I'm assuming template versioning would require user to recopy all the disks, I would add a checkbox to initiate copy to the same domains as the parent template. If child template has additional disks - no special treatment should be given (user can later on copy those disks wherever she chooses)
On 01/16/2012 01:58 PM, Ayal Baron wrote:
----- Original Message -----
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 12/01/12 22:45, Ayal Baron wrote: > ----- Original Message ----- >> We are going to be able to store the disks for a template on >> different storage domains due to the multiple storage domain >> feature. Cloning a template will still be possible, but will >> it >> provide any value? Thoughts? > I see no relation between the two options. > > Scenario 1: I can create a VM with a single disk and create a > template from it. > I would still want to be able to clone the template in order to > provision VMs from it on different domains. > > Scenario 2: same thing with multiple disks on same domain. > > Scenario 3: I have a template with 2 disks on 2 different > domains > (domain A and domain B) and I want to have another copy of the > template on domain C and domain D > Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from? yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create
On 01/16/2012 05:46 PM, Jon Choate wrote: them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
On 01/16/2012 06:16 PM, Jon Choate wrote: pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
Just bear in mind that user should still be able to export an entire template (should be single action to choose export domain and that's it).
When importing a template, user should be able to specify per disk the destination domain. (default should keep all disks in same domain)
When creating a VM from template there should still be a default for each disk, preferably user configurable default (it would be very annoying to deploy 20 VMs from the template and changing the default every time).
Clone VM from template should allow user to choose per disk *any* storage domain even if it doesn't have a copy of the template disk.
Does this imply that we would copy the template behind the scenes for them or does it mean we are going to let them put the disk in a place where it can't work?
I'm assuming template versioning would require user to recopy all the disks, I would add a checkbox to initiate copy to the same domains as the parent template. If child template has additional disks - no special treatment should be given (user can later on copy those disks wherever she chooses)
----- Original Message -----
On 01/16/2012 01:58 PM, Ayal Baron wrote:
----- Original Message -----
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 09:46 AM, Livnat Peer wrote: > On 12/01/12 22:45, Ayal Baron wrote: >> ----- Original Message ----- >>> We are going to be able to store the disks for a template on >>> different storage domains due to the multiple storage domain >>> feature. Cloning a template will still be possible, but will >>> it >>> provide any value? Thoughts? >> I see no relation between the two options. >> >> Scenario 1: I can create a VM with a single disk and create a >> template from it. >> I would still want to be able to clone the template in order >> to >> provision VMs from it on different domains. >> >> Scenario 2: same thing with multiple disks on same domain. >> >> Scenario 3: I have a template with 2 disks on 2 different >> domains >> (domain A and domain B) and I want to have another copy of >> the >> template on domain C and domain D >> > Hi Jon, > > After talking to Michael Pasternak it seems that we did not > implemented > copyTemplate in the REST API, it seems to be a gap that we > have. > > This gap is playing in our favor, we can remove the > copyTemplate > verb > and introduce copyDisk verb. > > The template disks can be copied to another SD. > When creating a VM from template the user can choose per disk > the > destination SD (only SD with the disks are eligible > candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as the template disks they were created from? yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create
On 01/16/2012 05:46 PM, Jon Choate wrote: them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
On 01/16/2012 06:16 PM, Jon Choate wrote: pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
Just bear in mind that user should still be able to export an entire template (should be single action to choose export domain and that's it).
When importing a template, user should be able to specify per disk the destination domain. (default should keep all disks in same domain)
When creating a VM from template there should still be a default for each disk, preferably user configurable default (it would be very annoying to deploy 20 VMs from the template and changing the default every time).
Clone VM from template should allow user to choose per disk *any* storage domain even if it doesn't have a copy of the template disk.
Does this imply that we would copy the template behind the scenes for them or does it mean we are going to let them put the disk in a place where it can't work?
Please empty lines to separate your responses, it is really difficult to find them. Anyway, clone VM copies all the bits and does not require the template. Create VM from template without clone would only allow specifying per disk domains that have a copy of the template disk.
I'm assuming template versioning would require user to recopy all the disks, I would add a checkbox to initiate copy to the same domains as the parent template. If child template has additional disks - no special treatment should be given (user can later on copy those disks wherever she chooses)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Jon Choate" <jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote:
----- Original Message ----- > We are going to be able to store the disks for a template on > different storage domains due to the multiple storage domain > feature. Cloning a template will still be possible, but will > it > provide any value? Thoughts? I see no relation between the two options.
Scenario 1: I can create a VM with a single disk and create a template from it. I would still want to be able to clone the template in order to provision VMs from it on different domains.
Scenario 2: same thing with multiple disks on same domain.
Scenario 3: I have a template with 2 disks on 2 different domains (domain A and domain B) and I want to have another copy of the template on domain C and domain D
Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?), what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 12/01/12 22:45, Ayal Baron wrote: > > ----- Original Message ----- >> We are going to be able to store the disks for a template on >> different storage domains due to the multiple storage domain >> feature. Cloning a template will still be possible, but will >> it >> provide any value? Thoughts? > I see no relation between the two options. > > Scenario 1: I can create a VM with a single disk and create a > template from it. > I would still want to be able to clone the template in order to > provision VMs from it on different domains. > > Scenario 2: same thing with multiple disks on same domain. > > Scenario 3: I have a template with 2 disks on 2 different > domains > (domain A and domain B) and I want to have another copy of the > template on domain C and domain D > Hi Jon,
After talking to Michael Pasternak it seems that we did not implemented copyTemplate in the REST API, it seems to be a gap that we have.
This gap is playing in our favor, we can remove the copyTemplate verb and introduce copyDisk verb.
The template disks can be copied to another SD. When creating a VM from template the user can choose per disk the destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as
On 01/16/2012 09:46 AM, Livnat Peer wrote: the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote:
On 01/16/2012 09:46 AM, Livnat Peer wrote: > On 12/01/12 22:45, Ayal Baron wrote: >> >> ----- Original Message ----- >>> We are going to be able to store the disks for a template on >>> different storage domains due to the multiple storage domain >>> feature. Cloning a template will still be possible, but will >>> it >>> provide any value? Thoughts? >> I see no relation between the two options. >> >> Scenario 1: I can create a VM with a single disk and create a >> template from it. >> I would still want to be able to clone the template in order to >> provision VMs from it on different domains. >> >> Scenario 2: same thing with multiple disks on same domain. >> >> Scenario 3: I have a template with 2 disks on 2 different >> domains >> (domain A and domain B) and I want to have another copy of the >> template on domain C and domain D >> > Hi Jon, > > After talking to Michael Pasternak it seems that we did not > implemented > copyTemplate in the REST API, it seems to be a gap that we have. > > This gap is playing in our favor, we can remove the copyTemplate > verb > and introduce copyDisk verb. > > The template disks can be copied to another SD. > When creating a VM from template the user can choose per disk > the > destination SD (only SD with the disks are eligible candidates). wait, when creating a VM from a template, the user won't get a choice will they? Won't the VM disks have to go on the same storage domain as the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote:
On 01/16/2012 05:46 PM, Jon Choate wrote: > On 01/16/2012 09:46 AM, Livnat Peer wrote: >> On 12/01/12 22:45, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> We are going to be able to store the disks for a template >>>> on >>>> different storage domains due to the multiple storage >>>> domain >>>> feature. Cloning a template will still be possible, but >>>> will >>>> it >>>> provide any value? Thoughts? >>> I see no relation between the two options. >>> >>> Scenario 1: I can create a VM with a single disk and create >>> a >>> template from it. >>> I would still want to be able to clone the template in order >>> to >>> provision VMs from it on different domains. >>> >>> Scenario 2: same thing with multiple disks on same domain. >>> >>> Scenario 3: I have a template with 2 disks on 2 different >>> domains >>> (domain A and domain B) and I want to have another copy of >>> the >>> template on domain C and domain D >>> >> Hi Jon, >> >> After talking to Michael Pasternak it seems that we did not >> implemented >> copyTemplate in the REST API, it seems to be a gap that we >> have. >> >> This gap is playing in our favor, we can remove the >> copyTemplate >> verb >> and introduce copyDisk verb. >> >> The template disks can be copied to another SD. >> When creating a VM from template the user can choose per disk >> the >> destination SD (only SD with the disks are eligible >> candidates). > wait, when creating a VM from a template, the user won't get a > choice > will they? Won't the VM disks have to go on the same storage > domain as > the template disks they were created from?
yes, but the template disks can be copied to multiple storage domains, so the user can choose for the VM/disk which storage domain to create them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 17/01/12 11:45, Ayal Baron wrote:
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote: > On 01/16/2012 05:46 PM, Jon Choate wrote: >> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>> On 12/01/12 22:45, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> We are going to be able to store the disks for a template >>>>> on >>>>> different storage domains due to the multiple storage >>>>> domain >>>>> feature. Cloning a template will still be possible, but >>>>> will >>>>> it >>>>> provide any value? Thoughts? >>>> I see no relation between the two options. >>>> >>>> Scenario 1: I can create a VM with a single disk and create >>>> a >>>> template from it. >>>> I would still want to be able to clone the template in order >>>> to >>>> provision VMs from it on different domains. >>>> >>>> Scenario 2: same thing with multiple disks on same domain. >>>> >>>> Scenario 3: I have a template with 2 disks on 2 different >>>> domains >>>> (domain A and domain B) and I want to have another copy of >>>> the >>>> template on domain C and domain D >>>> >>> Hi Jon, >>> >>> After talking to Michael Pasternak it seems that we did not >>> implemented >>> copyTemplate in the REST API, it seems to be a gap that we >>> have. >>> >>> This gap is playing in our favor, we can remove the >>> copyTemplate >>> verb >>> and introduce copyDisk verb. >>> >>> The template disks can be copied to another SD. >>> When creating a VM from template the user can choose per disk >>> the >>> destination SD (only SD with the disks are eligible >>> candidates). >> wait, when creating a VM from a template, the user won't get a >> choice >> will they? Won't the VM disks have to go on the same storage >> domain as >> the template disks they were created from? > > yes, but the template disks can be copied to multiple storage > domains, > so the user can choose for the VM/disk which storage domain to > create > them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects.
Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action.
We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing.
If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote: > On 01/16/2012 10:58 AM, Itamar Heim wrote: >> On 01/16/2012 05:46 PM, Jon Choate wrote: >>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>> ----- Original Message ----- >>>>>> We are going to be able to store the disks for a template >>>>>> on >>>>>> different storage domains due to the multiple storage >>>>>> domain >>>>>> feature. Cloning a template will still be possible, but >>>>>> will >>>>>> it >>>>>> provide any value? Thoughts? >>>>> I see no relation between the two options. >>>>> >>>>> Scenario 1: I can create a VM with a single disk and create >>>>> a >>>>> template from it. >>>>> I would still want to be able to clone the template in order >>>>> to >>>>> provision VMs from it on different domains. >>>>> >>>>> Scenario 2: same thing with multiple disks on same domain. >>>>> >>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>> domains >>>>> (domain A and domain B) and I want to have another copy of >>>>> the >>>>> template on domain C and domain D >>>>> >>>> Hi Jon, >>>> >>>> After talking to Michael Pasternak it seems that we did not >>>> implemented >>>> copyTemplate in the REST API, it seems to be a gap that we >>>> have. >>>> >>>> This gap is playing in our favor, we can remove the >>>> copyTemplate >>>> verb >>>> and introduce copyDisk verb. >>>> >>>> The template disks can be copied to another SD. >>>> When creating a VM from template the user can choose per disk >>>> the >>>> destination SD (only SD with the disks are eligible >>>> candidates). >>> wait, when creating a VM from a template, the user won't get a >>> choice >>> will they? Won't the VM disks have to go on the same storage >>> domain as >>> the template disks they were created from? >> yes, but the template disks can be copied to multiple storage >> domains, >> so the user can choose for the VM/disk which storage domain to >> create >> them from (per storage domains that have copies of that disk) > OH! I totally misunderstood. So what you are saying is that a > template > can have N number of copies of the same disk each on a different > storage > domain. I had thought that if you wanted that type of situation > you > would have multiple copies of the template itself too. yes, one copy of disk per domain though.
> Just to be clear, does this mean that the plan is to phase out > the > current clone template command and instead implementing a clone > disk > command so that a template can duplicate its disks individually? pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task. we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain. Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be?
----- Original Message -----
From: "Jon Choate" <jchoate@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message ----- > From: "Itamar Heim"<iheim@redhat.com> > To: "Jon Choate"<jchoate@redhat.com> > Cc: engine-devel@ovirt.org > Sent: Monday, January 16, 2012 7:26:24 PM > Subject: Re: [Engine-devel] the future of template cloning > > On 01/16/2012 06:16 PM, Jon Choate wrote: >> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>> ----- Original Message ----- >>>>>>> We are going to be able to store the disks for a >>>>>>> template >>>>>>> on >>>>>>> different storage domains due to the multiple storage >>>>>>> domain >>>>>>> feature. Cloning a template will still be possible, but >>>>>>> will >>>>>>> it >>>>>>> provide any value? Thoughts? >>>>>> I see no relation between the two options. >>>>>> >>>>>> Scenario 1: I can create a VM with a single disk and >>>>>> create >>>>>> a >>>>>> template from it. >>>>>> I would still want to be able to clone the template in >>>>>> order >>>>>> to >>>>>> provision VMs from it on different domains. >>>>>> >>>>>> Scenario 2: same thing with multiple disks on same >>>>>> domain. >>>>>> >>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>> domains >>>>>> (domain A and domain B) and I want to have another copy >>>>>> of >>>>>> the >>>>>> template on domain C and domain D >>>>>> >>>>> Hi Jon, >>>>> >>>>> After talking to Michael Pasternak it seems that we did >>>>> not >>>>> implemented >>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>> have. >>>>> >>>>> This gap is playing in our favor, we can remove the >>>>> copyTemplate >>>>> verb >>>>> and introduce copyDisk verb. >>>>> >>>>> The template disks can be copied to another SD. >>>>> When creating a VM from template the user can choose per >>>>> disk >>>>> the >>>>> destination SD (only SD with the disks are eligible >>>>> candidates). >>>> wait, when creating a VM from a template, the user won't >>>> get a >>>> choice >>>> will they? Won't the VM disks have to go on the same >>>> storage >>>> domain as >>>> the template disks they were created from? >>> yes, but the template disks can be copied to multiple >>> storage >>> domains, >>> so the user can choose for the VM/disk which storage domain >>> to >>> create >>> them from (per storage domains that have copies of that >>> disk) >> OH! I totally misunderstood. So what you are saying is that a >> template >> can have N number of copies of the same disk each on a >> different >> storage >> domain. I had thought that if you wanted that type of >> situation >> you >> would have multiple copies of the template itself too. yes, one copy of disk per domain though.
>> Just to be clear, does this mean that the plan is to phase >> out >> the >> current clone template command and instead implementing a >> clone >> disk >> command so that a template can duplicate its disks >> individually? > pretty much, yes. > though i'd imagine 'clone template' would still be useful to > have > for > the user. not sure if it implies core should expose it as well > to > allow > easier usage at UI level for such a task. we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on
----- Original Message ----- the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
> _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain.
Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be?
fine by me, although i think we should remove the clone template (actually called copy template), as i think the copy disk gives a way to do it, with more granularity, and the user will know exactly what to expect. unfortunately, there is another issue, currently, since template can be fully on a domain or not, remove template can get list of storage domains to remove the template from, and if the list contains all the domain the template is on, the template is fully deleted from the db, if its partial, then only the copies of the disks are removed from the domain. what i suggest is, making it simple: remove template will remove the template, and all of the disks copies from all the domains. we will need new removeTemplateDisk command that will remove a disk from a domain, as long there is another copy of the disk. if its the last copy it should fail, as removing the disk from all the domains will change the template, which is not a supported flow. thoughts?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
----- Original Message -----
From: "Jon Choate" <jchoate@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote: > > ----- Original Message ----- >> From: "Itamar Heim"<iheim@redhat.com> >> To: "Jon Choate"<jchoate@redhat.com> >> Cc: engine-devel@ovirt.org >> Sent: Monday, January 16, 2012 7:26:24 PM >> Subject: Re: [Engine-devel] the future of template cloning >> >> On 01/16/2012 06:16 PM, Jon Choate wrote: >>> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>>> ----- Original Message ----- >>>>>>>> We are going to be able to store the disks for a >>>>>>>> template >>>>>>>> on >>>>>>>> different storage domains due to the multiple storage >>>>>>>> domain >>>>>>>> feature. Cloning a template will still be possible, >>>>>>>> but >>>>>>>> will >>>>>>>> it >>>>>>>> provide any value? Thoughts? >>>>>>> I see no relation between the two options. >>>>>>> >>>>>>> Scenario 1: I can create a VM with a single disk and >>>>>>> create >>>>>>> a >>>>>>> template from it. >>>>>>> I would still want to be able to clone the template in >>>>>>> order >>>>>>> to >>>>>>> provision VMs from it on different domains. >>>>>>> >>>>>>> Scenario 2: same thing with multiple disks on same >>>>>>> domain. >>>>>>> >>>>>>> Scenario 3: I have a template with 2 disks on 2 >>>>>>> different >>>>>>> domains >>>>>>> (domain A and domain B) and I want to have another copy >>>>>>> of >>>>>>> the >>>>>>> template on domain C and domain D >>>>>>> >>>>>> Hi Jon, >>>>>> >>>>>> After talking to Michael Pasternak it seems that we did >>>>>> not >>>>>> implemented >>>>>> copyTemplate in the REST API, it seems to be a gap that >>>>>> we >>>>>> have. >>>>>> >>>>>> This gap is playing in our favor, we can remove the >>>>>> copyTemplate >>>>>> verb >>>>>> and introduce copyDisk verb. >>>>>> >>>>>> The template disks can be copied to another SD. >>>>>> When creating a VM from template the user can choose per >>>>>> disk >>>>>> the >>>>>> destination SD (only SD with the disks are eligible >>>>>> candidates). >>>>> wait, when creating a VM from a template, the user won't >>>>> get a >>>>> choice >>>>> will they? Won't the VM disks have to go on the same >>>>> storage >>>>> domain as >>>>> the template disks they were created from? >>>> yes, but the template disks can be copied to multiple >>>> storage >>>> domains, >>>> so the user can choose for the VM/disk which storage >>>> domain >>>> to >>>> create >>>> them from (per storage domains that have copies of that >>>> disk) >>> OH! I totally misunderstood. So what you are saying is that >>> a >>> template >>> can have N number of copies of the same disk each on a >>> different >>> storage >>> domain. I had thought that if you wanted that type of >>> situation >>> you >>> would have multiple copies of the template itself too. > yes, one copy of disk per domain though. > >>> Just to be clear, does this mean that the plan is to phase >>> out >>> the >>> current clone template command and instead implementing a >>> clone >>> disk >>> command so that a template can duplicate its disks >>> individually? >> pretty much, yes. >> though i'd imagine 'clone template' would still be useful to >> have >> for >> the user. not sure if it implies core should expose it as >> well >> to >> allow >> easier usage at UI level for such a task. > we can leave it untouched - means copyTemplate get 1 > destination > domain, and copies all disks to it, > but i think it will be unusable (and problematic - what if > one > of > the > disks already exists on the destination?), then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on
----- Original Message ----- the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
> what the user really wants is to specify which disks to copy > and destination per disk, and i don't see a reason to create > a > backend > command to do it > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain.
Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be?
fine by me, although i think we should remove the clone template (actually called copy template), as i think the copy disk gives a way to do it, with more granularity, and the user will know exactly what to expect.
unfortunately, there is another issue, currently, since template can be fully on a domain or not, remove template can get list of storage domains to remove the template from, and if the list contains all the domain the template is on, the template is fully deleted from the db, if its partial, then only the copies of the disks are removed from the domain.
what i suggest is, making it simple: remove template will remove the template, and all of the disks copies from all the domains. we will need new removeTemplateDisk command that will remove a disk from a domain, as long there is another copy of the disk. if its the last copy it should fail, as removing the disk from all the domains will change the template, which is not a supported flow.
thoughts?
This of course needs to be supported in clients, but how exactly will the user keep track of where each disk of the template resides?
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 17/01/12 17:04, Omer Frenkel wrote:
----- Original Message -----
From: "Jon Choate" <jchoate@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote: > > ----- Original Message ----- >> From: "Itamar Heim"<iheim@redhat.com> >> To: "Jon Choate"<jchoate@redhat.com> >> Cc: engine-devel@ovirt.org >> Sent: Monday, January 16, 2012 7:26:24 PM >> Subject: Re: [Engine-devel] the future of template cloning >> >> On 01/16/2012 06:16 PM, Jon Choate wrote: >>> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>>> ----- Original Message ----- >>>>>>>> We are going to be able to store the disks for a >>>>>>>> template >>>>>>>> on >>>>>>>> different storage domains due to the multiple storage >>>>>>>> domain >>>>>>>> feature. Cloning a template will still be possible, but >>>>>>>> will >>>>>>>> it >>>>>>>> provide any value? Thoughts? >>>>>>> I see no relation between the two options. >>>>>>> >>>>>>> Scenario 1: I can create a VM with a single disk and >>>>>>> create >>>>>>> a >>>>>>> template from it. >>>>>>> I would still want to be able to clone the template in >>>>>>> order >>>>>>> to >>>>>>> provision VMs from it on different domains. >>>>>>> >>>>>>> Scenario 2: same thing with multiple disks on same >>>>>>> domain. >>>>>>> >>>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>>> domains >>>>>>> (domain A and domain B) and I want to have another copy >>>>>>> of >>>>>>> the >>>>>>> template on domain C and domain D >>>>>>> >>>>>> Hi Jon, >>>>>> >>>>>> After talking to Michael Pasternak it seems that we did >>>>>> not >>>>>> implemented >>>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>>> have. >>>>>> >>>>>> This gap is playing in our favor, we can remove the >>>>>> copyTemplate >>>>>> verb >>>>>> and introduce copyDisk verb. >>>>>> >>>>>> The template disks can be copied to another SD. >>>>>> When creating a VM from template the user can choose per >>>>>> disk >>>>>> the >>>>>> destination SD (only SD with the disks are eligible >>>>>> candidates). >>>>> wait, when creating a VM from a template, the user won't >>>>> get a >>>>> choice >>>>> will they? Won't the VM disks have to go on the same >>>>> storage >>>>> domain as >>>>> the template disks they were created from? >>>> yes, but the template disks can be copied to multiple >>>> storage >>>> domains, >>>> so the user can choose for the VM/disk which storage domain >>>> to >>>> create >>>> them from (per storage domains that have copies of that >>>> disk) >>> OH! I totally misunderstood. So what you are saying is that a >>> template >>> can have N number of copies of the same disk each on a >>> different >>> storage >>> domain. I had thought that if you wanted that type of >>> situation >>> you >>> would have multiple copies of the template itself too. > yes, one copy of disk per domain though. > >>> Just to be clear, does this mean that the plan is to phase >>> out >>> the >>> current clone template command and instead implementing a >>> clone >>> disk >>> command so that a template can duplicate its disks >>> individually? >> pretty much, yes. >> though i'd imagine 'clone template' would still be useful to >> have >> for >> the user. not sure if it implies core should expose it as well >> to >> allow >> easier usage at UI level for such a task. > we can leave it untouched - means copyTemplate get 1 > destination > domain, and copies all disks to it, > but i think it will be unusable (and problematic - what if one > of > the > disks already exists on the destination?), then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on
----- Original Message ----- the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
> what the user really wants is to specify which disks to copy > and destination per disk, and i don't see a reason to create a > backend > command to do it > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain.
Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be?
fine by me, although i think we should remove the clone template (actually called copy template), as i think the copy disk gives a way to do it, with more granularity, and the user will know exactly what to expect.
We are removing the cloneTemplate and introducing cloneTemplatedisk, following the above discussion does anyone have strong objection for doing this?
unfortunately, there is another issue, currently, since template can be fully on a domain or not, remove template can get list of storage domains to remove the template from, and if the list contains all the domain the template is on, the template is fully deleted from the db, if its partial, then only the copies of the disks are removed from the domain.
Worth Noting that we have another REST API gap that we can use in our favor, the delete template from storage domain is not modeled yet and we don't need to support it.
what i suggest is, making it simple: remove template will remove the template, and all of the disks copies from all the domains.
+1 for that approach.
we will need new removeTemplateDisk command that will remove a disk from a domain, as long there is another copy of the disk. if its the last copy it should fail, as removing the disk from all the domains will change the template, which is not a supported flow.
thoughts?
I would implement a single verb - removeDisk, it has optional parameter storage domain. If the storage domain is not specified it is simply removing a disk (for template, VM or floating) if a SD is specified in case there is only one image that represent this disk (the only use case for VMs) we remove the disk (same as no passing no SD except for extra validation) if more than one image is associated with this disk (the image-SD map has more than one entry) then remove the relevant mapping. Note: in case of deleting the disk and there is only one image associated with the disk we should remove the device from the vm_devices table as well. Implementing a single generic verb makes it easier to keep backwards compatibility when the model changes. Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/17/2012 10:49 AM, Livnat Peer wrote:
On 17/01/12 17:04, Omer Frenkel wrote:
----- Original Message -----
From: "Jon Choate"<jchoate@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
On 17/01/12 10:46, Itamar Heim wrote: > On 01/17/2012 10:32 AM, Omer Frenkel wrote: >> ----- Original Message ----- >>> From: "Itamar Heim"<iheim@redhat.com> >>> To: "Jon Choate"<jchoate@redhat.com> >>> Cc: engine-devel@ovirt.org >>> Sent: Monday, January 16, 2012 7:26:24 PM >>> Subject: Re: [Engine-devel] the future of template cloning >>> >>> On 01/16/2012 06:16 PM, Jon Choate wrote: >>>> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>>>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>>>> ----- Original Message ----- >>>>>>>>> We are going to be able to store the disks for a >>>>>>>>> template >>>>>>>>> on >>>>>>>>> different storage domains due to the multiple storage >>>>>>>>> domain >>>>>>>>> feature. Cloning a template will still be possible, but >>>>>>>>> will >>>>>>>>> it >>>>>>>>> provide any value? Thoughts? >>>>>>>> I see no relation between the two options. >>>>>>>> >>>>>>>> Scenario 1: I can create a VM with a single disk and >>>>>>>> create >>>>>>>> a >>>>>>>> template from it. >>>>>>>> I would still want to be able to clone the template in >>>>>>>> order >>>>>>>> to >>>>>>>> provision VMs from it on different domains. >>>>>>>> >>>>>>>> Scenario 2: same thing with multiple disks on same >>>>>>>> domain. >>>>>>>> >>>>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>>>> domains >>>>>>>> (domain A and domain B) and I want to have another copy >>>>>>>> of >>>>>>>> the >>>>>>>> template on domain C and domain D >>>>>>>> >>>>>>> Hi Jon, >>>>>>> >>>>>>> After talking to Michael Pasternak it seems that we did >>>>>>> not >>>>>>> implemented >>>>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>>>> have. >>>>>>> >>>>>>> This gap is playing in our favor, we can remove the >>>>>>> copyTemplate >>>>>>> verb >>>>>>> and introduce copyDisk verb. >>>>>>> >>>>>>> The template disks can be copied to another SD. >>>>>>> When creating a VM from template the user can choose per >>>>>>> disk >>>>>>> the >>>>>>> destination SD (only SD with the disks are eligible >>>>>>> candidates). >>>>>> wait, when creating a VM from a template, the user won't >>>>>> get a >>>>>> choice >>>>>> will they? Won't the VM disks have to go on the same >>>>>> storage >>>>>> domain as >>>>>> the template disks they were created from? >>>>> yes, but the template disks can be copied to multiple >>>>> storage >>>>> domains, >>>>> so the user can choose for the VM/disk which storage domain >>>>> to >>>>> create >>>>> them from (per storage domains that have copies of that >>>>> disk) >>>> OH! I totally misunderstood. So what you are saying is that a >>>> template >>>> can have N number of copies of the same disk each on a >>>> different >>>> storage >>>> domain. I had thought that if you wanted that type of >>>> situation >>>> you >>>> would have multiple copies of the template itself too. >> yes, one copy of disk per domain though. >> >>>> Just to be clear, does this mean that the plan is to phase >>>> out >>>> the >>>> current clone template command and instead implementing a >>>> clone >>>> disk >>>> command so that a template can duplicate its disks >>>> individually? >>> pretty much, yes. >>> though i'd imagine 'clone template' would still be useful to >>> have >>> for >>> the user. not sure if it implies core should expose it as well >>> to >>> allow >>> easier usage at UI level for such a task. >> we can leave it untouched - means copyTemplate get 1 >> destination >> domain, and copies all disks to it, >> but i think it will be unusable (and problematic - what if one >> of >> the >> disks already exists on the destination?), > then don't copy it, it is already there > I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on
----- Original Message ----- the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
>> what the user really wants is to specify which disks to copy >> and destination per disk, and i don't see a reason to create a >> backend >> command to do it >> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain.
Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be? fine by me, although i think we should remove the clone template (actually called copy template), as i think the copy disk gives a way to do it, with more granularity, and the user will know exactly what to expect.
We are removing the cloneTemplate and introducing cloneTemplatedisk, following the above discussion does anyone have strong objection for doing this?
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
unfortunately, there is another issue, currently, since template can be fully on a domain or not, remove template can get list of storage domains to remove the template from, and if the list contains all the domain the template is on, the template is fully deleted from the db, if its partial, then only the copies of the disks are removed from the domain.
Worth Noting that we have another REST API gap that we can use in our favor, the delete template from storage domain is not modeled yet and we don't need to support it.
what i suggest is, making it simple: remove template will remove the template, and all of the disks copies from all the domains. +1 for that approach.
we will need new removeTemplateDisk command that will remove a disk from a domain, as long there is another copy of the disk. if its the last copy it should fail, as removing the disk from all the domains will change the template, which is not a supported flow.
thoughts? I would implement a single verb - removeDisk, it has optional parameter storage domain. If the storage domain is not specified it is simply removing a disk (for template, VM or floating) if a SD is specified in case there is only one image that represent this disk (the only use case for VMs) we remove the disk (same as no passing no SD except for extra validation) if more than one image is associated with this disk (the image-SD map has more than one entry) then remove the relevant mapping.
Note: in case of deleting the disk and there is only one image associated with the disk we should remove the device from the vm_devices table as well.
Implementing a single generic verb makes it easier to keep backwards compatibility when the model changes.
Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 17/01/12 18:04, Jon Choate wrote:
On 01/17/2012 10:49 AM, Livnat Peer wrote:
On 17/01/12 17:04, Omer Frenkel wrote:
----- Original Message -----
From: "Jon Choate"<jchoate@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 3:52:34 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/17/2012 07:29 AM, Livnat Peer wrote:
On 17/01/12 11:45, Ayal Baron wrote:
----- Original Message ----- > On 17/01/12 10:46, Itamar Heim wrote: >> On 01/17/2012 10:32 AM, Omer Frenkel wrote: >>> ----- Original Message ----- >>>> From: "Itamar Heim"<iheim@redhat.com> >>>> To: "Jon Choate"<jchoate@redhat.com> >>>> Cc: engine-devel@ovirt.org >>>> Sent: Monday, January 16, 2012 7:26:24 PM >>>> Subject: Re: [Engine-devel] the future of template cloning >>>> >>>> On 01/16/2012 06:16 PM, Jon Choate wrote: >>>>> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>>>>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>>>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>>>>> ----- Original Message ----- >>>>>>>>>> We are going to be able to store the disks for a >>>>>>>>>> template >>>>>>>>>> on >>>>>>>>>> different storage domains due to the multiple storage >>>>>>>>>> domain >>>>>>>>>> feature. Cloning a template will still be possible, but >>>>>>>>>> will >>>>>>>>>> it >>>>>>>>>> provide any value? Thoughts? >>>>>>>>> I see no relation between the two options. >>>>>>>>> >>>>>>>>> Scenario 1: I can create a VM with a single disk and >>>>>>>>> create >>>>>>>>> a >>>>>>>>> template from it. >>>>>>>>> I would still want to be able to clone the template in >>>>>>>>> order >>>>>>>>> to >>>>>>>>> provision VMs from it on different domains. >>>>>>>>> >>>>>>>>> Scenario 2: same thing with multiple disks on same >>>>>>>>> domain. >>>>>>>>> >>>>>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>>>>> domains >>>>>>>>> (domain A and domain B) and I want to have another copy >>>>>>>>> of >>>>>>>>> the >>>>>>>>> template on domain C and domain D >>>>>>>>> >>>>>>>> Hi Jon, >>>>>>>> >>>>>>>> After talking to Michael Pasternak it seems that we did >>>>>>>> not >>>>>>>> implemented >>>>>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>>>>> have. >>>>>>>> >>>>>>>> This gap is playing in our favor, we can remove the >>>>>>>> copyTemplate >>>>>>>> verb >>>>>>>> and introduce copyDisk verb. >>>>>>>> >>>>>>>> The template disks can be copied to another SD. >>>>>>>> When creating a VM from template the user can choose per >>>>>>>> disk >>>>>>>> the >>>>>>>> destination SD (only SD with the disks are eligible >>>>>>>> candidates). >>>>>>> wait, when creating a VM from a template, the user won't >>>>>>> get a >>>>>>> choice >>>>>>> will they? Won't the VM disks have to go on the same >>>>>>> storage >>>>>>> domain as >>>>>>> the template disks they were created from? >>>>>> yes, but the template disks can be copied to multiple >>>>>> storage >>>>>> domains, >>>>>> so the user can choose for the VM/disk which storage domain >>>>>> to >>>>>> create >>>>>> them from (per storage domains that have copies of that >>>>>> disk) >>>>> OH! I totally misunderstood. So what you are saying is that a >>>>> template >>>>> can have N number of copies of the same disk each on a >>>>> different >>>>> storage >>>>> domain. I had thought that if you wanted that type of >>>>> situation >>>>> you >>>>> would have multiple copies of the template itself too. >>> yes, one copy of disk per domain though. >>> >>>>> Just to be clear, does this mean that the plan is to phase >>>>> out >>>>> the >>>>> current clone template command and instead implementing a >>>>> clone >>>>> disk >>>>> command so that a template can duplicate its disks >>>>> individually? >>>> pretty much, yes. >>>> though i'd imagine 'clone template' would still be useful to >>>> have >>>> for >>>> the user. not sure if it implies core should expose it as well >>>> to >>>> allow >>>> easier usage at UI level for such a task. >>> we can leave it untouched - means copyTemplate get 1 >>> destination >>> domain, and copies all disks to it, >>> but i think it will be unusable (and problematic - what if one >>> of >>> the >>> disks already exists on the destination?), >> then don't copy it, it is already there >> > I agree with Omer, there is no reason to support copy template, > if > the > user wants to clone all the disks he can use multiple actions, we > don't > need a specific verb for this. Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
> If the UI chooses to expose such operation it will use the > multipleRunAction API which makes it easier to expose to the user > partial success, we could clone disk A and Disk B but Disk C > failed > etc. The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Exactly, choosing the disks to copy to the storage domain.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
> >>> what the user really wants is to specify which disks to copy >>> and destination per disk, and i don't see a reason to create a >>> backend >>> command to do it >>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel I would like this discussion to continue but I need some short-term closure since I only have two days to get something into code. He is what I am proposing to do:
1) leave clone template as it is. It will try to copy all of the disks to the same storage domain. 2) Expose a copy disk command so that the user can select a single disk and create a copy of it on another storage domain.
Is everyone ok with starting there and then refining once we can reach more of a consensus on what the end product should be? fine by me, although i think we should remove the clone template (actually called copy template), as i think the copy disk gives a way to do it, with more granularity, and the user will know exactly what to expect.
We are removing the cloneTemplate and introducing cloneTemplatedisk, following the above discussion does anyone have strong objection for doing this?
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed. You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button. I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained.
unfortunately, there is another issue, currently, since template can be fully on a domain or not, remove template can get list of storage domains to remove the template from, and if the list contains all the domain the template is on, the template is fully deleted from the db, if its partial, then only the copies of the disks are removed from the domain.
Worth Noting that we have another REST API gap that we can use in our favor, the delete template from storage domain is not modeled yet and we don't need to support it.
what i suggest is, making it simple: remove template will remove the template, and all of the disks copies from all the domains. +1 for that approach.
we will need new removeTemplateDisk command that will remove a disk from a domain, as long there is another copy of the disk. if its the last copy it should fail, as removing the disk from all the domains will change the template, which is not a supported flow.
thoughts? I would implement a single verb - removeDisk, it has optional parameter storage domain. If the storage domain is not specified it is simply removing a disk (for template, VM or floating) if a SD is specified in case there is only one image that represent this disk (the only use case for VMs) we remove the disk (same as no passing no SD except for extra validation) if more than one image is associated with this disk (the image-SD map has more than one entry) then remove the relevant mapping.
Note: in case of deleting the disk and there is only one image associated with the disk we should remove the device from the vm_devices table as well.
Implementing a single generic verb makes it easier to keep backwards compatibility when the model changes.
Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/17/2012 06:35 PM, Livnat Peer wrote: ...
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed.
You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button.
I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained.
I don't think a patch which would make existing functionality disabled is the way to go. I expect a lot of times a new functionality will be added, and the old one should be flagged deprecated with a comment as to why (or open a BZ to self to clean it up), or collaborate with someone more knowledgeable on the specific component to make the change in sync, or do the patch yourself. to make less code deprecated, the old api could wrap the new functionality (call removeDisk in a loop, etc.). it should still be flagged as something to clean up once the api calling it is removed. obviously, collaborating (or doing it thyself) on a sync'd change is easiest, but not always possible.
On 18/01/12 00:46, Itamar Heim wrote:
On 01/17/2012 06:35 PM, Livnat Peer wrote: ...
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed.
You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button.
I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained.
I don't think a patch which would make existing functionality disabled is the way to go. I expect a lot of times a new functionality will be added, and the old one should be flagged deprecated with a comment as to why (or open a BZ to self to clean it up),
I don't expect that we'll remove functionality a lot of times, this was a gap in the API modeling that enabled us doing that. If i understand correctly then you expect to add the clone disk functionality to the UI before removing the clone template button. Let's assume this requires a rewrite of the command to work with the new DB schema, this would be a throw away code, should it be done? I think not. We have upstream releases which should be stable - preferably with no partial functionality, other than that there is a development going on in upstream and from time to time some of the functionality won't be fully ready, it does not mean the application is broken but a disabled button in the UI or something similar can be a valid state IMO. or collaborate with someone more knowledgeable
on the specific component to make the change in sync, or do the patch yourself.
to make less code deprecated, the old api could wrap the new functionality (call removeDisk in a loop, etc.). it should still be flagged as something to clean up once the api calling it is removed. obviously, collaborating (or doing it thyself) on a sync'd change is easiest, but not always possible.
On 01/18/2012 09:38 AM, Livnat Peer wrote:
On 18/01/12 00:46, Itamar Heim wrote:
On 01/17/2012 06:35 PM, Livnat Peer wrote: ...
We can't remove cloneTemplate until it is removed from the UI or else we will break functionality. For now we are just going to ensure that it works as it always has until the UI is ready to remove it.
If by ensure you mean you are going to do adjustments for the cloneTemplate code to work then it is not needed.
You can either send a patch to disable/remove this button from the UI or synchronize your patch with a patch from the UI that removes this button.
I don't like the approach of leaving the code because many times we end up with a code that is not used and not maintained.
I don't think a patch which would make existing functionality disabled is the way to go. I expect a lot of times a new functionality will be added, and the old one should be flagged deprecated with a comment as to why (or open a BZ to self to clean it up),
I don't expect that we'll remove functionality a lot of times, this was a gap in the API modeling that enabled us doing that.
If i understand correctly then you expect to add the clone disk functionality to the UI before removing the clone template button. Let's assume this requires a rewrite of the command to work with the new DB schema, this would be a throw away code, should it be done? I think not.
We have upstream releases which should be stable - preferably with no partial functionality, other than that there is a development going on in upstream and from time to time some of the functionality won't be fully ready, it does not mean the application is broken but a disabled button in the UI or something similar can be a valid state IMO.
I think the assumption is someone should always be able to take upstream HEAD and build/base a version on it, other than the formal versions.
----- Original Message -----
On 17/01/12 11:45, Ayal Baron wrote:
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote: > On 01/16/2012 10:58 AM, Itamar Heim wrote: >> On 01/16/2012 05:46 PM, Jon Choate wrote: >>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> We are going to be able to store the disks for a template >>>>>> on >>>>>> different storage domains due to the multiple storage >>>>>> domain >>>>>> feature. Cloning a template will still be possible, but >>>>>> will >>>>>> it >>>>>> provide any value? Thoughts? >>>>> I see no relation between the two options. >>>>> >>>>> Scenario 1: I can create a VM with a single disk and >>>>> create >>>>> a >>>>> template from it. >>>>> I would still want to be able to clone the template in >>>>> order >>>>> to >>>>> provision VMs from it on different domains. >>>>> >>>>> Scenario 2: same thing with multiple disks on same domain. >>>>> >>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>> domains >>>>> (domain A and domain B) and I want to have another copy of >>>>> the >>>>> template on domain C and domain D >>>>> >>>> Hi Jon, >>>> >>>> After talking to Michael Pasternak it seems that we did not >>>> implemented >>>> copyTemplate in the REST API, it seems to be a gap that we >>>> have. >>>> >>>> This gap is playing in our favor, we can remove the >>>> copyTemplate >>>> verb >>>> and introduce copyDisk verb. >>>> >>>> The template disks can be copied to another SD. >>>> When creating a VM from template the user can choose per >>>> disk >>>> the >>>> destination SD (only SD with the disks are eligible >>>> candidates). >>> wait, when creating a VM from a template, the user won't get >>> a >>> choice >>> will they? Won't the VM disks have to go on the same storage >>> domain as >>> the template disks they were created from? >> >> yes, but the template disks can be copied to multiple storage >> domains, >> so the user can choose for the VM/disk which storage domain >> to >> create >> them from (per storage domains that have copies of that disk) > OH! I totally misunderstood. So what you are saying is that a > template > can have N number of copies of the same disk each on a > different > storage > domain. I had thought that if you wanted that type of > situation > you > would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
> > Just to be clear, does this mean that the plan is to phase out > the > current clone template command and instead implementing a > clone > disk > command so that a template can duplicate its disks > individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects.
Exactly, choosing the disks to copy to the storage domain.
Which is wrong because multipleRunAction assumes there are no dependencies between the actions. In the case of copyTemplate the user sees copying all disks as a single operation which should either fail or succeed. Partial results are not clear and can cause other problems. Validations in this case should be on the entire set together, not one by one, etc.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action.
We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing.
If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 18/01/12 02:22, Ayal Baron wrote:
----- Original Message -----
On 17/01/12 11:45, Ayal Baron wrote:
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message ----- > From: "Itamar Heim"<iheim@redhat.com> > To: "Jon Choate"<jchoate@redhat.com> > Cc: engine-devel@ovirt.org > Sent: Monday, January 16, 2012 7:26:24 PM > Subject: Re: [Engine-devel] the future of template cloning > > On 01/16/2012 06:16 PM, Jon Choate wrote: >> On 01/16/2012 10:58 AM, Itamar Heim wrote: >>> On 01/16/2012 05:46 PM, Jon Choate wrote: >>>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> We are going to be able to store the disks for a template >>>>>>> on >>>>>>> different storage domains due to the multiple storage >>>>>>> domain >>>>>>> feature. Cloning a template will still be possible, but >>>>>>> will >>>>>>> it >>>>>>> provide any value? Thoughts? >>>>>> I see no relation between the two options. >>>>>> >>>>>> Scenario 1: I can create a VM with a single disk and >>>>>> create >>>>>> a >>>>>> template from it. >>>>>> I would still want to be able to clone the template in >>>>>> order >>>>>> to >>>>>> provision VMs from it on different domains. >>>>>> >>>>>> Scenario 2: same thing with multiple disks on same domain. >>>>>> >>>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>>> domains >>>>>> (domain A and domain B) and I want to have another copy of >>>>>> the >>>>>> template on domain C and domain D >>>>>> >>>>> Hi Jon, >>>>> >>>>> After talking to Michael Pasternak it seems that we did not >>>>> implemented >>>>> copyTemplate in the REST API, it seems to be a gap that we >>>>> have. >>>>> >>>>> This gap is playing in our favor, we can remove the >>>>> copyTemplate >>>>> verb >>>>> and introduce copyDisk verb. >>>>> >>>>> The template disks can be copied to another SD. >>>>> When creating a VM from template the user can choose per >>>>> disk >>>>> the >>>>> destination SD (only SD with the disks are eligible >>>>> candidates). >>>> wait, when creating a VM from a template, the user won't get >>>> a >>>> choice >>>> will they? Won't the VM disks have to go on the same storage >>>> domain as >>>> the template disks they were created from? >>> >>> yes, but the template disks can be copied to multiple storage >>> domains, >>> so the user can choose for the VM/disk which storage domain >>> to >>> create >>> them from (per storage domains that have copies of that disk) >> OH! I totally misunderstood. So what you are saying is that a >> template >> can have N number of copies of the same disk each on a >> different >> storage >> domain. I had thought that if you wanted that type of >> situation >> you >> would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
>> >> Just to be clear, does this mean that the plan is to phase out >> the >> current clone template command and instead implementing a >> clone >> disk >> command so that a template can duplicate its disks >> individually? > > pretty much, yes. > though i'd imagine 'clone template' would still be useful to > have > for > the user. not sure if it implies core should expose it as well > to > allow > easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects.
Exactly, choosing the disks to copy to the storage domain.
Which is wrong because multipleRunAction assumes there are no dependencies between the actions. In the case of copyTemplate the user sees copying all disks as a single operation which should either fail or succeed. Partial results are not clear and can cause other problems. Validations in this case should be on the entire set together, not one by one, etc.
I think that using the multi action approach is the better behavior for the user. If the user clone a template with 3 disks and the engine was able to clone only two out of three (got an error on the third copy), As a user i would rather get a chance to clone the third one again and not re-clone the other two (it takes time...). So my vote goes to multi actions.
Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action.
We are not cloning the template itself we are only cloning the template disks.
For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing.
If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
> _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
<SNIP>
>>> >>> Just to be clear, does this mean that the plan is to phase >>> out >>> the >>> current clone template command and instead implementing a >>> clone >>> disk >>> command so that a template can duplicate its disks >>> individually? >> >> pretty much, yes. >> though i'd imagine 'clone template' would still be useful to >> have >> for >> the user. not sure if it implies core should expose it as >> well >> to >> allow >> easier usage at UI level for such a task. > > we can leave it untouched - means copyTemplate get 1 > destination > domain, and copies all disks to it, > but i think it will be unusable (and problematic - what if one > of > the > disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects.
Exactly, choosing the disks to copy to the storage domain.
Which is wrong because multipleRunAction assumes there are no dependencies between the actions. In the case of copyTemplate the user sees copying all disks as a single operation which should either fail or succeed. Partial results are not clear and can cause other problems. Validations in this case should be on the entire set together, not one by one, etc.
I think that using the multi action approach is the better behavior for the user. If the user clone a template with 3 disks and the engine was able to clone only two out of three (got an error on the third copy), As a user i would rather get a chance to clone the third one again and not re-clone the other two (it takes time...).
So my vote goes to multi actions.
You're missing the point, if it's a single action then the canDoAction would validate free space for all disks together and wouldn't copy a single byte before failing. On the other hand, I do agree that if canDoAction succeeds and then one of the copies fails then you have to rollback which is not nice. If you can do an aggregated canDoAction for copying multiple disks using the multipleRunAction (i.e. calculate space needed for *all* disks on each target domain and warn user before starting or fail) and GUI-wise the operation is done on the disks themselves and not on the template then I'm fine with that. <SNIP>
I think that using the multi action approach is the better behavior for the user. If the user clone a template with 3 disks and the engine was able to clone only two out of three (got an error on the third copy), As a user i would rather get a chance to clone the third one again and not re-clone the other two (it takes time...).
So my vote goes to multi actions.
You're missing the point, if it's a single action then the canDoAction would validate free space for all disks together and wouldn't copy a single byte before failing.
I think the main point is the roll back behavior as i mentioned earlier, and less the validation of the canDoAction.
On the other hand, I do agree that if canDoAction succeeds and then one of the copies fails then you have to rollback which is not nice. If you can do an aggregated canDoAction for copying multiple disks using the multipleRunAction (i.e. calculate space needed for *all* disks on each target domain and warn user before starting or fail) and GUI-wise the operation is done on the disks themselves and not on the template then I'm fine with that.
The engine has built-in support for adding shared logic for multiple actions. I think it makes sense to add a validation for the storage capacity on the summary of all storage requests. I rather get another input on this before going with the shared logic - If implementing the above behavior it means we are going to fail cloning all disks if there is not enough space to clone one of them regardless of the destination storage domain. For example: - There are 2 domains each has 10G free space - There are 3 disks each of them takes 6G - The engine gets multiple-action command: * clone disk1 to domain1 * clone disk2 to domain1 * clone disk3 to domain2 Result: - engine fails all command although we could have cloned disk3. I am ok with the above scenario just want to make clear what is going to be the behavior.
<SNIP>
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 11:45:33 AM Subject: Re: [Engine-devel] the future of template cloning
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote:
On 01/16/2012 10:58 AM, Itamar Heim wrote: > On 01/16/2012 05:46 PM, Jon Choate wrote: >> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>> On 12/01/12 22:45, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> We are going to be able to store the disks for a template >>>>> on >>>>> different storage domains due to the multiple storage >>>>> domain >>>>> feature. Cloning a template will still be possible, but >>>>> will >>>>> it >>>>> provide any value? Thoughts? >>>> I see no relation between the two options. >>>> >>>> Scenario 1: I can create a VM with a single disk and >>>> create >>>> a >>>> template from it. >>>> I would still want to be able to clone the template in >>>> order >>>> to >>>> provision VMs from it on different domains. >>>> >>>> Scenario 2: same thing with multiple disks on same domain. >>>> >>>> Scenario 3: I have a template with 2 disks on 2 different >>>> domains >>>> (domain A and domain B) and I want to have another copy of >>>> the >>>> template on domain C and domain D >>>> >>> Hi Jon, >>> >>> After talking to Michael Pasternak it seems that we did not >>> implemented >>> copyTemplate in the REST API, it seems to be a gap that we >>> have. >>> >>> This gap is playing in our favor, we can remove the >>> copyTemplate >>> verb >>> and introduce copyDisk verb. >>> >>> The template disks can be copied to another SD. >>> When creating a VM from template the user can choose per >>> disk >>> the >>> destination SD (only SD with the disks are eligible >>> candidates). >> wait, when creating a VM from a template, the user won't get >> a >> choice >> will they? Won't the VM disks have to go on the same storage >> domain as >> the template disks they were created from? > > yes, but the template disks can be copied to multiple storage > domains, > so the user can choose for the VM/disk which storage domain > to > create > them from (per storage domains that have copies of that disk) OH! I totally misunderstood. So what you are saying is that a template can have N number of copies of the same disk each on a different storage domain. I had thought that if you wanted that type of situation you would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
Just to be clear, does this mean that the plan is to phase out the current clone template command and instead implementing a clone disk command so that a template can duplicate its disks individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb. I agree. This is the common use case, all disk resides on the same SD. and that is why we need a verb for it. However, for more "trick"/special cases we need to support multi domains. I also think it would be easier from api perspective to use a single copy verb.
If the UI chooses to expose such operation it will use the multipleRunAction API which makes it easier to expose to the user partial success, we could clone disk A and Disk B but Disk C failed etc.
The multipleRunAction is for user marking multiple objects in GUI and running an action on all of these objects. Here however, the action the user wants is to copy 1 object (the template) which has sub objects and it should run as a single action. For example, if there is enough space on the target domain for 2/4 disks then using multipleRunAction would result in 2 disks being copied and 2 failing. If however it is a single action then the free space test would fail the entire action and user would be able to choose if he wants to copy just 2. Note that in this case, actually performing the copy of the 2 disks is detrimental as it can negatively affect VMs on this domain.
what the user really wants is to specify which disks to copy and destination per disk, and i don't see a reason to create a backend command to do it
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 17/01/12 23:00, Miki Kenneth wrote:
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, January 17, 2012 11:45:33 AM Subject: Re: [Engine-devel] the future of template cloning
----- Original Message -----
On 17/01/12 10:46, Itamar Heim wrote:
On 01/17/2012 10:32 AM, Omer Frenkel wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Jon Choate"<jchoate@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, January 16, 2012 7:26:24 PM Subject: Re: [Engine-devel] the future of template cloning
On 01/16/2012 06:16 PM, Jon Choate wrote: > On 01/16/2012 10:58 AM, Itamar Heim wrote: >> On 01/16/2012 05:46 PM, Jon Choate wrote: >>> On 01/16/2012 09:46 AM, Livnat Peer wrote: >>>> On 12/01/12 22:45, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> We are going to be able to store the disks for a template >>>>>> on >>>>>> different storage domains due to the multiple storage >>>>>> domain >>>>>> feature. Cloning a template will still be possible, but >>>>>> will >>>>>> it >>>>>> provide any value? Thoughts? >>>>> I see no relation between the two options. >>>>> >>>>> Scenario 1: I can create a VM with a single disk and >>>>> create >>>>> a >>>>> template from it. >>>>> I would still want to be able to clone the template in >>>>> order >>>>> to >>>>> provision VMs from it on different domains. >>>>> >>>>> Scenario 2: same thing with multiple disks on same domain. >>>>> >>>>> Scenario 3: I have a template with 2 disks on 2 different >>>>> domains >>>>> (domain A and domain B) and I want to have another copy of >>>>> the >>>>> template on domain C and domain D >>>>> >>>> Hi Jon, >>>> >>>> After talking to Michael Pasternak it seems that we did not >>>> implemented >>>> copyTemplate in the REST API, it seems to be a gap that we >>>> have. >>>> >>>> This gap is playing in our favor, we can remove the >>>> copyTemplate >>>> verb >>>> and introduce copyDisk verb. >>>> >>>> The template disks can be copied to another SD. >>>> When creating a VM from template the user can choose per >>>> disk >>>> the >>>> destination SD (only SD with the disks are eligible >>>> candidates). >>> wait, when creating a VM from a template, the user won't get >>> a >>> choice >>> will they? Won't the VM disks have to go on the same storage >>> domain as >>> the template disks they were created from? >> >> yes, but the template disks can be copied to multiple storage >> domains, >> so the user can choose for the VM/disk which storage domain >> to >> create >> them from (per storage domains that have copies of that disk) > OH! I totally misunderstood. So what you are saying is that a > template > can have N number of copies of the same disk each on a > different > storage > domain. I had thought that if you wanted that type of > situation > you > would have multiple copies of the template itself too.
yes, one copy of disk per domain though.
> > Just to be clear, does this mean that the plan is to phase out > the > current clone template command and instead implementing a > clone > disk > command so that a template can duplicate its disks > individually?
pretty much, yes. though i'd imagine 'clone template' would still be useful to have for the user. not sure if it implies core should expose it as well to allow easier usage at UI level for such a task.
we can leave it untouched - means copyTemplate get 1 destination domain, and copies all disks to it, but i think it will be unusable (and problematic - what if one of the disks already exists on the destination?),
then don't copy it, it is already there
I agree with Omer, there is no reason to support copy template, if the user wants to clone all the disks he can use multiple actions, we don't need a specific verb for this.
Reason or lack of depends on the common usage. If we assume that normally all disks of a template would reside on the same domain then it makes sense to have a verb to copy the template in its entirety and not burden the user. The general recommendation should be to use a single storage domain, so I think there is room for such a verb.
I agree. This is the common use case, all disk resides on the same SD. and that is why we need a verb for it. However, for more "trick"/special cases we need to support multi domains. I also think it would be easier from api perspective to use a single copy verb.
The question is what would we like to be the behavior when the operation fails, the different approaches are mostly around error flows: - If the clone template is a single action, the error handling would be to roll back (if the engine failed copying all the images, the images that were copied successfully to the destination will be deleted). - If we use the multiple action approach it means that each image that was copied successfully will stay there and be presented to the user as success and for those we failed to copy the user will get an error message.
participants (8)
-
Ayal Baron -
Ewoud Kohl van Wijngaarden -
Itamar Heim -
Jon Choate -
Livnat Peer -
Mike Kolesnik -
Miki Kenneth -
Omer Frenkel