Bug 1343097
| Summary: | cluster creation - cluster size range | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Storage Console | Reporter: | Martin Kudlej <mkudlej> | ||||
| Component: | UI | Assignee: | Karnan <kchidamb> | ||||
| Status: | CLOSED ERRATA | QA Contact: | sds-qe-bugs | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 2 | CC: | deb, julim, nthomas, sankarshan, vsarmila | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 2 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | rhscon-core-0.0.34-1.el7scon.x86_64 rhscon-ceph-0.0.33-1.el7scon.x86_64 rhscon-ui-0.0.47-1.el7scon.noarch | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-08-23 19:54:50 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1344195 | ||||||
| Attachments: |
|
||||||
|
Description
Martin Kudlej
2016-06-06 13:36:17 UTC
In looking at this BZ, out of the 2 items raised, I'd suggest addressing the second item, i.e. If user attempts to set a journal size greater than 1024 (can be in MB or GB), it is missing showing an error/warning message. Note: It does not let you click on Next, so you're stuck in the step without really knowing what you did wrong. Regarding the first item of the limited range of the journal size and ability to use decimals for the journal size value -- I don't think it needs to support decimal places as this is not common, and having both MB and GB allows the user to use an integer if using MB (vs. a number with decimal places with GB). If users follow the Ceph best practices on how to calculate journal size, users should not end up with decimal places in the journal size. Journal size = 2 * (expected throughput * filestore max sync interval) E.g. If your machine is on a 1Gbit line it will do something like 100MB/sec of writes, and you expect the journal to be able to hold the writes for a short period of time, something like 10 ~ 20 seconds: 100MB * 20 seconds = 2000MB Probably the smallest possible journal size would be 2 (and not 1). If we do want to change the range, I might suggest 2 as the smallest possible value. 1024 for the upper limit is probably fine. One more thing to note regarding the error/warning message that "Journal Size is not valid!" is the following:
(1) Avoid using exclamation marks in the message as this could be perceived as "scolding" the user.
(2) You probably don't need to use camel case in the message.
(3) Error/warning messages should be helpful, e.g.
Invalid journal size. Specify a journal size value between 2 and 1024.
Created attachment 1165360 [details]
Journal Size is not valid! message
Related to the journal size error/warning message
(In reply to Martin Kudlej from comment #0) > 1) There is limited range for journal size in create cluster wizard. > There is number range 1-1024 and user can select unit(MB/GB). It is not > specified in design document that number for journal size should be limited > in range 1-1024. I think that this is not problem in most cases and user > pick journal size in GBs. But I think that user should be able to set for > example 2.5 GB(2560 MB where 2560 is not in range 1-1024) which is not > possible now. Personally, I'd be annoyed as an admin if I was restricted to round-figures like this. So, I'm in favor of supporting more flexible values as the size. A quick and non-regressing solution is to increase the range cap to 10240. Which ensures not requiring to use one-decimal-point-into-next-mille kind of scenario (i.e. 2560MiB instead of 2.5GiB). > 2) If user set number bigger than 1024 there is no error message. With the increased cap, most likely it'll not be required. But for safety, a conditional ux feedback should be given to the user for invalid inputs as-you-type. It that doesn't need to be an info-box. Just marking the input colors in red and disabling the workflow-progress should be enough. I'm fine increasing the range cap to 10240 -- makes sense especially when you are using a smaller unit. If there are invalid inputs, as you type, user should get feedback about it. Please refer to http://www.patternfly.org/pattern-library/forms-and-controls/forms/#example-overview-3 for how to display error message for the form entry (and ensure no actions are enabled till all mandatory fields are completed in that step). Tested with ceph-ansible-1.0.5-25.el7scon.noarch ceph-installer-1.0.12-4.el7scon.noarch rhscon-ceph-0.0.32-1.el7scon.x86_64 rhscon-core-0.0.33-1.el7scon.x86_64 rhscon-core-selinux-0.0.33-1.el7scon.noarch rhscon-ui-0.0.47-1.el7scon.noarch and it works. --> VERIFIED 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://access.redhat.com/errata/RHEA-2016:1754 |