[Engine-devel] the future of template cloning

Tue Jan 17 21:00:16 UTC 2012


----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: engine-devel at 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 at redhat.com>
> > >>> To: "Jon Choate"<jchoate at redhat.com>
> > >>> Cc: engine-devel at 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 at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>>
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>