19 Nov
2012
19 Nov
'12
2:03 p.m.
----- 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. > > > 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. > > 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? > > > > > > > > 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. > > > > > > _______________________________________________ > > > > > > 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 > > > > > >