Bug 1990231
| Summary: | Setting a host to maintenance shouldn't be blocked when having 'active' image transfer | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Eyal Shenitzky <eshenitz> |
| Component: | BLL.Storage | Assignee: | Artiom Divak <adivak> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Evelina Shames <eshames> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.4.7 | CC: | ahadas, bugs, dfodor, michal.skrivanek, nsoffer, sfishbai |
| Target Milestone: | ovirt-4.5.3 | Keywords: | ZStream |
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.5?
pm-rhel: planning_ack? pm-rhel: devel_ack+ pm-rhel: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-engine-4.5.3.1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-10-03 19:01:06 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: | |||
|
Description
Eyal Shenitzky
2021-08-05 05:58:01 UTC
There are few validations for similar oongoing tasks (e.g. jobs), if possible that should be addressed as well Before we remove the validation, we must ensure that code handling preparing for maintenance state is considering active image transfers. Otherwise the host may be disconnected from storage while an image transfer is active. Previously we did not need to handle this case because we had the validation. Same issue for other ongoing tasks (comment 1) that are likely not handled yet. We are past 4.5.0 feature freeze, please re-target. this is supposedly not that hard, and still quite useful. To fix this we need to make two changes: 1. In VirtMonitoringStrategy#canMoveToMaintenance we also need to check if there's an ongoing transfer on the host 2. In TransferDiskImage we need to make sure not to start a transfer on a host that is in PreparingToMaintenance status (In reply to Arik from comment #6) > To fix this we need to make two changes: > 1. In VirtMonitoringStrategy#canMoveToMaintenance we also need to check if > there's an ongoing transfer on the host > 2. In TransferDiskImage we need to make sure not to start a transfer on a > host that is in PreparingToMaintenance status Not starting a transfer on host in PreparingToMaintenance sounds like nice improvement but it is not enough. If there are already active transfers we need to either wait for them or cancel them, but currently cancelling image transfer is flaky and likely to end in stuck transfer when the user cancel the transfer after failure (same issue we had in backup). (In reply to Nir Soffer from comment #7) > (In reply to Arik from comment #6) > > To fix this we need to make two changes: > > 1. In VirtMonitoringStrategy#canMoveToMaintenance we also need to check if > > there's an ongoing transfer on the host > > 2. In TransferDiskImage we need to make sure not to start a transfer on a > > host that is in PreparingToMaintenance status > > Not starting a transfer on host in PreparingToMaintenance sounds like nice > improvement > but it is not enough. > > If there are already active transfers we need to either wait for them or > cancel them, > but currently cancelling image transfer is flaky and likely to end in stuck > transfer when > the user cancel the transfer after failure (same issue we had in backup). Right, that's covered by #1 above - just like we do it for VMs that run on the host QE doesn't have the capacity to verify during 4.5.1 This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status. |