Existing behaviour in EFA 2.3.0
Configuration or Deconfiguration is never attempted on admin down switching devices.
Target Devices
Devices on which the configuration is intended to be pushed.
Complete Failure Topology
- Topology having atleast one single-homed device in admin down state or
atleast one dual-homed device pair with both the devices in admin down state
is a “complete failure topology”.
- Any Tenant CLI/REST of create or delete nature attempted on the target
devices having “complete failure topology” is rejected with an appropriate
error and result in a complete failure. EFA does not not have any
configuration recipe prepared for this REST API or CLI as the entire request
is rejected. For example, an EPG create attempted on a single-homed device
which is admin down state.
Complete Success Topology
- Topology having all the single-homed devices and all the dual-homed device
pair in admin up state is a “complete success topology”.
- Any Tenant CLI/REST of create/delete nature attempted on the target devices
having “complete success topology” will result in the configuration recipe
preparation for all the target devices and configuration will be attempted
on all the target devices as all the target devices are in “admin up”
state.
Partial Success Topology
- Topology which is not “complete failure topology” and having at least one
dual-homed device pair with one of the device in admin down state and the other
device in admin up state is a “partial success topology”.
- Any Tenant CLI/REST of create nature attempted on the target devices having
“partial success topology” will result in the configuration being attempted onto
the “admin up” devices and configuration not being attempted onto the “admin
down” devices. Even though configuration is not attempted for “admin down”
devices, the configuration will be treated as success for the “admin down”
devices.
Configuration recipe will be prepared and persisted in EFA for all
the devices and the configuration will be auto reconciled with the devices
when the “admin down” devices transition to “admin up”.
Hence when
the devices are “admin up” both EFA intended configuration and device
configuration will be in sync.
- Any Tenant CLI/REST of delete nature attempted on the target devices having
“partial success topology” will result in deconfiguration attempted on the
“admin up” devices and deconfiguration not attempted on the “admin down” devices
and the CLI/REST operation will fail with an appropriate error indicating that
the deconfiguration not being attempted on the “admin down” devices.
The
reason being EFA doesnt want to leave stale configurations on the devices.
If stale configurations are left on the devices, then bringing the devices
(having stale configurations) back into EFA will be erroneous considering
the full brownfield support is missing in EFA. User can retry the same
CLI/REST operation after the “admin down” devices transition to “admin up”
state so that the deconfiguration will be attempted on all the devices. User
can always use “force” option available in REST API to forcefully delete the
entities from EFA even in case of partial success topology.
- Drift between the EFA intended configuration and device config will be shown in
the “efa tenant debug device drift” CLI/REST output as well as in the
corresponding entity GET/SHOW output i.e. “efa tenant epg show”, “efa tenant po
show” etc. in the form of “app-state” and “dev-state”.
- EFA will block the tenant reconciliation API and rest of the tenant APIs will
support partial success behaviour.
