Bug 1248453
Summary: | [engine-backend] Gluster domain deactivation ends with a failure while the domain is master | ||
---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Elad <ebenahar> |
Component: | General | Assignee: | Ala Hino <ahino> |
Status: | CLOSED WORKSFORME | QA Contact: | Elad <ebenahar> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.17.0 | CC: | acanan, amureini, bazulay, bugs, ecohen, gklein, laravot, lsurette, mgoldboi, nsoffer, rbalakri, tnisan, ycui, yeylon, ylavi |
Target Milestone: | ovirt-3.6.2 | Flags: | amureini:
needinfo+
amureini: ovirt-3.6.z? tnisan: ovirt-4.0.0? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
Target Release: | 4.17.17 | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | storage | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-13 11:50:50 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
Elad
2015-07-30 10:37:01 UTC
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. this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high Both Elad and I failed to reproduce. This bug happens because unsynced clocks, we can use -m on tar to solve that issue. We shouldn't fail to migrate the master because of that. Allon/Nir - what's your take on that? (In reply to Liron Aravot from comment #4) > This bug happens because unsynced clocks, we can use -m on tar to solve that > issue. We shouldn't fail to migrate the master because of that. > > Allon/Nir - what's your take on that? Sounds reasonable to me. Nir? (In reply to Liron Aravot from comment #4) > This bug happens because unsynced clocks, we can use -m on tar to solve that > issue. We shouldn't fail to migrate the master because of that. > > Allon/Nir - what's your take on that? Did tar fail because the timestamps are in the future? Maybe we don't handle tar exit code properly? Anyway I don't think we should care about the timestamps, so if using -m avoid this issue, why not. after a check, tar isn't failing because of the timestamp but logs those warnings in stderr which is misleading (and already confused people when this bug was investigated), we should avoid those timestamp errors when performing the operation. |