19 Nov
2012
19 Nov
'12
7:38 a.m.
On 11/19/2012 03:34 PM, Liron Aravot wrote: > > > ----- Original Message ----- >> From: "Michael Kublin" <mkublin@redhat.com> >> To: "Liron Aravot" <laravot@redhat.com> >> Cc: engine-devel@ovirt.org >> Sent: Monday, November 19, 2012 3:28:06 PM >> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater >> >> >> >> ----- Original Message ----- >>> From: "Liron Aravot" <laravot@redhat.com> >>> To: "Michael Kublin" <mkublin@redhat.com> >>> Cc: engine-devel@ovirt.org >>> Sent: Monday, November 19, 2012 3:17:04 PM >>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Michael Kublin" <mkublin@redhat.com> >>>> To: "Liron Aravot" <laravot@redhat.com> >>>> Cc: engine-devel@ovirt.org >>>> Sent: Monday, November 19, 2012 3:03:23 PM >>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Liron Aravot" <laravot@redhat.com> >>>>> To: "Mike Kolesnik" <mkolesni@redhat.com> >>>>> Cc: engine-devel@ovirt.org, "Michael Kublin" >>>>> <mkublin@redhat.com> >>>>> Sent: Monday, November 19, 2012 2:52:56 PM >>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Mike Kolesnik" <mkolesni@redhat.com> >>>>>> To: "Liron Aravot" <laravot@redhat.com> >>>>>> Cc: engine-devel@ovirt.org, "Michael Kublin" >>>>>> <mkublin@redhat.com> >>>>>> Sent: Monday, November 19, 2012 2:44:56 PM >>>>>> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater >>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Liron Aravot" <laravot@redhat.com> >>>>>>>> To: engine-devel@ovirt.org >>>>>>>> Sent: Monday, November 19, 2012 2:03:57 PM >>>>>>>> Subject: [Engine-devel] [Engine-Devel] OvfDataUpdater >>>>>>>> >>>>>>>> starting a new discussion thread. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Mike Kolesnik" <mkolesni@redhat.com> >>>>>>>>> To: "Liron Aravot" <laravot@redhat.com> >>>>>>>>> Sent: Monday, November 19, 2012 12:42:10 PM >>>>>>>>> Subject: Re: [Engine-devel] OvfAutoUpdater >>>>>>>>> >>>>>>>>> I think 'version' is a more standard term for the >>>>>>>>> column >>>>>>>>> names. >>>>>>>>> >>>>>>>>> Also in: 4. If succesfull - for each vm update the >>>>>>>>> ovf_generation >>>>>>>>> to >>>>>>>>> equal the db_generation. >>>>>>>>> I think you mean that the update should be to the >>>>>>>>> entity >>>>>>>>> version >>>>>>>>> you >>>>>>>>> initially selected. >>>>>>>>> >>>>>>> 1. I think should be version = version +1; >>>>> the version will be the db_generation that was loaded when we >>>>> loaded >>>>> the vm/template. >>>>> for example - if the vm/template was updated twice between >>>>> OvfUpdater >>>>> runs, we will need to increment twice - so incrementing by one >>>>> will >>>>> cause another unneeded ovf update for that vm. >>>> I am talking about ovfVersion or how you called it. >>> me too, >>> if we update the vm three times between OvfAutoUpdater runs , we >>> will >>> have the following values in the loaded vm for example: >>> db_generation 8 >>> ovf_generation 5 >>> >>> when we perform the ovf update , ovf_generation should be set to 8 >>> and not to 6, as version '8' is the version that we wrote the ovf >>> metadata of. >> These should be written in wiki, with remarks that values which were >> retrieved >> from DB together. >>>>>>> 2. Now the quartz is automatic process, updateVmInSpm it is >>>>>>> spm >>>>>>> operation -it means it can trigger a reconstruct >>>>>>> and spm election. >>>>> 2. updateVmInSpm command would be changed so it won't trigger >>>>> failover, will add that to the wiki. >>>>>>> 3. How your solution is handling a case of >>>>>>> hotPlug/hotUnplug/remove/add of vm disks. vm_static is not >>>>>>> usually >>>>>>> updated. >>>>> Whenever will be a command that locks a vm/template, you will >>>>> have >>>>> an >>>>> option during the unlock to specify if the version need to be >>>>> incremented, you'll be able to increment it also yourself. >>>>> The HotUnPlug command does lock the vm and during >>>>> endSuccesfully >>>>> attempt to update the vm in spm, so it will increment the >>>>> db_version/generation instead. >>>>>> >>>> addDisk, removeDisk, hotPlug/unPlug not locking a vm. >>>> Also, as far as I know LockVm/UnLockVm it is operation on >>>> vm_dynamic >>>> and not >>>> vm_static. >>> >>> hotplug acquires memory lock on the vm and has no async tasks if I >>> recall correctly. >> Yes, correct and what? These what I said, vm_static is not updated. > you will just call the dao method for incrementing the db_generation, you don't have to perform vm_static update. >>> adddisk acquires shared lock on the vm which is problematic with >>> today flow as well - as you have a race during updateVmInSpm, it >>> should be fixed regardless of the OvfAutoUpdater. >> It is not answer on my question. How ovf will be updated? How you >> understand >> that ovf of vm should be updated? > > the ovf will be updated when you increment the db_generation value instead of calling updateVmInSpm(). > you will be able to do that from the dao directly when you want, or when you unlock a vm/template. > when you will update the db_generation, the vm/template would be picked up by OvfUpdater as it's db_generation is different than its ovf_generation. > >>>> >>>>>> Also consider snapshots & vNICs which affect the VM state. >>>>> Whatever affect the vm state and triggers updateVmInSpm today >>>>> will >>>>> continue to, it can be added to flows which don't do that >>>>> today. >>>>>> >>>>>>> 4. Reconstruct/Recovery - updateVmInSpm should be called on >>>>>>> all >>>>>>> vms, >>>>>>> no matter if they were updated. >>>>> >>>>> Ofcourse, it's being taken care of. >>>> How? >>> we don't have ovf's of the vms when we reconstruct as we don't have >>> master domain - so we should set the ovf_generation of the vms to >>> be >>> 0 - which will cause ovfautoupdater to copy the vm metadata. >> I did not understand that statement and how it is related. > OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation. >>> a performance improvement may be introduced later on in case of >>> wrong >>> master version, but that's not related to the ovfautoupdater. >> I don't understand connection to performance. >> Now you are replacing a calls to VmCommand.updateVmInSpm() one of >> them it >> is at reconstruct flow, and you should handle it also and add it to >> wiki. > answered below, OvfAutoUpdater will get those vms for update as db_generation is different than ovf_generation. >>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mike >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater >>>>>>>>>> >>>>>>>>>> Hi all, i'll be glad if you could review the wiki >>>>>>>>>> page >>>>>>>>>> of >>>>>>>>>> OvfAutoUpdater, if you have any suggestions or ideas >>>>>>>>>> please >>>>>>>>>> let >>>>>>>>>> me >>>>>>>>>> know. >>>>>>>>>> >>>>>>>>>> http://wiki.ovirt.org/wiki/Feature/OvfAutoUpdater >>>>>>>>>> >>>>>>>>>> short preview from the wiki: >>>>>>>>>> vm/template configurations (including disks info) are >>>>>>>>>> stored >>>>>>>>>> on >>>>>>>>>> the >>>>>>>>>> master storage domain for backup purposes, >>>>>>>>>> import/export >>>>>>>>>> and >>>>>>>>>> also >>>>>>>>>> to >>>>>>>>>> provide the abillity to run VMs without having a >>>>>>>>>> running >>>>>>>>>> engine/db. >>>>>>>>>> Currently ovf update is done synchronously when >>>>>>>>>> performing >>>>>>>>>> various >>>>>>>>>> operations on vms/templates - update, save, >>>>>>>>>> adding/removing >>>>>>>>>> a >>>>>>>>>> disk, >>>>>>>>>> etc. What's more, currently updating the ovf >>>>>>>>>> (updateVM >>>>>>>>>> vdsm >>>>>>>>>> call) >>>>>>>>>> is >>>>>>>>>> usually done within a transcation. >>>>>>>>>> >>>>>>>>>> The idea behined OvfAutoUpdater is to perform batch >>>>>>>>>> ovf >>>>>>>>>> update >>>>>>>>>> operations that aggregate all outstanding updates per >>>>>>>>>> data >>>>>>>>>> center. >>>>>>>>>> These updates will be done in specifed time intervals >>>>>>>>>> which >>>>>>>>>> will >>>>>>>>>> reduce XML-RPC calls and will enable the removal of >>>>>>>>>> this >>>>>>>>>> syncronous >>>>>>>>>> vdsm call from all over the code. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Liron Aravot. Are you going to expose the config value via engine-config? >>>>>>>>>> _______________________________________________ >>>>>>>>>> Engine-devel mailing list >>>>>>>>>> Engine-devel@ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel@ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel@ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >