Bug 1123052
| Summary: | [HC] Validate glusterfs volume parameters required for ovirt storage domains | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Federico Simoncelli <fsimonce> |
| Component: | vdsm | Assignee: | Ala Hino <ahino> |
| Status: | CLOSED ERRATA | QA Contact: | Elad <ebenahar> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.5.0 | CC: | adahms, ahino, amureini, anbabu, bazulay, fsimonce, gklein, lpeer, nsoffer, sabose, sbose, scohen, vbellur, yeylon, ykaul |
| Target Milestone: | ovirt-3.6.0-rc | ||
| Target Release: | 3.6.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | v4.17.0.8 | Doc Type: | Bug Fix |
| Doc Text: |
Red Hat recommends using glusterfs volumes that are replica type and replica count 1 or 3. Previously, VDSM did not validate glusterfs volumes when adding glusterfs storage domains. As a result, administrators could configure glusterfs volumes with an unsupported replica type and count. VDSM now validates the required parameters before using a glusterfs volume as a storage domain, and if the glusterfs volume configuration is not supported, there is a warning.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-03-09 19:23:35 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
Federico Simoncelli
2014-07-24 17:57:30 UTC
Sahina, your team or mine? (In reply to Allon Mureinik from comment #1) > Sahina, your team or mine? Allon, I think the check for if the options are present could be done by the storage team. We could set the options on the volume as part of the "Optimize for virt store" option available on the volume - this can be done by the gluster team Anmol, does your patch referenced in the BZ solve the issue, or is there anything else that should be done here? My patch 1. Checks if the volume is of the recommended configuration : a. If no, issues a warning just in case if it is not.However the user can still go ahead and optimise the volume for virt store in which case the UI enables the required options if the volume is of replicate type. b. If yes, optimise for virt store. So in all, the patch is a UI patch with validation + options setting handled from UI. (In reply to Allon Mureinik from comment #3) > Anmol, does your patch referenced in the BZ solve the issue, or is there > anything else that should be done here? So after this patch, what are we currently missing in order to close this bug? Firstly,My sincere apologies for a very delayed response. I don't think we are missing anything now as the required options are being set directly from UI and the additional options required are being handled from UI in the attached patch set upstream.And the new options are optional in the sense the user can choose to force optimise thereby overriding/ignoring the suggested configuration. Federico, this satisfies us? (In reply to Tal Nisan from comment #7) > Federico, this satisfies us? No, this RFE was filed to validate the parameters in VDSM when it's creating/connecting/using the Gluster Storage Domain. Ala, I think you can take care of this as part of your re-working of gluster mounting. Ala, please add some doctext explaining this feature. Ala, please add the appropriate doctext. Note that according to bug 1238093, we also support replica count of 1 (which was introduced a tad later, and isn't visible in the patches attached to this bug). VDSM validates that the Gluster volume resides on 1 or 3 bricks while using replica as expected. If a 2 bricks volume is given, the operation is aborted by VDSM with a UnsupportedGlusterVolumeReplicaCountError but engine doesn't know how to handle with it and fails with a NullPointerException: https://bugzilla.redhat.com/show_bug.cgi?id=1270732. In case a distributed volume is provided for the domain, the operation is allowed and the domain is created successfully (tried with distributed 2 and 3) I tested also with replica 6 and the results are the same as replica 2. Tested using: rhevm-3.6.0-0.18.el6.noarch vdsm-4.17.8-1.el7ev.noarch Behavior here changed per bug 1286565. Hence, doctext changed accordingly, i.e. if volume replica is not supported, there is a warning in the log instead of failing the operation. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-0362.html |