[Engine-devel] [Engine-Devel] OvfDataUpdater

[Liron Aravot]

----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, November 19, 2012 3:03:23 PM
> Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > Sent: Monday, November 19, 2012 2:52:56 PM
> > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Liron Aravot" <laravot at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Michael Kublin" <mkublin at redhat.com>
> > > Sent: Monday, November 19, 2012 2:44:56 PM
> > > Subject: Re: [Engine-devel] [Engine-Devel] OvfDataUpdater
> > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Liron Aravot" <laravot at redhat.com>
> > > > > To: engine-devel at 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 at redhat.com>
> > > > > > To: "Liron Aravot" <laravot at 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.
> > > > 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.
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.
> 
> > > 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.

a performance improvement may be introduced later on in case of wrong master version, but that's not related to the ovfautoupdater.
> > > > 
> > > > > > 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 at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > > > 
> > > > > > 
> > > > > _______________________________________________
> > > > > Engine-devel mailing list
> > > > > Engine-devel at ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > > 
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > 
>