...
- Include general functionalities, specific functionalities, abstractions.
- Make it flexible to extend the wrapper based on specific needs.
- Patch custom configurations.
- Cleanup when something fails.
SolutionConcept:
- Use a step-by-step execution that's already available in pythonsdk-testsand implement the simulator as a step-by-step process.
- The step-by-step process execution will allow to patch configurations to each independent step separately before they start.
- The step-by-step process execution will allow to "rollback" (cleanup) from the step where the problem occurred.
- The step-by-step process execution is capable of changing the order of steps and dropping certain steps.
- The first (1) basic step has the lowest level of abstraction - most common functionalities for all.
- The zero (0) basic step would be a substitution for the first step (1) for complex models.
- The third (3) basic step has the highest level of abstraction - least common functionalities for all.
Example of a single vs. a complex simulator execution models.
Solution:
- Simulators's images and other setup will be described in helm charts.
- Helm charts may be stored in a remote repository as well as a local folder. Remote is preferred to avoid duplicate code.
- For Pyhelm Tiller's HOST address on the target machine is required. Tiller may run as a background process which be addressed by localhost. Other ways are allowed too.
- Pyhelm supports Helm v2 and according to Guilin release versions it is sufficient. Though Pyhelm was tested on the machine with Helm v3 and that ran without problems.
- STEP LEVEL 2 takes HTTP/HTTPS request configurations during init.
