Allow set debug mode for Tempest

[rdiazcam]

This change allows to enable the debug mode for the Tempest test operator by setting cifmw_test_operator_tempest_debug: true in spec (false by default). It must only be set to true for debbuging purposes (e.g. when running the operator manually) because it keeps the pod (e.g .Running) sleeping infinity.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign viroel for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[github-actions]

Thanks for the PR! ❤️
I'm marking it as a draft, once your happy with it merging and the PR is passing CI, click the "Ready for review" button below.

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/b7b0bc76af8d4520af00e8b5bb93a6fa

✔️ openstack-k8s-operators-content-provider SUCCESS in 2h 12m 01s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 15m 27s
✔️ cifmw-crc-podified-edpm-baremetal SUCCESS in 1h 30m 44s
❌ cifmw-multinode-tempest FAILURE in 17m 30s
✔️ noop SUCCESS in 0s
✔️ cifmw-pod-ansible-test SUCCESS in 7m 09s
✔️ cifmw-pod-pre-commit SUCCESS in 7m 01s
✔️ build-push-container-cifmw-client SUCCESS in 22m 14s
✔️ cifmw-molecule-test_operator SUCCESS in 4m 11s

[lpiwowar]

recheck

Thanks, looks good to me 👍 . I see no reason why not to expose this parameter. The job failure does not seem to be related to the patch:

  Traceback (most recent call last):
      File "/home/zuul/ci-framework-data/venv/bin/repo-setup-get-hash", line 10, in <module>
        sys.exit(cli_entrypoint())
      File "/home/zuul/ci-framework-data/venv/lib64/python3.9/site-packages/repo_setup/get_hash/__main__.py", line 117, in cli_entrypoint
        main()
      File "/home/zuul/ci-framework-data/venv/lib64/python3.9/site-packages/repo_setup/get_hash/__main__.py", line 89, in main
        repo_setup_hash_info = HashInfo(
      File "/home/zuul/ci-framework-data/venv/lib64/python3.9/site-packages/repo_setup/get_hash/hash_info.py", line 153, in __init__
        raise HashInvalidDLRNResponse(error_str)
    repo_setup.get_hash.exceptions.HashInvalidDLRNResponse: Invalid response received from the delorean server. Queried URL: https://trunk.rdoproject.org/centos9-antelope/current-podified/delorean.repo.md5. Response code: -1. Response text: The read operation timed out. Failed to create HashInfo object.
  stderr_lines: <omitted>
  stdout: '2024-09-04 06:05:32,642 - repo-setup-get-hash - ERROR - Invalid response received from the delorean server. Queried URL: https://trunk.rdoproject.org/centos9-antelope/current-podified/delorean.repo.md5. Response code: -1. Response text: The read operation timed out. Failed to create HashInfo object.'
  stdout_lines: <omitted>

[rdiazcam]

recheck

[cjeanner]

Since this is a proper data structure, I'm wondering if we shouldn't:

• push a cifmw_test_operator_tempest_default_config in vars/main.yml
• update cifmw_test_operator_tempest_config to be mostly empty
• combine both dict before generating the configuration file

That way, we could get something really nice and provide a better interface. Avoiding that kind of PR.

Any thoughts?