Bug 1720908
| Summary: | Remove host fails when host is in maintenance as it's lock due to DisconnectHostFromStoragePoolServersCommand - host in maintenance should not be locked | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Avihai <aefrat> | ||||
| Component: | BLL.Storage | Assignee: | Ahmad Khiet <akhiet> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Evelina Shames <eshames> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.3.4.3 | CC: | akhiet, bugs, bzlotnik, frolland, masayag, mburman, tnisan | ||||
| Target Milestone: | ovirt-4.3.6 | Keywords: | Automation, Regression | ||||
| Target Release: | 4.3.6 | Flags: | pm-rhel:
ovirt-4.3+
pm-rhel: blocker? |
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | ovirt-engine-4.3.6 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-09-26 19:43:18 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: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Avihai
2019-06-16 13:08:28 UTC
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. After debugging the mentioned issue in this bug, and discussed it with Benny, we found that the status updated in the job table in the database reflects the real status of the host, and what the status in the log is not accurate as mentioned in this bug. so we have the following solutions: 1- check job table if the status in 'finished' state, then remove command can be issued. 2- revert the bug Bug 1667723 https://bugzilla.redhat.com/show_bug.cgi?id=1667723 3- stay with the current state and make no change. what do you think? (In reply to Ahmad Khiet from comment #2) > After debugging the mentioned issue in this bug, and discussed it with > Benny, > we found that the status updated in the job table in the database reflects > the real status of the host, and what the status in the log is not accurate > as mentioned in this bug. What do you mean by that? So the state I get in RESTAPI from the hosts are wrong/different than from the DB? If so this issue should be solved and host be solution#0 . In automation, I wait till the host is in 'maintenance' and only then try to remove the host. But as there is still running related tasks/jobs there this operation fails. > so we have the following solutions: > > 1- check job table if the status in 'finished' state, then remove command > can be issued. This is a workaround, not a bug solution. We need the host state to reflect it's true state. host DB state = logs host state = REST host state (which user use in automation/ansible) > 2- revert the bug Bug 1667723 > https://bugzilla.redhat.com/show_bug.cgi?id=1667723 Also not good as then we return the issue when the host is removed while disconnecting from storage which is bad. > 3- stay with the current state and make no change. No way, as now most of our users also use ansible automation and will wait until the host is in maintenance and expect DB state reflected in logs/REST. How hard is it to implement the logic solution which is: Wait until all related jobs/tasks are done and then move the host to maintenance? This is the root cause of this bug. If the state I get in RESTAPI from the hosts is wrong/different than from the DB than this issue should be addressed. as Moti sent in the mailing list. I have added a lock and wait with a timeout of 1 minute for RemoveVdsCommand. Verified on engine 4.3.6-0.1. This bugzilla is included in oVirt 4.3.6 release, published on September 26th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.6 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |