Re: [Engine-devel] ovirt core MOM

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