| Summary: | Updating OVF stores may take several minutes more than configured value | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Gilad Lazarovich <glazarov> | ||||
| Component: | BLL.Storage | Assignee: | Liron Aravot <laravot> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Gilad Lazarovich <glazarov> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.6.0 | CC: | acanan, amureini, bugs, glazarov, tnisan | ||||
| Target Milestone: | ovirt-3.6.2 | Keywords: | Automation | ||||
| Target Release: | 3.6.2 | Flags: | tnisan:
ovirt-3.6.z?
rule-engine: blocker? glazarov: planning_ack? glazarov: devel_ack? glazarov: testing_ack? |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | storage | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-01-03 16:40:58 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. Gilad, The Ovf update process updates the storage, thus can always take more than a minute (for example, if you defined 1000 ovf disks). The defined time interval is the time interval in which the update should attempt to run (we schedule a quartz job for that) but it doesn't and can't garantuee the time the update will take. Please direct me to the timeframe in which the ovf update process took you that long, the log contains few hours so i'll be able to take a look at that case. please also specify how many ovf disks you defined per domain. In the meanwhile i'm removing the regression flag as it seems like there's no regression here. thanks, Liron. The configuration value is the duration between the job STARTs, not how long they should take. |
Created attachment 1109987 [details] Full set of logs including those from engine, vdsm instances and ART Description of problem: Updating OVF stores may take several minutes more than configured value Version-Release number of selected component (if applicable): 3.6.2-0.1 How reproducible: 100% when running all tests (over File and Block) Steps to Reproduce: 1. Configure the OvfUpdateIntervalInMinutes to 1 minute and restart the engine 2. Create new VMs with no disks 3. Attach disks to these VMs that reside on the same Storage domain 4. Once engine shows the OVF store has been updated, extract the OVF store for the storage domain containing the disks Actual results: It may take 3+ minutes for the OVF store to get updated Expected results: The update should take about a minute as configured Additional info: Several builds ago, my code had only 75 seconds for the OVF updates to be processed, but this is exceeded regularly now, with up to 4 minutes until the OVF store is actually updated. See attached logs, note string: Positive path, disk 'disk_1_6250_nfs_2_alias' isn't found in VM 'storage_ovf_on_any_domain_2' OVF file which shows it takes about 3 minutes for the OVF store contents to show the disk created