Added in new blueprint for handling interruptions

[Ktmi]

This is intended to resolve kytos-ng/maintenance#59. This provides a blueprint for a mechanism to handle interruptions such as maintenance windows.

[viniarck]

Nicely done @Ktmi, great how this has evolved and emerged as interruptions.

Most of it looks good to me, asked minor implementation details clarifications though. Also, raised some questions that needs confirmation from network engineers to also confirm.

[viniarck]

Another adjacent thing to consider, once a service has its primary path interrupted but then it eventually ends the interruption, is it expected that the service should be using its primary path if it's available again or it's OK to continue in a backup or failover path?

Currently, mef_eline won't switchover to the primary once it's available. In a production deployment, that means that network engineers would have to redeploy the EVCs if they want to force trying to use the primary path again.

[viniarck]

Another adjacent thing to consider, once a service has its primary path interrupted but then it eventually ends the interruption, is it expected that the service should be using its primary path if it's available again or it's OK to continue in a backup or failover path?

Currently, mef_eline won't switchover to the primary once it's available. In a production deployment, that means that network engineers would have to redeploy the EVCs if they want to force trying to use the primary path again.

This thread is still unanswered.

[Ktmi]

Another adjacent thing to consider, once a service has its primary path interrupted but then it eventually ends the interruption, is it expected that the service should be using its primary path if it's available again or it's OK to continue in a backup or failover path?
Currently, mef_eline won't switchover to the primary once it's available. In a production deployment, that means that network engineers would have to redeploy the EVCs if they want to force trying to use the primary path again.

This thread is still unanswered.

I spoke with @italovalcy and the response is that for dynamic paths, when the original interruption that affected them ends, continue to use the recomputed path, unless the recomputed path was using flexible metrics and didn't satisfy all criteria. For static paths, we switch back to the original path.

[viniarck]

For static paths, we switch back to the original path.

Cool. Please, later on map this requirement as an issue on mef_eline that's only desired circuits with static paths, that way one day it can be prioritized accordingly.

[viniarck]

@Ktmi there's also a conflict with docs/blueprint/EP035.rst, can you bump this as EP037? I've also closed most of the threads that I opened, followed up with minor ones to confirm we're on the same page.

[viniarck]

@Ktmi, nicely done consolidating this blueprint, it's getting very close to land, I'm going to approve once these minor threads are closed/resolved:

• Added in new blueprint for handling interruptions #356 (comment)
• Added in new blueprint for handling interruptions #356 (comment)
• Finally, I got reminded of that initial requirement of potentially having the ability to redeploy a static circuit over a path that under maintenance (or provision a new static circuit), I'm not sure if @italovalcy will make use of this feature on 2023.1, but it's worth confirming if we'll need to augment mef_eline to start potentially differentiating when a path that is still operationally active but status_reason == {"maintenance"}.

Thanks, David.

[viniarck]

Nicely done consolidating this blueprint @Ktmi.

If anything else on mef_eline regarding provisioning paths during a maintenance is needed you can create a new issue, but since that won't impact much this blueprint, since the blueprint ended up very well agnostically solving the problem with interruptions, I'll go ahead and already leave it approved. If nobody has any extra comments or reviews we can merge this PR by Monday.

[italovalcy]

LGTM. I have a few questions/comments that I discussed with David/Vinicius on slack (specially the need for SERVICE_PROVIDERS setting versus using callback functions on top of existing events enhanced with a dry-run parameter). However, overall, the blueprint is good to go!

[viniarck]

Let's ship it then. Congrats @Ktmi, and thanks @italovalcy for you feedback.

If anything else minor is needed it'll be augmented in a next iteration.