Re: [Engine-devel] ovirt core MOM

From: "Ayal Baron" <abaron(a)redhat.com&gt; To: "Itamar Heim" <iheim(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org, "Miki Kenneth" <mkenneth(a)redhat.com&gt; 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&quot;&lt;iheim(a)redhat.com&gt; > >> To: "Ayal Baron&quot;&lt;abaron(a)redhat.com&gt; > >> Cc: engine-devel(a)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). > > >