Description of problem: There should be some way to ensure ordering of nfs exports. When there are multiple export lines for a given file system, ordering of these is often important (to grant root access, insecure option for NAT gateways, read-only vs read-write, etc) Version-Release number of selected component (if applicable): How reproducible: Sometimes NFS filesystems get reexported by the cluster, either because some export got deleted, because of configuration changes, etc... This reexporting (or even the initial export when the cluster starts) doesn't preserve the ordering of NFS exports from the config file. Steps to Reproduce: 1. Delete some export 2. Wait 3. The export reappears, but not in the order it is specified in the config file Actual results: Expected results: When an export for a given file system must be refreshed, all exports for that filesystem should be refreshed in the correct order. Additional info: It would be fully acceptable (at least to me) to have an extra attribute in the XML file to specify the ordering if it is difficult to preserve ordering of the parsed data. Order is only important within one export point as far as I can see.
Removing the recover tag should solve this for you for now - that should cause a full restart.
Created attachment 129235 [details] Adds ability to disable recovery (causing service restart) There's no easy way to make rgmanager do "restart this entire branch of a service tree as a recovery operation". For now, we'll just allow loss of a specific exports to trigger a service bounce. Add allow_recovery="0" to any nfs client where that client is fatal. Less than ideal, but it works. In a future release, we may add inheritance support (e.g. the way fsid works) so that you don't need to set this as a per-client option.
I have patched the file and edited my config. Just a bit too chicken to actually test it right now... We will have to bring down the whole server room within the next weeks so I'll test then. By the way... Looking at the patch, it seems like I should add allow_recover=0, not allow_recovery.
correct -- allow_recover="0" :)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0557.html