----- Original Message ----- > > > ----- Original Message ----- > > From: "Ayal Baron" <[email protected]> > > To: "Itamar Heim" <[email protected]> > > Cc: "Miki Kenneth" <[email protected]>, [email protected] > > 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"<[email protected]> > > > >>> To: "Itamar Heim"<[email protected]> > > > >>> Cc: [email protected], "Miki > > > >>> Kenneth"<[email protected]> > > > >>> 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"<[email protected]> > > > >>>>>> To: "Ayal Baron"<[email protected]> > > > >>>>>> Cc: [email protected] > > > >>>>>> 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) >
I agree, that is why I said template versioning should have both. _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
