| Summary: | The optimizer result is not updating according to the engine status | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] ovirt-optimizer | Reporter: | Shira Maximov <mshira> | ||||
| Component: | General | Assignee: | Martin Sivák <msivak> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Shira Maximov <mshira> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 0.13 | CC: | bugs, mavital, mgoldboi, mshira | ||||
| Target Milestone: | ovirt-4.0.6 | Flags: | rule-engine:
ovirt-4.0.z+
rule-engine: ovirt-4.1+ rule-engine: blocker+ mgoldboi: planning_ack+ msivak: devel_ack+ mavital: testing_ack+ |
||||
| Target Release: | 0.14 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | ovirt-optimizer-0.14 | Doc Type: | Bug Fix | ||||
| Doc Text: |
Cause:
The oVirt SDKv4 can throw an error when the engine is not available or the login fails. The error was not properly handled. This could happen when the engine was restarted for example.
Workaround:
All is fine again when the optimizer is restarted.
Consequence:
The refresh threads died.
Fix:
The error is now properly handled (and logged).
Result:
The optimizer refresh thread continues in degraded mode (no v4 features) and without a crash when the SDK v4 returns an error.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-01-18 07:25:19 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1397100 | ||||||
| Attachments: |
|
||||||
How long did you wait between clicking and observing? It can take even 30 seconds (usually not more) for the status to change... (In reply to Martin Sivák from comment #1) > How long did you wait between clicking and observing? It can take even 30 > seconds (usually not more) for the status to change... it's been an hour by now, and it's hasn't change. And is the VM actually running? What does the browser console and optimizer log say? Is the optimizer stuck again? The VM is running, the optimizer is not stuck, there are no errors in optimizer log and in the browser. So the optimizer was stuck in this case. The optimizer engine is working fine as is the result reporting, but the data collection threads are stuck for some reason. This happens after a random time according to the log so I do not know the reproduction steps atm. The cause of this bug is when restarting the ovirt-engine service. Steps to Reproduce: 0. restart the ovirt engine service 1. have a setup with optimizer installed 2. right click on vm -> start optimize 3. go to clusters - > optimizer - > "start on host XXX" 4. look at the optimizer tab So it seems this is only triggered by a failure to connect to the engine VM. That is not nice, but nothing that would be happening too often I hope. I am lowering the priority to high and I think a 4.0.6 patch and a release note in 4.0.5 should handle that just fine. verified on : ovirt-optimizer-0.14-2.el7ev.noarch verification steps: Steps to Reproduce: 0. restart the ovirt engine service 1. have a setup with optimizer installed 2. right click on vm -> start optimize 3. go to clusters - > optimizer - > "start on host XXX" 4. look at the optimizer tab- OK |
Created attachment 1215842 [details] optimizer print screen Description of problem: after performing the optimizer start, the vm still appears in 'VMS THAT SHOULD BE STARTED' and in 'MIGRATION / START STEPS' Version-Release number of selected component (if applicable): ovirt-optimizer-0.13-1.el7ev.noarch ovirt-optimizer-ui-0.13-1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. have a setup with optimizer installed 2. right click on vm -> start optimize 3. go to clusters - > optimizer - > "start on host XXX" 4. look at the optimizer tab Actual results: the vm still appears in 'VMS THAT SHOULD BE STARTED' and in 'MIGRATION / START STEPS' Expected results: the vm should not appear in the 'VMS THAT SHOULD BE STARTED' and in 'MIGRATION / START STEPS' Additional info: