+++ This bug was initially created as a clone of Bug #1117943 +++
Description of problem:
This RFE is part of the request is to introduce logic in the fencing workflow for the engine to determine if an inability to communicate with external hosts is because it is having network connectivity issues, or if there is a legitimate problem with the remote host.
We should track the physical devices (i.e., interface, bond) used to establish connectivity from Engine to the hosts in the 'rhevm' logical network. In the event of a physical connectivity problem of an interface, we should be able to alert that so that the fencing flow will take that into consideration and allow the environment time to stabilize/reestablish connectivity with the hosts.
Infra/Engine portion of interface monitoring logic for fencing storms.
This process is running on an ongoing basis and providing a mechanism to let the engine know if one of its interfaces has changed state within a certain amount of time. Since connectivity to, and status of, hosts is sensitive to network connectivity, it is important that we understand first if the engine host is having networking issues, or if there is an actual problem lies within the network or against hypervisor hosts.
In this flow, before initiating the fence command over the fencing network to the target host, the engine will first check to determine if its network is suspect from a state change. If the networking state has changed within a configurable amount of time (default 10 minutes), the engine will not issue fencing commands, and will instead provide sufficient time for the environment to stabilize and for all hypervisor hosts to return to an operational state.
There will be an option in the Fencing Policy sub menu (Defined by BZ 1118879) to enable or disable the following option:
"Disrupt fence request if engine has network connectivity failures"
Targeting 3.6 pending networking effort required to complete BZ 1117943.
Per past discussions with scott,
Closing this RFE as won't fix.