Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Note: This page is for discussion and aims to define the possible requirements for a simulator wrapper within  pythonsdk-tests

Andreas Geißler Michał Jagiełło Illia Halych Krzysztof Kuzmicki


When we launch E2E tests, we sometimes need to launch third party simulator (e.g. pnf-simulator).

It would be a cool feature if we could have a wrappers within the pythonsdk-test to be able to start/stop/configure/launch REST API as a prerequisite steps.

It obviously depends of the simulators...and their ability to be controled and offer a REST API for the test.

We may however imagine to define an API that will allow the pythonsdk-test to consume such simulators.

Any simulator

  • shall be hosted in dedicated repository (do one thing and do it well)
  • shall include a docker build chain and be runnable trough a docker run command
  • shall be available in the ONAP Nexus

Though the docker standard command, it shall be able to

  • start the simulator
  • start with specific configuration
  • stop the simulator

If the feature is available, a REST API shall be available to reconfigure/trigger workflow.

The wrapper step within the pythonsdk-tests shall

  • detect if the simulator is available or not (if not test shall fail immediately exception simulatorNotAvailable)
  • launch the simulator
  • get the simulator status
  • stop the simulator
  • exchange with the simulator if an API available

Open questions

use of submodule from pythonsdk to know the available simulators? customize configuration?


The "scalable steps" solution

INT-1812 - Getting issue details... STATUS INT-1829 - Getting issue details... STATUS

Author: Illia Halych

Problem: all simulators are different, no trivial solution for all.

Challenges:

  1. Include general functionalities, specific functionalities, abstractions.
  2. Make it flexible to extend the wrapper based on specific needs.
  3. Patch custom configurations.
  4. Cleanup when something fails.

Solution:

  1. Use a step-by-step execution that's already available in pythonsdk-testsand implement the simulator as a step-by-step process.
  2. The step-by-step process execution will allow to patch configurations to each independent step separately before they start.
  3. The step-by-step process execution will allow to "rollback" (cleanup) from the step where the problem occurred.
  4. The step-by-step process execution is capable of changing the order of steps and dropping certain steps. 
  5. The first (1) basic step has the lowest level of abstraction - most common functionalities for all.
  6. The zero (0) basic step would be a substitution for the first step (1) for complex models.
  7. 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.
 





  • No labels