Introduce action commands

This MR introduces actions which could be performend before and after experiments.

Closes #270 (closed)

marked this merge request as draft

There is one non-trivial point: how can we decide whether an action has been performed successfully or not? Do you have an idea? @she

mentioned in merge request !187 (merged)

changed milestone to %0.7.0

added 1 commit

• 66a0650a - Introduces a BechnmarkStateChecker which checks in each iteration of the...

Compare with previous version

added 12 commits

• 66a0650a...77f5e030 - 11 commits from branch she:master
• 9c02d956 - Merge branch 'master' of git.se.informatik.uni-kiel.de:she/theodolite into introduce-actionCommands

Compare with previous version

added 2 commits

• 812b6741 - fix test
• 8de1752e - Wait if required pod (for the actions) is not ready, small fixes

Compare with previous version

added 1 commit

• 37535e44 - reformat code

Compare with previous version

added 2 commits

• 95c8f7bb - 1 commit from branch she:master
• 0f24e4f7 - Merge branch 'master' of git.se.informatik.uni-kiel.de:she/theodolite into introduce-actionCommands

Compare with previous version

added To Do modul/theodolite labels

removed To Do label

added In Progress label

added 1 commit

• 276d9ebb - Use a string array instead of a single string to define the command of an action

Compare with previous version

added 41 commits

• 276d9ebb...7c2acb21 - 40 commits from branch she:master
• f643036f - Merge branch 'master' of git.se.informatik.uni-kiel.de:she/theodolite into introduce-actionCommands

Compare with previous version

added 1 commit

• bb388751 - Make it possible to set the timeout for an action in the benchmark manifests

Compare with previous version

added 2 commits

• cb3d1ba0 - Add basic test for actions and action commands
• 96c3e7d0 - Enhance logging

Compare with previous version

@she as you suggested in #270 (closed), we use labels to identify the pod on which a command should be executed. This makes sense in most cases. But it is possible that two different pods (or deployments) have the same labels (or some of the labels are the same). So it's possible that a matching pod is the right pod and has the right containers, and another pod with matching labels doesn't have the right containers. If we set the container field as optional, we will not be able to identify a pod by both the matching labels and the required container. So I would really prefer to set the container field as required. What do you think about this?