Description
In the current approach, VPP cannot be restarted from the same state (same problem as with FRR back in the days). We may want to invest time in third-party reload tools or change the approach to generate complete configs.
From Taras' and Viacheslav's testing, VPP crashes rarely occur during normal operation and usually happen on configuration changes. Thus the priority is to be able to revert it to the old state after a failed commit.
Taras Pudiak:
The goal of this task is to make VPP fault-tolerant. This means that, under any circumstances—whether due to system errors, low memory, or configuration scripts—if VPP is restarted, it should revert to a known working configuration.I see two main aspects to this task:
- Handling VPP Crashes or Forced Restarts
For example, if there isn't enough memory and VPP needs to be restarted just to restore functionality. This needs to be handled by systemd service. This logic should likely mirror what happens during a system boot: first, apply the data plane configuration, then trigger all dependencies to ensure the full configuration is reapplied properly.
- Handling Failed Commits Due to Errors
In this case, if a commit fails due to mistakes in the configuration during commit, VPP should not crash with no future actions. Instead, it should revert to the last known good configuration. The failed commit should be rejected gracefully, without causing destructive results.
I’m not entirely sure how this should behave in the case of partially failed commits. For example, let’s say the data plane configuration is successfully applied, VPP restarts, but some interface settings (e.g., in the set vpp interfaces section) are not applied correctly. What should happen then?