hotfix 2024.1.3: fixed extra removed flows that were being published on event "failover_old_path"

[viniarck]

Closes #504

I'm still analyzing other potential related one kytos-ng/telemetry_int#133 though

Summary

See updated changelog file

Local Tests

• Simulated/forced failover_old_path events, it no longer is sending extra removed flows

2024-09-03 11:30:31,266 - INFO [kytos.napps.kytos/flow_manager] (thread_pool_app_24) Send FlowMod from KytosEvent dpid: 00:00:00:00:00:00:00:01, command: delete, force: True, total_len
gth: 101,  flows[0, 101]: [{'cookie': 12285320825246548803, 'match': {'in_port': 2, 'dl_vlan': 1}, 'owner': 'mef_eline', 'cookie_mask': 18446744073709551615}, {'cookie': 12254970944063
612495, 'match': {'in_port': 2, 'dl_vlan': 3}, 'owner': 'mef_eline', 'cookie_mask': 18446744073709551615}, {'cookie': 12316423280674281796, 'match': {'in_port': 2, 'dl_vlan': 7}, 'owne

2024-09-03 11:30:31,325 - INFO [kytos.napps.kytos/flow_manager] (dynamic_single_0) Send FlowMod from KytosEvent dpid: 00:00:00:00:00:00:00:01, command: delete, force: True, total_lengt
h: 386,  flows[0, 200]: [{'cookie': 12141205637170692931, 'match': {'in_port': 2, 'dl_vlan': 1, 'dl_type': 2048, 'nw_proto': 6}, 'owner': 'telemetry_int', 'cookie_mask': 18446744073709
551615, 'priority': 21100, 'table_group': 'evpl', 'instructions': [{'instruction_type': 'apply_actions', 'actions': [{'action_type': 'add_int_metadata'}, {'action_type': 'output', 'por
t': 17}]}]}, {'cookie': 12141205637170692931, 'match': {'in_port': 2, 'dl_vlan': 1, 'dl_type': 2048, 'nw_proto': 17}, 'owner': 'telemetry_int', 'cookie_mask': 18446744073709551615, 'pr
iority': 21100, 'table_group': 'evpl', 'instructions': [{'instruction_type': 'apply_actions', 'actions': [{'action_type': 'add_int_metadata'}, {'action_type': 'output', 'port': 17}]}]}



2024-09-03 11:30:31,255 - INFO [kytos.napps.kytos/flow_manager] (thread_pool_app_27) Send FlowMod from KytosEvent dpid: 00:00:00:00:00:00:00:02, command: delete, force: True, total_len
gth: 202,  flows[0, 200]: [{'cookie': 12285320825246548803, 'match': {'in_port': 2, 'dl_vlan': 1}, 'owner': 'mef_eline', 'cookie_mask': 18446744073709551615}, {'cookie': 12285320825246
548803, 'match': {'in_port': 1, 'dl_vlan': 1}, 'owner': 'mef_eline', 'cookie_mask': 18446744073709551615}, {'cookie': 12254970944063612495, 'match': {'in_port': 2, 'dl_vlan': 3}, 'owne


2024-09-03 11:30:35,418 - INFO [kytos.napps.kytos/flow_manager] (dynamic_single_0) Send FlowMod from KytosEvent dpid: 00:00:00:00:00:00:00:02, command: delete, force: True, total_lengt
h: 404,  flows[0, 200]: [{'cookie': 12141205637170692931, 'match': {'in_port': 2, 'dl_vlan': 1, 'dl_type': 2048, 'nw_proto': 6}, 'owner': 'telemetry_int', 'cookie_mask': 18446744073709
551615, 'priority': 21100, 'table_group': 'evpl', 'instructions': [{'instruction_type': 'apply_actions', 'actions': [{'action_type': 'add_int_metadata'}]}]}, {'cookie': 121412056371706

End-to-End Tests

e2e exec with this branch:

+ python3 -m pytest tests/ --reruns 2 -r fEr
============================= test session starts ==============================
platform linux -- Python 3.11.2, pytest-8.1.1, pluggy-1.5.0
rootdir: /builds/amlight/kytos-end-to-end-tester/kytos-end-to-end-tests
plugins: rerunfailures-13.0, timeout-2.2.0, anyio-4.3.0
collected 267 items
tests/test_e2e_01_kytos_startup.py ..                                    [  0%]
tests/test_e2e_05_topology.py ..................                         [  7%]
tests/test_e2e_06_topology.py ....                                       [  8%]
tests/test_e2e_10_mef_eline.py ..........ss.....x.....x................  [ 23%]
tests/test_e2e_11_mef_eline.py ......                                    [ 26%]
tests/test_e2e_12_mef_eline.py .....Xx.                                  [ 29%]
tests/test_e2e_13_mef_eline.py ....Xs.s.....Xs.s.XXxX.xxxx..X........... [ 44%]
.                                                                        [ 44%]
tests/test_e2e_14_mef_eline.py x                                         [ 45%]
tests/test_e2e_15_mef_eline.py .....                                     [ 47%]
tests/test_e2e_16_mef_eline.py ..                                        [ 47%]
tests/test_e2e_20_flow_manager.py ......................                 [ 56%]
tests/test_e2e_21_flow_manager.py ...                                    [ 57%]
tests/test_e2e_22_flow_manager.py ...............                        [ 62%]
tests/test_e2e_23_flow_manager.py ..............                         [ 68%]
tests/test_e2e_30_of_lldp.py ....                                        [ 69%]
tests/test_e2e_31_of_lldp.py ...                                         [ 70%]
tests/test_e2e_32_of_lldp.py ...                                         [ 71%]
tests/test_e2e_40_sdntrace.py ................                           [ 77%]
tests/test_e2e_41_kytos_auth.py ........                                 [ 80%]
tests/test_e2e_42_sdntrace.py ..                                         [ 81%]
tests/test_e2e_50_maintenance.py ............................            [ 92%]
tests/test_e2e_60_of_multi_table.py .....                                [ 94%]
tests/test_e2e_70_kytos_stats.py ........                                [ 97%]
tests/test_e2e_80_pathfinder.py ss......                                 [100%]
=============================== warnings summary ===============================
= 243 passed, 8 skipped, 9 xfailed, 7 xpassed, 1295 warnings in 12445.82s (3:27:25) =

[Alopalao]

Looks good to me. How oftern kytos/flow_manager.flow.error is sent? Now that old_path is sent through event. This event notifying an error could not be related to failover flows or current path flows but when it is caught both failover_path and current_path are deleted.

[viniarck]

How oftern kytos/flow_manager.flow.error is sent?

flow_manager publishes this a result of either a 1) OFPT_ERROR (unsupported flow) or 2) a socket error, which can happen if force=True isn't set.

but when it is caught both failover_path and current_path are deleted.

Right, for 1), that's safe since it can't recover from an ofpt_error. But for 2) since all flows installation is using force=False, then it should respect the exc handling that you implemented with EVCPathNotInstalled which would detect which path failed. But if we were to have force=True for flows installation for either of the entire path then that handler wouldn't be able to different easily as you pointed out.

Let me know if you're seeing any other potential issue here @Alopalao.

[viniarck]

I also exercised a bit more the original issue, it no longer happens, tried 10+ times with 100+ EVCs.