The Ankaios server shall create a delete graph for inter-workload dependencies

[inf17101]

Description

The Ankaios server shall create a delete graph with DeleteConditions for inter-workload dependencies. The DeleteConditions shall be inserted into the DeletedWorkload struct that is sent to the Ankaios agent. If the user or control interface requests to delete a dependency the Ankaios agent shall use the DeleteConditions to determine when it is allowed to the delete the workload.

Goals

Having a DeleteGraph storing the DeleteDependencies. The Ankaios server shall send the correct dependencies for deletion of a workload.

Final result

The DeleteGraph is implemented and stores DeleteConditions for inter-workload dependencies. The handling of the delete conditions for the Update Strategy AT_LEAST_ONCE shall not be part of the DeleteGraph, but instead handled in the agent implementation directly.

Summary

The DeleteGraph contains only DeleteConditions for workloads having inter-workload dependencies with AddCondition::ADD_COND_RUNNING. The DeleteGraph stores the reversed condition for the dependency. If a workload A has a dependency to B with the condition ADD_COND_RUNNING, the DeleteGraph stores: B -> A (DeleteCondition::DelNorPendingNotRunning). Meaning, Ankaios is allowed to delete the dependency B if A is neither pending nor running.

Tasks

• [x] Extend the ServerState through a DeleteGraph (HashMap<String, HashMap<String, DeleteCondition>>)
• [x] Ankaios server can send the dependencies of a workload to be deleted; a list of required-by workload names is actually sufficient for the DeleteWorkload command
• [x] Add unit tests
• [x] Update requirements

[inf17101]

The HashMap<String, HashMap<String, DeleteCondition>> stores the DeleteCondition reversed to the AddCondition::ADD_COND_RUNNING for a dependency.

For example, it looks like the following:

A needs B with state AddCondition::ADD_COND_RUNNING

Then into the DeleteGraph is inserted: B --> A: DeleteCondition::DelNorRunningNotPending

Meaning, if dependency B is deleted then A shall neither running nor pending otherwise A may ran into an error state because it needs B running.

For AddCondition::ADD_COND_SUCCEEDED and AddCondition::ADD_COND_FAILED no delete conditions is needed and thus not inserted into the DeleteGraph.

[inf17101]

In the case the Update Strategy AT_LEAST_ONCE is used, the Agent implementation shall handle the condition when to delete the workload. No need to insert a delete condition into the delete graph. This can be handled directly in the agent implementation for Update Startegies in the future.

[inf17101]

The maintenance of the DeleteGraph (meaning deleting DeleteConditions from the the DeleteGraph) shall be handled in a separate PR and is listed as separate task inside #48. This is because of merge conflicts and size of the current PR for creating the DeleteGraph.

[inf17101]

Before finalizing the issue, I need first resolve #179 with the plantuml bug to have correct output uml sequence diagrams.

[inf17101]

The diagram was updated with the export of the VSCode extension generating the correct output.