On 01/17/2012 10:49 AM, Livnat Peer wrote:
On 17/01/12 17:04, Omer Frenkel wrote:
----- Original Message -----
From: "Jon Choate"<jcho...@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"<ih...@redhat.com>
To: "Jon Choate"<jcho...@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.
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
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
