Impact combination
Reminder:
Types of dependencies (DependencyRequirement):
1. Optional,
2. OptionalRecommended,
3. Runnable,
4. RunnableRecommended,
5. Running.
Types of impacts (StartDependencyImpact):
1. Unknown,
2. FullStop,
3. StopOptionalAndRunnable,
4. Minimal,
5. StartRecommended,
6. StartRecommendedAndStopOptionalAndRunnable,
7. FullStart,
8. IsTryOnly (flag),
9. TryFullStop,
10. TryStopOptionalAndRunnable,
11. TryStartRecommendedAndStopOptionalAndRunnable,
12. TryStartRecommended,
13. TryFullStart.
For more information on the relation between the impacts and the dependency requirements, check out the code and the comments there:
- Yodii.Model/LiveModel/StartDependencyImpact.cs,
- Yodii.Model/DependencyRequirement.cs,
- Yodii.Model/Configuration/FinalConfigurationItem.cs (Combine function).
What’s an impact?
An impact
is a property (much like the status) of an item (service/plugin). It determines
the effects the item will have on its dependencies upon starting.
How does it work?
When the configuration has been accepted and the engine is running, we enter the “Dynamic resolution” phase. The graph is considered valid.
Upon starting, each graph item can dynamically start, stop or “ignore” (Optional dependency?) specific items depending on their type of dependencies (there are a few).
The dependency requirement is actually a contract that provides an item with guarantees.
Example:
1. If P1 starts, then S1 must be running too. (DependencyRequirement.Running between P1 and S1)
2. If P2 starts, then S2 must be runnable. P2 has the guarantee it will be able to start S2 at any time. (DependencyRequirement.Runnable between P2 and S2)
The
dependency impact is another kind of contract, which uses the dependency
requirement contract and says which types of dependencies (and consequently,
directly and indirectly related items of the graph) are to be affected by the
starting of a specific item.
Example:
Our P1 plugin has a FullStart dependency impact. Upon starting, it will attempt to start all its dependencies (Running, Runnable, Optional and the recommended ones).
The tricky
part is that each of P1’s dependencies, upon starting, will need to apply their
own dependency impact with their own dependency requirement.
So depending on the configuration of the graph, the entire system (all graph items live status) might be affected by the starting of a single item.
Why impact combination can be useful?
Because it sounds cool.
The status and impact of a given item can evolve in the configuration and in the resolution. Impact combination is yet another conflict resolution initiative.
If one item is located in two separate layers, it has been decided by design that its 2 main properties (Status and Impact) will combine. (Code: FinalConfigurationItem.Combine)
The
combination happens only if the 2 versions of the item are “compatible”:
meaning, it will be possible according to our rules.
Example:
In the first layer, the plugin 1 has an impact “StartRecommended”.
In the second layer, the plugin 1 has an impact “StopOptionalAndRunnable”.
In this case for example, the combination is possible and the final determined impact of the plugin 1 is “StartRecommendedAndStopOptionalAndRunnable”.
We can satisfy (and guarantee) exactly what the user expressed in the configuration by “tweaking it” internally without the user’s knowledge (though, a warning would be welcomed I think.)
The code testing this feature (in the configuration only) is currently passing.
Yodii.Engine.Tests/ Tests/ConfigurationManagerTests.cs