[Engine-devel] ovirt core MOM

[Ayal Baron]

----- Original Message -----
> 
> 
> ----- 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)
> 

I agree, that is why I said template versioning should have both.