...
use of submodule from pythonsdk to know the available simulators? customize configuration?
The "scalable steps" solution
Concept:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Implementation:
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Author: Illia Halych
Problem: all simulators are different, no trivial solution for all.
Challenges:
- 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' images and other setup are described in helm charts. Charts should be stored in a remote repository and can be installed together with dependencies.
- Avionix officially supports Helm 3 only.
- STEP LEVEL 2 supports HTTP/HTTPS API calls.
