Bug 1270562 - [RFE] - Add an API to force OVF_STORE update
[RFE] - Add an API to force OVF_STORE update
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
4.0.0
Unspecified Unspecified
low Severity medium (vote)
: ovirt-4.1.3
: 4.1.3.3
Assigned To: Tal Nisan
Avihai
: FutureFeature
Depends On: 1403581 1404607
Blocks: 1489215
  Show dependency treegraph
 
Reported: 2015-10-11 04:04 EDT by Allon Mureinik
Modified: 2017-09-06 20:44 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Add an API to force OVF_STORE update Reason: The need to control the timing of an ovf_store volume update, rather than wait for the scheduled job for this, and help recuperate from a previous update that is presumably defective. Result: 1. New REST API action - updateovfstore . Usage example: http://myserver:8080/ovirt-engine/api/storagedomains/<sotrage-domain-id>/updateovfstore 2. New context menu option - Update OVFs, when right clicking over an active storage domain. A new button WAS NOT supplied since this should not be a common operation.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-06 09:55:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+
rule-engine: exception+
ratamir: testing_plan_complete+
ylavi: planning_ack+
amureini: devel_ack+
ratamir: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 54537 master MERGED core: Enable ovf-store update initiation via REST API 2016-08-23 11:00 EDT
oVirt gerrit 55330 master MERGED webadmin: Add Webadmin support for ovf-store update user initiation 2016-08-23 11:00 EDT
oVirt gerrit 55700 master MERGED engine: Add audit log message for update OVF_STORE 2016-08-23 11:00 EDT

  None (edit)
Description Allon Mureinik 2015-10-11 04:04:56 EDT
In the current release, the OVF_STORE is updated periodically, in order to reduce I/O impact. However, users would sometimes want to force an update - e.g., after importing an important VM, making a critical update, etc.
Comment 1 Christopher Pereira 2015-10-14 05:46:48 EDT
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.
Comment 2 Red Hat Bugzilla Rules Engine 2015-10-19 06:50:33 EDT
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.
Comment 3 Mike McCune 2016-03-28 19:43:17 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 4 Vered Volansky 2016-04-20 13:56:11 EDT
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.
Comment 6 Tal Nisan 2016-05-05 08:10:40 EDT
Idan, please progress with the patches
Comment 7 Idan Shaby 2016-06-09 07:18:46 EDT
Moving to Tal since he's working on it.
Comment 8 Raz Tamir 2016-11-29 12:02:42 EST
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
Comment 9 Allon Mureinik 2016-11-29 15:32:15 EST
(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?
Comment 10 Raz Tamir 2016-11-30 05:01:18 EST
We will wait for official build and retest
Comment 11 Sandro Bonazzola 2016-12-12 08:53:54 EST
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.
Comment 12 Avihai 2016-12-14 04:50:23 EST
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
Comment 13 Avihai 2016-12-14 06:12:58 EST
As discussed with Tal Nissan , reassigning this bug .
Comment 14 Avihai 2016-12-14 06:19:07 EST
Tal , you can aggragate/dup both bugs ( #1404565 , #1403581 ) to bug #1404607 as they are all with the same issue & solve it there .
Comment 16 Yaniv Kaul 2017-03-08 14:32:53 EST
Tal, is this going to 4.1, or shall we defer it to 4.2?
Comment 17 Tal Nisan 2017-03-09 08:09:44 EST
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
Comment 18 Yaniv Kaul 2017-03-09 08:26:04 EST
(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?
Comment 19 Allon Mureinik 2017-06-20 05:55:53 EDT
Maor/Tal, with bug 1403581 fixed, is there anything more to do here, or should this be back ON_QA?
Comment 20 Maor 2017-06-20 17:21:34 EDT
Honestly, this feature is basically BZ1403581 and BZ1404607, unless I'm missing anything...
Comment 21 Allon Mureinik 2017-06-21 01:48:19 EDT
(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.
Comment 22 Avihai 2017-06-25 06:35:27 EDT
verified at 4.1.3.4

Note You need to log in before you can comment on or make changes to this bug.