API usage questions

[langestefan]

Hi! I had a few questions about using the API.

How can I:

• Get a list of running tests by ID?
• Stop all running tests?

Currently the API becomes unresponsive after creating the first test case and calling {url}/testcases/{testcase}/select a second time.

The only way I can get it out of this state is deleting the containers.

[EttoreZ]

Hey @langestefan thank you for using BOPTEST. Are you using the local or cloud version?
The cloud version is currently very limited in the amount of test cases that can be deployed. In the local version you can deploy as many workers as you want, given you have the compute, with docker compose up web worker provision --scale worker=n, where n is the number of available test cases you can deploy, by default n=1 so you can deploy one test case.
To stop each test case you can use PUT stop/{testid}.

[langestefan]

Hi, I am running locally. I can indeed add more workers, but isn't that just a temporary solution? I would like to stop the running test without knowing the testid, so I can start a new one. That's a separate issue from the API hanging when calling {url}/testcases/{testcase}/select twice.

[EttoreZ]

As far as I know, @dhblum correct me if I am wrong. There is no API call to see current test cases and get their ID. Currently what I do is save the ID in a .json file and if the code crashes load the .json and stop the test case using the API call I mentioned before PUT stop/{testid}.

[langestefan]

Currently what I do is save the ID in a .json file and if the code crashes load the .json and stop the test case using the API call I mentioned before PUT stop/{testid}.

This makes it quite difficult to manage an existing container using the API. When I start a new python process, it doesn't know about the test ID and can't access the container contents.

So if I understand correctly there is also no possibility to switch an existing worker to a new test case?

[EttoreZ]

The main way to recover a currently running test case is by storing the generated ID as far as I know (timeout happens after 15min of inactivity). What in your use case would make it cumbersome to save the ID in external file?
The general workflow envisioned is:

• Deploy as many workers as needed
• Select a test case
• run co-simulation
• stop running container

When a worker container is deployed with a selected test case, it cannot be switched to a different a test case. The previous test case needs to be stopped, or if more than one worker is available you can call the {url}/testcases/{testcase}/select API again to deploy a different worker.

[langestefan]

Thanks for explaining!

What in your use case would make it cumbersome to save the ID in external file?

It's just more practical to use the API. It already has all of this information.

When a worker container is deployed with a selected test case, it cannot be switched to a different a test case.

That's fair. But then I would expect the API to return an error indicating that is the case.

[bertrandkerres]

There is an old issue #720 for a similar issue to that @langestefan refers, namely that the API also doesn't return any error code if no workers are available; instead it just hangs. I think it would be good to return a 503 Service Unavailable.

@EttoreZ One use case where the "store test-id in a file" workaround is difficult is if one runs the controllers also in docker containers. They will have their own filesystem and no access to write to a shared json file with test ids.