Description of problem ====================== During "Create Storage Cluster" workflow in "Internal - Attached Devices" mode (aka LSO), OCP Console acts as if there were no storage devices or nodes to use, reporting no results and disabling the options at first, but later after a while, updates the view and shows results of the detection. This is confusing, esp. when one tries to enable Arbiter stretch cluster. The fact that detection is not yet ready or ongoing should be clearly indicated until the results are accurate. Version-Release number of selected component ============================================ OCP 4.7.0-0.nightly-2021-02-09-224509 LSO 4.7.0-202102110027.p0 OCS 4.7.0-260.ci How reproducible ================ 3/3 Steps to Reproduce ================== 1. Install OCP cluster on vsphere platform, with worker nodes having local storage block devices attached (to be used later via LSO) 2. Install LSO and OCS operators 3. Via OCP Console, start "Create Storage Cluster" flow, and select "Internal - Attached Devices" mode. 4. Configure Local Volume Set during "Create Storage Class" step 5. Try to enable arbiter mode during "Storage and Nodes" step Actual results ============== During "Create Storage Class" step, at first no suitable nodes with local devices are shown. Then after a while, nodes are reported. During "Storage and Nodes" step, at first storage class Expected results ================ When a detection is not yet finished so that OCP Console can't present it's final results yet, it should indicate that the details are being loading or detected. Additional info =============== This could be confusing for first time users, especially when trying to use arbiter mode, because during about first 10 or 20 seconds of "Storage and Nodes" view, "Enable arbiter" option can't be enabled. Since there is "Advance Subscription" notice for this feature, and it takes significant time for the results to be shown in the page, customers could be mislead into thinking that they don't have proper subscription, while the "enable arbiter" option is actually available.
Created attachment 1756713 [details] screenshot #1: Create Storage Cluster view, during "Storage and Nodes" step, with an option to enable Arbiter mode See screenshot #1 capturing Create Storage Cluster workflow during "Storage and Nodes" step, with an option to enable Arbiter mode. When one arrives there for the first time, arbiter mode can't be enabled no matter what. Customer not aware of this could reasonably suspect that it's because a problem with subscription or minimum requirements, as both details are covered in info boxed next to the enable arbiter option. This could send first time users to check details which may not be necessary to check again. Only those who will retry to click on enable arbiter option later again will notice that the option is not in fact blocked.
Moving out of 4.7 Yes its takes time for leading the nodes. I remember there was a similar bz reported, will check and update here
@mbukatov , sounds like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1901720 ??
Looks like root cause of BZ 1901720 is mostly to blame here as well. That said, this bug describes additional details: - it describes use case with arbiter stretch cluster, where the problem could cause specific additional confusion - the expected behavior is bit different, I expect that UI will be able to tell user that LSO plumbing work is not yet finished via some info box, so that one can distinguish empty results from ongoing detection So for the tracking purposes, I would like to keep it open for qe team to make sure this use case is verified. If you plan to fix the issue at once, you can set the older bz 1901720 as blocking of this bug.
I don't see how bug 1901720 is related here. Bug 1901720 is about a cosmetic issue in which it takes some time to find the disks for storagecluster creation while here (bug 1928285), it is about the fact that you can create the storagecluster with a single deviceset only and for using more disks, the admin needs to perform add capacity operations
sorry, please disregard my previous comment, I thought this bug is bug 1928319. About the 1901720 and this one (1928285), IMO, if the root cause is the same, maintaining 2 BZs is redundant.
Additional information: > This could be confusing for first time users, especially when trying to use > arbiter mode, because during about first 10 or 20 seconds of "Storage and > Nodes" view, "Enable arbiter" option can't be enabled. I retried this process and measured time it takes for arbiter mode to be available when one arrives to "Storage and Node" view for the first time, and the result is 65 seconds.
*** This bug has been marked as a duplicate of bug 1901720 ***
With OCP 4.8.0-0.nightly-2021-05-13-002125, I see that BZ 1901720 is addressed, but this one is not. Based on this, I'm reopening the bug, because it can't be a duplicate of BZ 1901720 when it's fix doesn't have any effect here.
That said, I see that BZ 1901720 is still in POST with it's patch not merged yet, so it's possible that I considered BZ 1901720 addressed because of other change, and that the actuall fix of BZ 1901720 will fix this bug as well.
Yes, so I am marking this as a duplicate of BZ 1901720 again. Please verify it once original BZ is moved to ON_QA *** This bug has been marked as a duplicate of bug 1901720 ***
I disagree, moreover the issue is still not addressed. What we need to make sure is that: - let user know that localvolumeset is being created (something is going on) - localvolumeset and it's storage class has been created (something has just finished)
I just checked that this problem is still applicable to OCP/ODF 4.9
One possible solution here would be to include additional step in the wizard, which would track the progress of setup for localvolumeset and it's storageclass.
Testing with: - OCP 4.10.0-0.nightly-2021-11-26-060537 - LSO 4.9.0-202111151318 - ODF 4.9.0-249.ci And I see that when LVS starts to be provisioned before 3rd step "Capacity and nodes" is shown, Console reports that "PVC are being provisioned", in a similar way how it's done during disk discovery phase earlier. >>> VERIFIED
Created attachment 1843778 [details] verification screenshot
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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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://access.redhat.com/errata/RHSA-2022:0056