[Engine-devel] multiple destinations for disks in create/import template?
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template? Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them. If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>. thoughts?
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template?
Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them.
If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>.
thoughts? I think something that should be taken in consider if doing that, is
On 02/02/2012 06:01 PM, Jon Choate wrote: that the VM which the template is created from will stay in image lock much longer. Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template?
Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them.
If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>.
thoughts? I think something that should be taken in consider if doing that, is
On 02/02/2012 06:01 PM, Jon Choate wrote: that the VM which the template is created from will stay in image lock much longer. Not necessarily. Once we get one copy of each disk down, we can release
Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all. Yes, the failure cases need to be considered. I would think that as long as one copy of each disk can be created then the template should
On 02/02/2012 11:19 AM, Maor wrote: the vm and use these copies as the source of the other copies. persist. If we can't create a copy of each disk then we need to roll back and not create the template. But in this approach how do we convey the list of failures back to the user?
_______________________________________________ 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 02/02/2012 07:16 PM, Jon Choate wrote:
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template?
Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them.
If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>.
thoughts? I think something that should be taken in consider if doing that, is
On 02/02/2012 06:01 PM, Jon Choate wrote: that the VM which the template is created from will stay in image lock much longer. Not necessarily. Once we get one copy of each disk down, we can release
Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all. Yes, the failure cases need to be considered. I would think that as long as one copy of each disk can be created then the template should
On 02/02/2012 11:19 AM, Maor wrote: the vm and use these copies as the source of the other copies. persist. If we can't create a copy of each disk then we need to roll back and not create the template.
But in this approach how do we convey the list of failures back to the user?
how about we start with KISS to see everything works post all changes going around, and later can add support for multiple clones (parallel or serial)?
On 02/02/12 21:17, Itamar Heim wrote:
On 02/02/2012 07:16 PM, Jon Choate wrote:
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template?
Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them.
If so, what would the UI look for this? It would require the backend to receive something that looks like Map<DiskImage, List<StorageDomain>>.
thoughts? I think something that should be taken in consider if doing that, is
On 02/02/2012 06:01 PM, Jon Choate wrote: that the VM which the template is created from will stay in image lock much longer. Not necessarily. Once we get one copy of each disk down, we can release
Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all. Yes, the failure cases need to be considered. I would think that as long as one copy of each disk can be created then the template should
On 02/02/2012 11:19 AM, Maor wrote: the vm and use these copies as the source of the other copies. persist. If we can't create a copy of each disk then we need to roll back and not create the template.
But in this approach how do we convey the list of failures back to the user?
how about we start with KISS to see everything works post all changes going around, and later can add support for multiple clones (parallel or serial)?
+1 for KISS Other than that we have many scenarios where we want to aggregate number of users actions as one user operation (plug and activate disk for example and some older flows like configure local storage). I think that after introducing a general mechanism in the engine for executing sequence of commands all the above modeling will be redundant. Theoretically the user will be able to create a template followed by clone disk for the relevant disks etc. Livnat
______________________________
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (4)
-
Itamar Heim -
Jon Choate -
Livnat Peer -
Maor