Bug 1472289
| Summary: | No clear method to multiplex all bricks to one process(glusterfsd) with cluster.max-bricks-per-process option | |||
|---|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Nag Pavan Chilakam <nchilaka> | |
| Component: | glusterd | Assignee: | Samikshan Bairagya <sbairagy> | |
| Status: | CLOSED ERRATA | QA Contact: | Nag Pavan Chilakam <nchilaka> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | rhgs-3.3 | CC: | amukherj, rcyriac, rhinduja, rhs-bugs, storage-qa-internal, vbellur | |
| Target Milestone: | --- | |||
| Target Release: | RHGS 3.3.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | brick-multiplexing | |||
| Fixed In Version: | glusterfs-3.8.4-35 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1472417 (view as bug list) | Environment: | ||
| Last Closed: | 2017-09-21 05:02:13 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: | 1472417 | |||
| Bug Blocks: | 1417151 | |||
|
Description
Nag Pavan Chilakam
2017-07-18 11:35:45 UTC
We have a plan to make the default to 0 instead of 1 which would ensure that once we fall back to default with brick mux enabled all the bricks get attached to a single process. However we'd need to ensure that volumes are restarted to have this into effect. @Samikshan - can you please send an upstream patch? (In reply to Atin Mukherjee from comment #1) > We have a plan to make the default to 0 instead of 1 which would ensure that > once we fall back to default with brick mux enabled all the bricks get > attached to a single process. However we'd need to ensure that volumes are > restarted to have this into effect. > > @Samikshan - can you please send an upstream patch? Completely fine with the restart requirement. One more question, if we tag 0 to default brick mux feature, then what about 1. It has no importance. It more of breaks brick mux feature. It may be better to set both 0 and 1 to the default brick mux feature Having both 0 and 1 as default value doesn't make any sense to me. What we could do at best is have 0 as default and CLI doesn't allow this option to be configured with value as 1. Does it make sense? (In reply to Atin Mukherjee from comment #3) > Having both 0 and 1 as default value doesn't make any sense to me. What we > could do at best is have 0 as default and CLI doesn't allow this option to > be configured with value as 1. Does it make sense? makes sense upstream patch : https://review.gluster.org/#/c/17819/ downstream patch : https://code.engineering.redhat.com/gerrit/#/c/112934/ on_qa validation:
With brick mux on:
1)should not be allowed to set value to 1, as it creates confusion
2)default must be zero
3)must be allowed to set any value b/w {0,2..n}, where n is a postive whole number(other than 1)
All the above must also reflect in behavior, ie if value is set to 4, then only max 4 bricks per node must be associated with one glusterfsd proc
validation:
[root@dhcp35-192 ~]# gluster v get all all
Option Value
------ -----
cluster.server-quorum-ratio 51
cluster.enable-shared-storage disable
cluster.op-version 31101
cluster.brick-multiplex on
cluster.max-bricks-per-process 0
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 0
volume set: success
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 1
volume set: failed: Brick-multiplexing is enabled. Please set this option to a value other than 1 to make use of the brick-multiplexing feature.
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 2
volume set: success
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 3
volume set: success
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 0
volume set: success
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 1
volume set: failed: Brick-multiplexing is enabled. Please set this option to a value other than 1 to make use of the brick-multiplexing feature.
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 3
volume set: success
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 199
volume set: success
As all the above cases passed, hence moving to verified
testversion:3.8.4-35
with brick mux off:
1)default should show as 0
2)should not be allowed to change this value
3)brick mux should not be in effect
Validation:
if we try to set value , when brick mux is off, getting below error as expected:
[root@dhcp35-192 ~]# gluster v get all all
Option Value
------ -----
cluster.server-quorum-ratio 51
cluster.enable-shared-storage disable
cluster.op-version 31101
cluster.brick-multiplex disable
cluster.max-bricks-per-process 0
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 10
volume set: failed: Brick-multiplexing is not enabled. Please enable brick multiplexing before trying to set this option.
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 0
volume set: failed: Brick-multiplexing is not enabled. Please enable brick multiplexing before trying to set this option.
[root@dhcp35-192 ~]# gluster v set all cluster.max-bricks-per-process 1
volume set: failed: Brick-multiplexing is not enabled. Please enable brick multiplexing before trying to set this option.
raised cosmetic bug 1474342 - reset cluster.max-bricks-per-process value when brick mux is disabled 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/RHBA-2017:2774 |