Evaluate the feasibility of migrating all system tests from Bash to Python

added Code Quality Continuous Integration labels

added 1 deleted label

assigned to @afonso

added prioritylow label

assigned to @rbachman

assigned to @poliverc

As discussed in the last dev meeting, have will a sit-down to discuss what will be the steps of this work and how we will distribute it.

Some points:

• @poliverc has already been working on CTA tests with Gfal2 and python.
• @rbachman has already some experience in migrating CTA (operations) scripts from bash to python.
• We need to take this opportunity to also restructure how the system tests are organised and run by the CI.
  • There are several optimisations to be made

changed milestone to %CI update push

We need to be more careful during this migration: the stress tests performance is more important than readability: last stress test was 2.5x slower

So we need to make sure that performance wise this rewrite is working OK.

Another point: we need to be able to use these scripts outside of CI to benchmark our production infrastructure (with possibly different authentication method than the CI one).

This was a key point for the unreadable test scripts: run as is on production for benchmarks.

assigned to @idlarbi and unassigned @rbachman

unassigned @poliverc

For the organization of the system tests, this issue should take care of the directory layout: #908 (closed).

We need to differentiate between the two types of test scripts we have: the top-level scripts that execute kubectl commands to run scripts in the different pods, and the test scripts that actually run on the pods. The scripts that run on the pods, we probably don't want to port to Python: these scripts are crucial for performance, and portability is important here (as mentioned by Julien). On the other hand, we should be able to safely migrate the top-level scripts to Python without hurting performance. Portability is not as big of a concern here, as these scripts are simply executed from whatever machine has access to the Kubernetes cluster.

Whatever we decide, at the very least we should refactor these scripts to be more readable at some point (make them consistent with each other).

mentioned in issue #740 (closed)

added ci: tests label