Re: [Engine-devel] ovirt core MOM

----- Original Message ----- > From: "Ayal Baron"<abaron(a)redhat.com> > To: "Itamar Heim"<iheim(a)redhat.com> > Cc: "Miki Kenneth"<mkenneth(a)redhat.com>, engine-devel(a)ovirt.org > Sent: Wednesday, February 1, 2012 12:26:12 PM > Subject: Re: [Engine-devel] ovirt core MOM > > > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> From: "Ayal Baron"<abaron(a)redhat.com> >>> To: "Itamar Heim"<iheim(a)redhat.com> >>> Cc: "Miki Kenneth"<mkenneth(a)redhat.com>, 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"<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. >>>> >>> 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. Decision?