[Engine-devel] ovirt core MOM

[Ayal Baron]

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

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

Again, need to put the emphasis on fast provisioning of templates and VMs.
Applying updates to a pool should be a breeze (e.g. an automatic monthly process that unseals the template, updates it and reseals it).

> 
> 
>