Bug 1270562

As commented in BZ #825671 (which originated this one), we have the OvfUpdateIntervalInMinutes configuration value (60 minutes by default) and Engine is checking for changes before updating the OVF_STORE, so reducing OvfUpdateIntervalInMinutes could be good enough in most cases.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Points to take intoconsideration when verifying this bz:

* When initiating ovf update by REST action or GUI context menu, an update should occur even if there was no change in the environment.

* The update could fail if another update (say, scheduled ovf update) is being processed, and vice versa.

* There are two OVF_STORE disks per domain, so there should be two audit log messages stating the OVF_STORE was updated that look exactly alike. This is not a bug, this is just how it's supposed to be.

* There are no audit log messages for quartz-scheduled OVF updates. This is intentional since the scheduled job goes over all the active data domains in the system, and that would flood the events log (again, two identical messages for each domain) in case there are even just a few domains. Note we did try this approach at first and the flooding was horrible, and so we decided not to log messages for the scheduled job.

Idan, please progress with the patches

Moving to Tal since he's working on it.

Verified on - ovirt-engine-4.1.0-0.0.master.20161126211319.gitae69c34.el7.centos.noarch

POST api/storagedomains/{sd_id}/updateovfstore

and ensure all items from comment #4 are met

(In reply to Raz Tamir from comment #8)
> Verified on -
> ovirt-engine-4.1.0-0.0.master.20161126211319.gitae69c34.el7.centos.noarch
> 
> POST api/storagedomains/{sd_id}/updateovfstore
> 
> and ensure all items from comment #4 are met

So can this be moved to VERIFIED, or should we wait for an official build, the BZ to be moved to ON_QA and these steps performed again?

We will wait for official build and retest

The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.

Update on Feature latest execution :
WebGUI&API Force updateOVF does not update OVF store when Adding VM/Disk or removing disk (Only removing VM works)

Version-Release number of selected component (if applicable):
oVirt Engine Version: 4.1.0-0.2.master.20161212172238.gitea103bd.el7.centos 

Works :
- Remove VM 

Not Working ( Also aggregated in Bug #140460) :
1)If not scheduled update Nothing works !  - bug 1403581

2) After scheduled update , modify VM/disk + force update:

-  Create VM No disk - bug #1404565 
-  Create VM +disk (or 2disks) - Bug #140460
-  Delete disk from VM

As discussed with Tal Nissan , reassigning this bug .

Tal , you can aggragate/dup both bugs ( #1404565 , #1403581 ) to bug #1404607 as they are all with the same issue & solve it there .

Tal, is this going to 4.1, or shall we defer it to 4.2?

The feature is basically but with a few bugs that weren't examined yet due to no capacity, we can fix them for the first 4.1.z

(In reply to Tal Nisan from comment #17)
> The feature is basically but with a few bugs that weren't examined yet due
> to no capacity, we can fix them for the first 4.1.z

So why not defer to 4.1.3?

Maor/Tal, with bug 1403581 fixed, is there anything more to do here, or should this be back ON_QA?

Honestly, this feature is basically BZ1403581 and BZ1404607, unless I'm missing anything...

(In reply to Maor from comment #20)
> Honestly, this feature is basically BZ1403581 and BZ1404607, unless I'm
> missing anything...

That was my understanding too - was trying to see if I was missing anything.
Setting to ON_QA accordingly.

verified at 4.1.3.4