[Engine-devel] ovirt core MOM

[Ayal Baron]

----- 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.