After reading some source code of charmed-openstack-tester and zaza- openstack-tests, I finally set up a debug env by setting keep- workspace=true, which prevents the tempest workspace from being deleted after running charmed-openstack-tester. This allows me to quickly debug a single failed test by running the following similar tempest command.
1, tempest run --workspace zaza --regex 'octavia_tempest_plugin.tests.scenario.v2.test_traffic_ops.TrafficOperationsScenarioTest' I got the following two kinds of logs #the log from ~/.tempest/zaza/tempest.log 2025-06-13 03:29:56.706 310372 INFO tempest.lib.common.ssh [-] Creating ssh connection to '10.149.142.113:22' as 'cirros' with public key authentication 2025-06-13 03:29:56.708 310372 INFO paramiko.transport [-] Connected (version 2.0, client dropbear_2020.81) 2025-06-13 03:29:56.808 310372 INFO paramiko.transport [-] Authentication (publickey) successful! 2025-06-13 03:29:56.809 310372 INFO tempest.lib.common.ssh [-] ssh connection to [email protected] successfully created 2025-06-13 03:29:56.816 310372 INFO octavia_tempest_plugin.tests.validators [-] Validate URL got exception: HTTPConnectionPool(host='10.149.142.113', port=80): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f961dec6860>: Failed to establish a new connection: [Errno 111] Connection refused')). Retrying ... 2025-06-13 03:44:54.182 310372 INFO octavia_tempest_plugin.tests.validators [-] Validate URL got exception: HTTPConnectionPool(host='10.149.142.113', port=80): Max retries exceeded wit h url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f961dec70a0>: Failed to establish a new connection: [Errno 111] Connection refused')). Retrying. 2025-06-13 03:44:59.188 310372 INFO tempest.test [-] <class 'tempest.lib.exceptions.TimeoutException'> raised in TrafficOperationsScenarioTest.setUpClass. Invoking tearDownClass. #the log from /var/log/octavia/octavia-worker.log ... |__Flow 'octavia-create-loadbalancer-flow': octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id 6246b204-53e3-4362-9351-1afdf99deb96 to go active timeout. 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker Traceback (most recent call last): 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker File "/usr/lib/python3/dist-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker result = task.execute(**arguments) 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker File "/usr/lib/python3/dist-packages/octavia/controller/worker/v2/tasks/compute_tasks.py", line 302, in execute 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker raise exceptions.ComputeWaitTimeoutException(id=compute_id) 2025-06-13 02:15:47.862 198168 ERROR octavia.controller.worker.v2.controller_worker octavia.common.exceptions.ComputeWaitTimeoutException: Waiting for compute id 6246b204-53e3-4362-9351-1afdf99deb96 to go active timeout. These logs show that TrafficOperationsScenarioTest is creating an octavia backend, but timed out while verifying the service on port 80. This is clearly unrelated to our metadata fix, as the backend VM is accessible via SSH as '[email protected]' with public key authentication, so this octavia_tempest_plugin test failure(octavia_tempest_plugin.tests.scenario.v2.test_traffic_ops.TrafficOperationsScenarioTest) is unrelated to metadata and metadata fix. 2, The remaining 3 heat_tempest_plugin tests are dynamically generated by gabbits, this is the output of running the following gabbits tests - https://paste.ubuntu.com/p/sknr3sgtBG/ tempest run --config-file etc/tempest.conf --regex heat_tempest_plugin.tests.api.test_heat_api > heat_tempest.log 2>&1 These 3 failed gabbits tests just creates a stack instance of type OS::Heat::TestResource for testing the heat api (https://github.com/openstack/heat-tempest- plugin/blob/master/heat_tempest_plugin/tests/api/gabbits/resources.yaml#L27), it doesn't create a real VM, so it does not involve metadata. 3, Besides, We have also tested before that running charmed-openstack- tester without this metadata fix result in these 4 failed tests as well. 4, And this morning, we received feedback from our customer, who comfirmed: We tested the new neutron version 2:20.5.0-0ubuntu2.1 on one of the compute hosts in a focal/yoga cluster and tested creation of several VMs. This is working as expected. Overall, I think this fix is fine. thank you. ** Tags removed: verification-needed-jammy verification-yoga-needed ** Tags added: verification-done-jammy verification-yoga-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2017748 Title: [SRU] OVN: ovnmeta namespaces missing during scalability test causing DHCP issues To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2017748/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
