Bug 1463083
Summary: | RESTAPI - Attaching a storage domain to 4.0 DC fails due to discard after delete is now True by default but not supported | ||||||
---|---|---|---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Avihai <aefrat> | ||||
Component: | BLL.Storage | Assignee: | Idan Shaby <ishaby> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Avihai <aefrat> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 4.2.0 | CC: | amureini, bugs, ishaby, melewis, ylavi | ||||
Target Milestone: | ovirt-4.2.0 | Keywords: | Automation, AutomationBlocker | ||||
Target Release: | --- | Flags: | rule-engine:
ovirt-4.2+
amureini: devel_ack+ |
||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Release Note | |||||
Doc Text: |
Previously, when adding a new data storage domain without stating the values of Discard After Delete (DAD) and storage format, their default values were previously calculated according to the data center version of the host that added the storage domain. Discard After Delete was set to true for a data center greater than or equal to Red Hat Virtualization 4.1, otherwise it was set to false. The storage format was set V4 for the a data center greater than or equal to Red Hat Virtualization 4.1, otherwise it was set to V3. This was a bad heuristic since the data center of the host that added the domain is a random data center and it is not necessarily the data center that the domain will be later attached to. Now, the logic has been changed so that the default storage format for new data domains will be the latest format, currently it is V4. For non-data domains, nothing has changed V1 was and will remain the default value. The default value of Discard After Delete will be calculated according to the storage format and is set to true for storage formats greater than or equal to V4, otherwise it is set to false.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-12-20 11:38: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: | |||||||
Attachments: |
|
Description
Avihai
2017-06-20 06:06:27 UTC
No issues with attaching SD to 4.1/4.2 DC , only with 4.0 this issue occurs. Maybe a solution can be to leave discard after delete flag as False by default so we can still work with 4.0 DC's . Why was this changed to True in the past 2 weeks? This is the result of bug 1456414. IMHO, if this is done in two steps - create succeeds, and then the attach fails, it's a user error (i.e., NOTABUG), provided that bug 1456414 is documented properly in the release notes. Yaniv - your two cents? (In reply to Allon Mureinik from comment #2) > This is the result of bug 1456414. "Of the fix to bug 1456414", of course - i.e., this behavior is intentional. This is not a bug in the sense of "the system behaves in a way we didn't inted it to", but may still be a bug in the sense of "the intended behavior is a bad idea" - pending PM's input on this. Yaniv , can you please update what is the decision here? This blocks multiple automation TC's(in upgrade&qcow2_v3 TP's) runs on 4.2 that currently create 4.0 SD's without stating DAD to be disabled & thus fails. So if this is not a bug we(QA automation) need to update the create storage domain function & add a configurable DAD boolean optional variable & change the current TC's accordingly. The issue here is that the REST API call was to create v3 SD that should not have a different default than before. I think we should make sure when we change a default for v4 SD it doesn't affect older SD versions. Yaniv, Avihai - thanks for clarifying, I see the point now. I debugged through the code and here's what I think is going on: - If you supply a DAD version, the engine attempts to use it - this makes sense to me. - If you don't supply a DAD value, but do supply a DC, the engine calculates the default DAD version from the DC level - still makes sense. - If you don't supply a DAD or a DC, the DC is implicitly taken for the host (kinda-sorta makes sense), and the DAD value is calculated from that. What happens here, if I'm following the case correctly, is an attempt to create a detached SD using a host from a 4.1 DC (which causes DAD=true), and then attempting to attach it to a 4.0 DC, which then fails, as this is not supported. I don't think this is a particularly common case, but it's a bug nonetheless, and I agree with Yaniv's comment 5 - if no DC nor DAD is given, we should attempt to take the DAD value from the storage format, which kinda-sorta implies a potential DC level. Idan - can you please handle this? verified at 4.2.0-0.0.master.20170707124946.gitf15a6d9.el7.centos This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |