You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context: I was verifying if mef_eline was fully handling the error in the following case when trying to deploy a path:
It succeeds removing the current flows with force True, flow_manager still responsive when handling the request.
But then keep a middle switch of the patch not connected to simulate a connection error, at this point mef_eline should undo/remove this path since it failed mid deployment iteration
Finally, it was expected that mef_eline would remove the path, but it didn't since it the first step current_path was set to empty. So, it left the EVC as active and didn't rollback
The potential problem when this case happens seems two-fold:
deploy_to_path on this line, should probably be using remove_path_flows(use_path), which was the path that failed mid deployment, plus maybe no harm still also calling remove_current_flows() for extra good measure
Once the prior step is fixed, then when removing flows here the request can fail again, let's say when flow_manager returns HTTP 500 during a server request overload, very rare and our NApps are behaving well but it can happen. In this case, it should also deactive the EVC and follow one of the approaches of error handling async/consistent recovery that's being documented on Tackling epic_mef_eline_flows_error_handling #515
How to reproduce
Use the a ring topology
Create an EVC with the following payload (save it as epl_static_payload.json):
Temporarily change [this line to self.remove_current_flows(force=False, sync=True)]https://github.com/kytos-ng/mef_eline/blob/master/models/evc.py#L885) on mef_eline. The force=False here is just to facilitate to simulate as if flow_manager would return error in its request, it'll return 424 if the switch isn't connected, but since an error HTTP 500 is handled similarly we can use this to our favor to simulate it easily.
Set switch s3 as disconnected sudo ovs-vsctl set-controller s3 tcp:127.0.0.1:6654
Restart kytosd, just so the temporary code change you made on the prior step gets loaded and will be ready to fail when flows gets pushed to switch s3
Request a EVC redeploy http PATCH http://0.0.0.0:8181/api/kytos/mef_eline/v2/evc/<evc_id>/redeploy
Notice that request will be retried, will fail, but it won't completly rollback and keep the EVC active
Context: I was verifying if
mef_eline
was fully handling the error in the following case when trying to deploy a path:flow_manager
still responsive when handling the request.mef_eline
should undo/remove this path since it failed mid deployment iterationmef_eline
would remove the path, but it didn't since it the first step current_path was set to empty. So, it left the EVC as active and didn't rollbackThe potential problem when this case happens seems two-fold:
remove_path_flows(use_path)
, which was the path that failed mid deployment, plus maybe no harm still also callingremove_current_flows()
for extra good measureflow_manager
returns HTTP 500 during a server request overload, very rare and our NApps are behaving well but it can happen. In this case, it should also deactive the EVC and follow one of the approaches of error handling async/consistent recovery that's being documented on Tackling epic_mef_eline_flows_error_handling #515How to reproduce
Use the a ring topology
Create an EVC with the following payload (save it as epl_static_payload.json):
Temporarily change [this line to self.remove_current_flows(force=False, sync=True)]https://github.com/kytos-ng/mef_eline/blob/master/models/evc.py#L885) on mef_eline. The
force=False
here is just to facilitate to simulate as if flow_manager would return error in its request, it'll return 424 if the switch isn't connected, but since an error HTTP 500 is handled similarly we can use this to our favor to simulate it easily.Set switch
s3
as disconnectedsudo ovs-vsctl set-controller s3 tcp:127.0.0.1:6654
Restart
kytosd
, just so the temporary code change you made on the prior step gets loaded and will be ready to fail when flows gets pushed to switchs3
Request a EVC redeploy
http PATCH http://0.0.0.0:8181/api/kytos/mef_eline/v2/evc/<evc_id>/redeploy
Notice that request will be retried, will fail, but it won't completly rollback and keep the EVC active
Here's the entire example:
Before deployment 6 flows:
After deployment 4 installed flows (sw3 flows still pending, consistency would fix it, but still at it is it left the current path)
Here's the EVC still active despite a failed deployment:
The text was updated successfully, but these errors were encountered: