[Engine-devel] the future of template cloning

Tue Jan 17 15:37:12 UTC 2012

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Jon Choate" <jchoate at redhat.com>
> > To: engine-devel at 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 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.
> > >>
> > >
> > >>> 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 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
> > 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 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
> 