Summary

A problem may present itself where an on-host asset that relates to a secondary network CNI plugin (e.g. a bridge or a master interface for macvlan, etc) is modified outside of the typical CNI ADD / CNI DEL lifecycle and disrupts connectivity on a secondary network. This applies in a number of situations where those assets are modified/deleted/etc across a number of CNI plugins and is not limited to the bridge CNI. Having these situations be repaired without user intervention is the proper long-term behavior of our platform.

Motivation

Having these situations be repaired without user intervention is the proper long-term behavior of our platform. 

This RFE was raised per engineering request in BZ 2066351

Goals

Add Self-healing Functionality for CNI 2.0 spec B

Non-Goals

Changing current functionality defined by CNI 1.0

User Stories

Story 1

As a OpenShift administrator, I want CNI connectivity to be resilient to cases where an on-host asset that relates to a secondary network CNI plugin (e.g. a bridge or a master interface for macvlan, etc) is modified outside of the typical CNI ADD / CNI DEL lifecycle.