1. Proposed title of this feature request

• EgressIP Canary

2. What is the nature and description of the request?

• Consider adding an alert mechanism/deployment that when enabled (optionally? or when an egressIP is added?) will periodically probe listeners via egressIP and alert if a response code is not observed. Objectively we could re-use ingress-canary for this as target backends/route, just adding a new namespace (openshift-egress-canary) with a daemonset that periodically probes outbound using an egressIP and can fire an alert if node egress routing is failing or if traffic cannot be redirected properly through egress addressing. 

3. Why does the customer need this? (List the business requirements here)
EgressIP has limited visibility into it's functionality and state. During an outage there are few methods available to confirm that egress Is working properly or that egress is even related to the problem condition.

Egress on OVNkube while powerful, has been the cause of a number of significant blocker bugs for many production platforms and customers and troubleshooting remains difficult as it's not always clear whether egress was working during an outage. Logging from the egress canary pod would help to confirm timeframes of failovers, outage windows and confirm whether or not egress is currently (or was) impacted during a migration or other impact scenario.

More data/visibility into this service (coupled with the planned remapping of Egress hollistically as level-driven) would be valuable to customers and support teams alike. An easy method for getting this data would be to have a dedicated/automatic deployment which uses an existing egressIP or self-allocates an egressIP (or optionally, can be ENABLED with a new customer-selected egressIP) to serve as a method for auditing traffic flow states when egress is in use. 

4. List any affected packages or components.
egressIP
ovnkubernetes
SDN
ingressCanary
ovnkube-controller