[Engine-devel] ovirt core MOM

[Miki Kenneth]

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