[Epic][Portability] Ensure test suite execution portability & parallelism

[fernandofloresg]

Is there an existing issue for this?

• [X] There are no existing issues.

Enabler description

Testing conducted using the AC tool will enable the execution of tests in parallel, significantly enhancing the efficiency of our testing process. The objective of this epic is to modify the various test suites to ensure that, when these tests are run in parallel—even on the same machine—there are no conflicts. This will involve meticulously identifying and addressing potential issues related to resource contention, data consistency, and test isolation. By achieving this, we aim to improve test execution times and reliability, ultimately fostering a more robust and scalable testing environment.

This initiative was previously attempted with the issue [Enabler] Remove hard coded vol user from test cases #625. Initially, the task did not encompass the removal of all hardcoded elements from the test suite; this requirement was added later. The process of modifying all test suites proved to be costly in terms of testing and PR reviews. However, a significant positive outcome was the development of a random data set name generator, which has since been integrated into many test suites. This generator has enhanced the flexibility and reliability of our testing framework.

We know from experience which things should not be hardcoded:

• Data set names.
• Volumes (We can have hardcoded names when we are creating it, but we can think of a random volume name generator too.)
• User names, currently OMVSADM.
• USS files (Stretch item: tests that use /tmp/ folder can be considered correct and should not affect portability.).

During the analysis, we identified several test cases containing hardcoded content that could potentially impact the execution of tests in parallel or on systems different from the current VMs used.

Test suites identified have concurrency issues:

• [x] [Enabler][Portability] [zos_apf] Ensure test suite portability by removing hard coded data.
• [x] [Enabler][Portability] [zos_backup] Ensure test suite portability by removing hard coded data.
• [x] [Enabler][Portability] [zos_blockinfile] Ensure test suite portability by removing hard coded data.
• [x] [Enabler][Portability] [zos_encode] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_fetch] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_find] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_job_submit] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_job_query] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_mvs_raw] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_volume_init] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_tso_command] Ensure test suite portability by removing hard coded data.
• [ ] [Enabler][Portability] [zos_copy] Ensure test suite portability by removing hard coded data.

Note: To ensure portability, if possible, we should have them run the concurrent executor (CE) at the end of their development. Unfortunately, its only possible to do this from a local environment.

Test suites without hardcoded content:

• zos_unarchive
• zos_script
• zos_ping
• zos_operator
• zos_operator_action_query
• zos_mount
• zos_lineinfile
• zos_job_output
• zos_data_set
• zos_archive

Ansible module

zos_apf, zos_backup_restore, zos_blockinfile, zos_copy, zos_encode, zos_fetch, zos_find, zos_gather_facts, zos_job_output, zos_job_query, zos_job_submit, zos_lineinfile, zos_mvs_raw, zos_operator, zos_operator_action_query, zos_tso_command, zos_volume_init