Description of problem: Many a times a user will set a volume options but did not restart the volume and did not know that the option did not activate at all. I have a suggestion. When a user run 'gluster volume set help', besides getting a description and the default value of the option, we can added a requirement: section to it. For example: # gluster volume set help ..... Option: performance.write-behind Default Value: on Description: enable/disable write-behind translator in the volume. Requirement: None <<<<<===== ..... Option: performance.strict-write-ordering Default Value: off Description: Do not let later writes overtake earlier writes even if they do not overlap Requirement: None <<<<<===== ..... Other values would be volume restart, client remount, both. Version-Release number of selected component (if applicable): RHGS-3.1.X How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: N/A Expected results: N/A Additional info:
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