| Summary: | [RFE] It would be great for users to know whether a volume option requires a volume restart or client remount. | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | Oonkwee Lim_ <olim> |
| Component: | glusterd | Assignee: | Nithya Balachandran <nbalacha> |
| Status: | CLOSED DEFERRED | QA Contact: | Bala Konda Reddy M <bmekala> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | rhgs-3.1 | CC: | amukherj, atumball, bkunal, mchangir, nbalacha, olim, ravishankar, rhs-bugs, sasundar, storage-qa-internal, vbellur |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened, ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | Improvements | ||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-09 11:32:30 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1408949, 1468976, 1472361, 1481177 | ||
|
Description
Oonkwee Lim_
2016-02-04 18:56:48 UTC
Olim, For your information, all the volume options should be set on the volume dynamically without any requirement. If not, then that should be escalated for a bug. After setting the option using 'gluster volume set', anyone can validate the option, using 'gluster volume info' or 'gluster volume get' As I remember all the volume options can be set on the volume without any requirements on the volume except for ( allow-insecure option ). Share your thoughts Is there a way to set it as a flag? (like DOC/SETTABLE/ etc?) So that we can not keep dealing with a spreadsheet or wiki for this, instead the code would let us know. (In reply to Amar Tumballi from comment #6) > Is there a way to set it as a flag? (like DOC/SETTABLE/ etc?) > > So that we can not keep dealing with a spreadsheet or wiki for this, instead > the code would let us know. IMO, very well possible. We just need to introduce a new flag and as part of volume get <option> this flag can be displayed to let user know. Except for brick mux, I do not know of any other options which require a restart. I would like a list of these first and justification for why they require a restart before we proceed. RPC: * network.ping-timeout - re-mount required on client * transport.listen-backlog - volume restart required * transport.tcp-user-timeout - volume restart required * transport.socket.keepalive - volume restart required * transport.socket.keepalive-time - volume restart required * transport.socket.keepalive-interval - volume restart required * transport.socket.keepalive-count - volume restart required All the above are socket related options and any changes will be applicable to new connections only. So, to apply the changes to all connections, a volume restart is required. transport.listen-backlog is applicable when volume is started since it is only applicable to the *listening* socket. AFR: cluster.consistent-metadata - re-mount required on client as noted in comment #3. Note that the remount is required only to remove entries that were possibly cached by the fuse client *before* the option was set. Otherwise, the remount is strictly not required. @Amar: I would like to have this RFE done as it gives a better user and a support experience. I would say better user experience as customer don't need to ask support on what do be done if any parameter is changed and I would say better support experience as support team can provide better action item while recommending some parameter changes. Ack! We are working on this. With RHGS4.0 we want to tackle some of this. Bipin, As this BZ will be addressed in RHGS 4, as per the agreement and guidance received from Sankarshan/Rejy, we decided to close these bugs with a deferred as reason. If required you can file a tracker bug in downstream to track these changes. Please let me know if this looks fine with you. I'll be closing this bug next week. Thanks, Atin |