Re: [Engine-devel] ovirt core MOM

On 01/23/2012 11:01 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> From: "Ayal Baron"<abaron(a)redhat.com> >>> To: "Itamar Heim"<iheim(a)redhat.com> >>> Cc: engine-devel(a)ovirt.org, "Miki Kenneth"<mkenneth(a)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(a)redhat.com> >>>>>> To: "Ayal Baron"<abaron(a)redhat.com> >>>>>> 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.