- Brief overview of fencing and HA in general - How fencing and HA differ in a Grafton deployment - Supported fencing policies for Grafton and when each is useful
*** Bug 1388824 has been marked as a duplicate of this bug. ***
I don't think we have any deep details about fencing flow in our documentation, we have described only fencing related parameters shown in UI. There are also other parameters, which are changeable only using engine-config, but those are probably described only in some KCS articles. If you would like to describe fencing flow in detail, then please take a look at following resources: http://www.ovirt.org/develop/developer-guide/engine/automatic-fencing/ http://www.ovirt.org/develop/release-management/features/engine/fence-kdump/#fencing-flow-with-fence-kdump https://www.youtube.com/watch?v=RAGV_za_Qvw https://www.slideshare.net/MartinPeina/integrating-kdump-into-ovirt https://www.youtube.com/watch?v=V1JQtmdleaM http://www.slideshare.net/MartinPeina/host-fencing-in-ovirt-fixing-the-unknown-and-allowing-vms-to-be-highly-available Feel free to ask if you have any additional questions about fencing details
Laura, I think we should provide more clarity on why did we introduce gluster fencing policies rather than explaining what fencing does. what do you think ? 2.1 section title has to be changed to "Configuring Gluster fencing policies"
This adds gluster related fencing policies for hyper-converged clusters. Previous fencing policies ignored Gluster processes. But in Hyper-converged mode, fencing policies are required to ensure that a host is not fenced if there is a brick process running, or to ensure no loss of quorum when shutting down the host with an active brick. New fencing policies will be added for Gluster Quorum and Brick Status. These policies can be enabled at Cluster level. These policies will be checked after all other existing policies. Similar to existing fencing policies, these policies will not prevent SSH Soft fencing. Laura, above info can be added to the guide instead of the paragraph "Fencing allows a cluster to enforce performance and availability policies and react to unexpected host failures by automatically rebooting virtualization hosts." But you can still have the link for fencing present in the guide. @sahina, can you please confirm ?
The document seems to indicate that these are the only policies that are needed - would be good to mention that in addition to the existing policies, for hyperconverged clusters, the gluster policies need to be enabled as well. This is to prevent a host from being fenced in a way that gluster storage becomes unavailable.
Laura, not sure if we can have this in the doc "and are the last factor in determining whether a node is fenced."
changes in the doc looks good. Moving this bug to verified state
Fixed in RHGS 3.3 documentation.