bug: maintenance on a UNI interface will keep the EVC status as active

[viniarck]

• A maintenance window on a UNI interface will keep the EVC status as active. Anything related to links are behaving as expected since topology when handling interruptions start and end will generate kytos.topology/link_up|link_down events. But for interfaces without links NApps like mef_eline would need to subscribe to topology.interruption.(start|end) to handle the interface cases. A maintenance on a network resource sets the network entity as DOWN and status_reason maintenance, so it's logically down. This needs to be handled same as a UNI going down or up.

How to reproduce

• Create an EVC
• Schedule a maintenance window with the maintenance NApp on a UNI
• Wait for the MW to start
• Notice the EVC will still be active

2024-11-27 09:46:00,002 - INFO [apscheduler.executors.default] (ThreadPoolExecutor-1_0) Running job "MaintenanceStart (trigger: date[2024-11-27 09:46:00 UTC-03:00], next run at: 2024-11
-27 09:46:00 UTC-03:00)" (scheduled at 2024-11-27 09:46:00-03:00)
2024-11-27 09:46:00,006 - INFO [apscheduler.scheduler] (APScheduler) Removed job some_mw-start
2024-11-27 09:46:00,008 - INFO [kytos.napps.kytos/maintenance] (ThreadPoolExecutor-1_0) Scheduling "some_mw"
2024-11-27 09:46:00,009 - INFO [kytos.napps.kytos/maintenance] (ThreadPoolExecutor-1_0) Scheduled "some_mw" end at 2024-11-27 12:47:00+00:00
2024-11-27 09:46:00,009 - INFO [apscheduler.scheduler] (ThreadPoolExecutor-1_0) Added job "MaintenanceEnd" to job store "default"
2024-11-27 09:46:00,012 - INFO [kytos.napps.kytos/topology] (dynamic_single_0) Received interruption start of type 'maintenance' affecting switches frozenset(), interfaces frozenset({'0
0:00:00:00:00:00:00:01:1'}), links frozenset()
2024-11-27 09:46:00,009 - INFO [apscheduler.executors.default] (ThreadPoolExecutor-1_0) Job "MaintenanceStart (trigger: date[2024-11-27 09:46:00 UTC-03:00], next run at: 2024-11-27 09:4
6:00 UTC-03:00)" executed successfully


kytos $> evc_id = "1ad8f110f5d041"

kytos $> mef_eline.circuits[evc_id].is_active()
Out[7]: True

kytos $> intf.status
Out[8]: <EntityStatus.DOWN: 'DOWN'>

kytos $> intf.status_reason
Out[9]: {'maintenance'}

kytos $> mef_eline.circuits[evc_id].uni_a.interface.status
Out[10]: <EntityStatus.DOWN: 'DOWN'>

kytos $> 2024-11-27 09:46:50,833 - INFO [uvicorn.access] (MainThread) 127.0.0.1:50940 - "GET /api/kytos/mef_eline/v2/evc/?archived=false HTTP/1.1" 200
2024-11-27 09:47:00,000 - INFO [apscheduler.scheduler] (APScheduler) Removed job some_mw-end
2024-11-27 09:47:00,000 - INFO [apscheduler.executors.default] (ThreadPoolExecutor-1_0) Running job "MaintenanceEnd (trigger: date[2024-11-27 12:47:00 UTC], next run at: 2024-11-27 12:4
7:00 UTC)" (scheduled at 2024-11-27 12:47:00+00:00)
2024-11-27 09:47:00,004 - INFO [apscheduler.executors.default] (ThreadPoolExecutor-1_0) Job "MaintenanceEnd (trigger: date[2024-11-27 12:47:00 UTC], next run at: 2024-11-27 12:47:00 UTC
)" executed successfully

Impacts

The impact is that the logical interruption won't have any side effect and the interface will still be used, so pretty much the maintenance side effects won't apply, which in some cases won't matter much, but in other cases it can, for example:

If you have a MW not finished while an UNI is still going up, the EVC can be left in an inactive state, or it can also fail to compute a new path since it can result in a case where it doesn't find new path, then it would behave like losing the UNI going up event.

Right now I'm fixing other things I won't be able to map all the related cases, but this is a heads up not to use maintenance on UNI interfaces in the meantime until this is better explored and covered.