Re: [Engine-devel] ovirt core MOM

----- Original Message ----- > 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. > > #2 does not solve #1. #2 allows doing part of #1 in a more efficient way. so there is no reason to not do #1. (there is also no reason to not do #2)