[Engine-devel] ovirt core MOM

Wed Feb 1 10:16:39 UTC 2012

----- Original Message -----
> From: "Ayal Baron" <abaron at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "Miki Kenneth" <mkenneth at redhat.com>, engine-devel at ovirt.org
> Sent: Wednesday, February 1, 2012 11:41:43 AM
> Subject: Re: [Engine-devel] ovirt core MOM
> 
> 
> 
> ----- Original Message -----
> > On 01/23/2012 11:01 PM, Ayal Baron wrote:
> > >
> > >
> > > ----- Original Message -----
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Ayal Baron"<abaron at redhat.com>
> > >>> To: "Itamar Heim"<iheim at redhat.com>
> > >>> Cc: engine-devel at ovirt.org, "Miki Kenneth"<mkenneth at redhat.com>
> > >>> Sent: Sunday, January 22, 2012 11:19:03 AM
> > >>> Subject: Re: [Engine-devel] ovirt core MOM
> > >>>
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> On 01/20/2012 11:42 PM, Miki Kenneth wrote:
> > >>>>>
> > >>>>>
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Itamar Heim"<iheim at redhat.com>
> > >>>>>> To: "Ayal Baron"<abaron at redhat.com>
> > >>>>>> Cc: engine-devel at ovirt.org
> > >>>>>> Sent: Friday, January 20, 2012 2:12:27 AM
> > >>>>>> Subject: Re: [Engine-devel] ovirt core MOM
> > >>>>>>
> > >>>>>> On 01/19/2012 11:58 AM, Ayal Baron wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ----- Original Message -----
> > >>>>>>>> On 01/18/2012 05:53 PM, Livnat Peer wrote:
> > >>>>>>>>> Hi All,
> > >>>>>>>>>
> > >>>>>>>>> This is what we've discussed in the meeting today:
> > >>>>>>>>>
> > >>>>>>>>> Multiple storage domain:
> > >>>>>>>>> - Should have a single generic verb for removing a disk.
> > >>>>>>>>> - We block removing the last template disk - template is
> > >>>>>>>>> immutable.
> > >>>>>>>>
> > >>>>>>>> but it will be deleted when deleting the template, right?
> > >>>>>>>
> > >>>>>>> Of course.
> > >>>>>>> The point is that the template is an immutable object and
> > >>>>>>> should
> > >>>>>>> not change (until we support editing a template at which
> > >>>>>>> point
> > >>>>>>> the
> > >>>>>>> user would have to change the template to edit mode before
> > >>>>>>> being
> > >>>>>>> able to make such changes and maybe also be able to run it
> > >>>>>>> and
> > >>>>>>> make changes internally?).
> > >>>>>>
> > >>>>>> When i hear "edit a template" i don't expect replacing the
> > >>>>>> files.
> > >>>>>> I expect a new edition of disks appearing as a new version
> > >>>>>> of
> > >>>>>> the
> > >>>>>> template. but they don't have to derive from same original
> > >>>>>> template.
> > >>>>>> say i want to create a "Fedora 16 template", then update it
> > >>>>>> every
> > >>>>>> month
> > >>>>>> with latest "yum update".
> > >>>>>> it doesn't matter if i use a VM from same template or just
> > >>>>>> create
> > >>>>>> a
> > >>>>>> new one.
> > >>>>>> then specify it is V2 of the "Fedora 16 template".
> > >>>>>> when someone creates a VM from this template, default
> > >>>>>> version
> > >>>>>> would
> > >>>>>> be
> > >>>>>> latest (but we can let them choose specific older versions
> > >>>>>> as
> > >>>>>> well)
> > >>>>> +1. Nicely put.
> > >>>>> And just to add another common use case is the pool usage.
> > >>>>> When we creating stateless VM pool from the template,
> > >>>>> it would be nice to be able to update the template to V2,
> > >>>>> and have all the newly created VMs dynamically based to the
> > >>>>> new
> > >>>>> template.
> > >>>>
> > >>>> that is indeed where i was going with it as well, but not as
> > >>>> trivial,
> > >>>> since need to wait for VMs to stop and return to pool and
> > >>>> create
> > >>>> new
> > >>>> ones and remove old ones.
> > >>>> also, creating new ones may involve an admin action of first
> > >>>> boot
> > >>>> +
> > >>>> take
> > >>>> of first snapshot
> > >>>>
> > >>>> (hence i stopped the previous description before this part,
> > >>>> but
> > >>>> since
> > >>>> you opened the door...)
> > >>>
> > >>> Yes, but this all goes to template versioning (which is great
> > >>> and
> > >>> we
> > >>> need).
> > >>> For the user though, creating a new template version like you
> > >>> described would be a long and wasteful process, and is not what
> > >>> I'm
> > >>> talking about.
> > >>>
> > >>> Unless we support nested templates (second template would be a
> > >>> snapshot over the first one), then we're likely to require way
> > >>> too
> > >>> much space and creation process would be too slow (having to
> > >>> copy
> > >>> over all the bits).
> > >>> I think the pool example is an excellent example where I would
> > >>> not
> > >>> want to have 2 copies of the template where the only difference
> > >>> between them is a set of security patches I've applied to the
> > >>> new
> > >>> template.
> > >> Not sure I understand how you do that while vms are still
> > >> running
> > >> on
> > >> the original template?
> > >
> > > They either:
> > > 1. wouldn't be (if changes are in place)
> > > 2. if we support template over template (from snapshot) then no
> > > issue at all.
> > >     Once all VMs stop running on previous template we can live
> > >     merge the 2.
> > >
> > >>>
> > >>> So the 2 options are for what I'm suggesting are:
> > >>> 1. decommission the old template by making in place changes
> > >>> 2. support template snapshots
> > >> Not sure how this will work and what use case it serves?
> > >
> > > number 1: changing the template for stateless pools.
> > > number 2: for anything you want including template versioning.
> > > Template versioning should have 2 flavours:
> > > 1. my golden image is outdated and I would like to decommission
> > > it
> > > and replace with a new one created from scratch (i.e. same name,
> > > new VMs would be derived from new template, no data dedup).
> > > 2. my golden image is outdated and I would like to update it
> > > internally - create a VM from it, make the changes, seal this VM
> > > as the new version of the template (not using the process we have
> > > today which copies all the data, just change it to be immutable).
> > >
> > > The latter requires supporting trees.
> > 
> > use case wise, #1 is easier, and covers both use cases - it only
> > varies
> > in amount of IO/Space, so when someone tackles this implementation
> > wise,
> > I'd vote for doing #1 first.
> > 
> No, it varies in amount of time and complexity for user.
> It might also be quite complex to create the same image again.
> To this I can only say 'provisioning provisioning provisioning'.
> The point is to make the user's life easier and making provisioning a
> breeze, forcing #1 is going in the opposite direction.
> 
> 

#2 does not solve #1. 
#2 allows doing part of #1 in a more efficient way.
so there is no reason to not do #1.
(there is also no reason to not do #2)