Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dry runs for network modifications #3001

Open
olperr1 opened this issue May 7, 2024 · 2 comments · May be fixed by #3002 or #3112
Open

Dry runs for network modifications #3001

olperr1 opened this issue May 7, 2024 · 2 comments · May be fixed by #3002 or #3112
Assignees

Comments

@olperr1
Copy link
Member

olperr1 commented May 7, 2024

Describe the current behavior

When applying network modifications to a network, there is no way to know if all of them can be successfully applied prior to applying them.

Describe the expected behavior

We want to add "dry run" capabilities to network modifications. They would allow to check that all the modifications could successfully be applied before their real application.

Describe the motivation

When applying several network modifications, if one of them fails, the network is left in an unknown state: the first modifications where applied but not the ones after the failing one. To return in a stable state, it is necessary to identify the applied modifications and to revert them, which could not be easily done.

Extra Information

Problem description

For simple network modifications, it is easy to check if they could be applied or not. For instance, an OpeningSwitch modification could be applied if the switch exists (regardless its previous state). Thus a list of network modifications containing only OpeningSwitch operations could be applied if every single modification could be applied on the network.

On the contrary, some modifications can have an impact on the next operations. For instance, if you have a modification removing a switch, it would be applicable if the switch exists… but if it is followed by another modification opening the switch, the application of the whole list of modifications will fail.

Principle

To cover both of these cases, it is proposed to create 2 "dry run" modes:

  1. a simple one, called the local dry run, which would just check the application of a single NetworkModification;
  2. a more costly one, called the full dry run, which will try to perform a whole list of modifications on a copy of the network and will return if this was successfully achieved.

Local dry run

To implement the local dry run, the NetworkModification.apply(Network, NamingStrategy, boolean, ComputationManager, ReportNode) method will take an additional parameter: boolean dryRun and will return a boolean:

  • When dryRun is false, the method's behavior should be the same as before (the return value should be always true if no exception is thrown);
  • When dryRun is true:
    • the method should only check the prerequisites of the network modification's application (no modification should be applied);
    • if at least a prerequisite is not respected, the method should not throw an exception but should return false;
    • if all the prerequisites are respected, the method should return true;
    • if the prerequisites cannot be checked, the method should throw a PowsyblException informing that "This network modification's application cannot be checked with a local dry run".

Full dry run

This type is the simplest to implement, but also the most costly. It consists of a single method in NetworkModificationList:
boolean fullDryRun(Network, NamingStrategy, ComputationManager, ReportNode)

This method should clone the network and call the NetworkModificationList's apply method with it. If no PowsyblException is catched, the dry run is a success and the method should return true. Else, It should return false.

Special case of NetworkModificationList's apply method

As each NetworkModification's apply method, the one of NetworkModificationList should have the additional boolean dryRun parameter and should return a boolean:

  • When dryRun is false, the method's behavior should be the same as before (the return value should be always true if no exception is thrown);
  • When dryRun is true, the method should run a local dry run on all of its modifications if it is pertinent, or else run the full dry run. In both case, it should return the result of the performed dry run.

How to know if a local dry run is pertinent?
Each NetworkModification should implement 2 new methods (better names can be used):

  • boolean hasImpactOnOtherModifications(): this method should return true if it may have impact on a NetworkModification which could be applied after. Typically, it should return true for topological network modifications.
  • boolean isLocalDryRunPossible(): this method should return true if all the prerequisites of the modification can be checked in the local dry run. Thus:
    • when it returns true, the local dry run should no throw any exception;
    • when it returns false, the local dry run should throw a PowsyblException.

The local dry run could be performed by the NetworkModificationList's apply method if:

  • isLocalDryRunPossible() returns true for every modification of the list;
  • and hasImpactOnOtherModifications() returns false for all the n-1 first modifications of the list, with n being the size of the list (since no modification will be applied after the last one, it doesn't matter if it has a potential impact).
@olperr1 olperr1 linked a pull request May 7, 2024 that will close this issue
7 tasks
@pjeanmarie
Copy link
Member

Can use of local dry run replace Rao canBeApplied?
yes

Rao canBeApplied was only doing separate equivalent of local dry runs for each of its elementary actions, without taking into account interaction between multiple elementary actions (but most network action have only one elementary action). So local dry run (as describe above) can be used in Rao on each elementary actions to reproduce canBeApplied behavior* (even without using NetworkModificationList) and using NetworkModificationList local dry run or a full dry run will be more precise than actual Rao.

NB. The exception in Rao is the network action SwitchPair elementary action which canBeApplied is not linked to the fact that the modification are applicable and so it will keep is own implementation of canBeApplied in Rao.

*To be exact: canBeApplied was verifying less thinks that the local dry run will, but it was not on purpose so using less permissive local dry run will be better.

@pjeanmarie
Copy link
Member

pjeanmarie commented May 31, 2024

Can use of dry run (local or full) can replace Rao hasImpactOnNetwork?
no

Local dry run as describe above do not answer this question but we could imagine a similar mechanism than the local dry run that will answer the question of hasImpactOnNetwork by checking if the elements of the network are already in the configuration expected post-modification. It will have the same limitation in case of multiple actions by not saying if one modification cancel a previous one for instance.

Full dry run will not give that information because it return only a boolean, but it computes that information, for instance, if we return the copy of the network on which we applied the modifications we could compare it to the original network to see if there is at least one difference, in that case hasImpactOnNetwork is true.

@olperr1 olperr1 linked a pull request Jul 31, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants