.Workflow operations persist through interruptions in connectivity This update solves an issue in the Bare Metal Provisioning service (ironic) that caused the deployment process to loop and time out because of interruptions in connectivity while the deployment agent was starting. The issue occurred because only one attempt was made to evaluate if a RAM drive was recently booted. When this issue occurred, the bare metal nodes would fail to clean, deploy, or perform other workflow actions.

This issue is exceptionally difficult to reproduce. Ultimately the root cause is due to a short lived transient connectivity loss, the kind of connectivity loss which could be the result of LACP Fallback activating on a switchport, where after the host boots and network begins to come online, the network port will go offline for a short period of time. This short period of time can be enough to cause the overall step retrieval method in the ironic-conductor process to consider the connection timed out as opposed to returning valid data. The retry logic in the conductor would then retry, and the conductor's "is this a fresh/new agent" logic would disqualify the newly built agent so it would never retrieve it's list of steps available to execute upon to allow the overall deployment flow to activate. Some lab environments have apparently been able to reproduce this more reliably than others, specifically because the ramdisk in those environments is starting up about 30 seconds after network connectivity is first established, which enables the timing of the switch to attempt link validation causes the fallback logic logic to engage. This is where customers are attempting to use Bonded interfaces and then deploy over those bonded interfaces.