----- Original Message ----- > From: "Mike Kolesnik" <[email protected]> > To: "Liron Aravot" <[email protected]> > Cc: [email protected], "Michael Kublin" <[email protected]> > Sent: Monday, November 19, 2012 2:44:56 PM > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater > > > > > > > ----- Original Message ----- > > > From: "Liron Aravot" <[email protected]> > > > To: [email protected] > > > 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" <[email protected]> > > > > To: "Liron Aravot" <[email protected]> > > > > 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. > > 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. > > 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. > > > > > > 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 > > > > > [email protected] > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > Engine-devel mailing list > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
