Bug 1136916
| Summary: | [RFE] Add visual element to LUNs already in use by Storage domain in add External (Direct Lun) screen | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Gilad Lazarovich <glazarov> | ||||||
| Component: | RFEs | Assignee: | shani <sleviim> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Shir Fishbain <sfishbai> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | --- | CC: | acanan, bugs, mgoldboi, sleviim, srevivo, tnisan, ykaul, ylavi | ||||||
| Target Milestone: | ovirt-4.2.5 | Keywords: | FutureFeature | ||||||
| Target Release: | 4.2.5 | Flags: | rule-engine:
ovirt-4.2?
ebenahar: testing_plan_complete- ylavi: planning_ack? rule-engine: devel_ack+ rule-engine: testing_ack+ |
||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | ovirt-engine-4.2.5 | Doc Type: | Enhancement | ||||||
| Doc Text: |
Feature:
Add a visual element to LUNs already in use by storage domain in add External (Direct Lun) screen.
Reason:
Having the visual element will allow the user to skip such LUNs more efficiently.
Result:
LUNs which are already used by an external storage domain won't be able to be selected and appear as grayed out with an N/A button on the 'Actions' column.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2018-07-31 15:26:56 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
Gilad Lazarovich
2014-09-03 15:11:39 UTC
Shani, iirc you handle a similar request in the same dialog, is it the same? Created attachment 1439599 [details] Solved issue for identifing external luns. This one was solved as a part of this patch: https://gerrit.ovirt.org/#/c/86187/. As you can see in the screenshot attached, luns which are already part of other iscsi storage domain have an N/A label on the 'Actions' column and their line is grayed out. Unlike a lun which is a part of the current (managed) iscsi storage domain, this one has a green V mart on the most left column, and it should be grayed out in case it can't be extended. This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?. INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No external trackers attached] For more info please contact: infra (In reply to shani from comment #3) > Created attachment 1439599 [details] > Solved issue for identifing external luns. > > This one was solved as a part of this patch: > https://gerrit.ovirt.org/#/c/86187/. the referenced patch has been included in ovirt-engine-4.2.1.2. Moving to QE. If the addition of visual element to LUNs is for a new virtual disk? Because it doesn't appear there but only in manage domain. You are right, I'll work on a patch fixing it. Moving back to assigned. Thanks! This issue was discussed before here [1], and it seems that this operation should not be blocked (i.e., not block the ability to create a direct lun disk over a lun which already in use). [1] https://bugzilla.redhat.com/show_bug.cgi?id=980162 Therefore, moving back to on_qa We didn't claim the operation of adding LUN that is part of a domain should be blocked. The issue is that this bug was reported on the add direct LUN prompt and the fix is on manage domains prompt. After a f2f talk, the current patch was suggested. The comment:"LUN is already part of a Storage Domain: iscsi_0" is highlighted with an exclamation mark. 4.2.5-0.1.el7ev This bugzilla is included in oVirt 4.2.5 release, published on July 30th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.5 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. |