We observe issues recently in uni-jobs scenarios that involve Glance utilizing Cinder as a backend: uni05epsilon, uni06zeta and uni07eta.

The observed behavior for zeta and eta is the same: there is only the glance-*-db-purge pod present and no other glance pod running, the deployment fails on timeout (probably waiting for Glance pods?).

pod/glance-9b9da-db-purge-29027521-78nv9                            0/1     Completed   0                14m 

e.g.

• uni06zeta: https://sf.apps.int.gpc.ocp-hub.prod.psi.redhat.com/logs/a14/components-integration/a14f77b9c88f4794bc71c8a96f881b4a/logs/controller-0/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/all_resources.log (notice also the cinder-backup pod restarting, I am not sure if that's related/relevant here)
• uni07eta: https://sf.apps.int.gpc.ocp-hub.prod.psi.redhat.com/logs/f62/components-integration/f623be9919bb4bc180812ef6ed63b51d/logs/controller-0/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/all_resources.log

In case of epsilon the behavior is the same, although there is no timeout on deployment (some wait condition missing?), so the job proceeds to tempest and then it fails on missing image service endpoint: https://sf.apps.int.gpc.ocp-hub.prod.psi.redhat.com/logs/7f0/components-integration/7f0e1c5f1969416599883e38cfb124f9/logs/controller-0/ci-framework-data/logs/openstack-k8s-operators-openstack-must-gather/namespaces/openstack/pods/tempest-tests-tempest-workflow-step-00-run1-maintests-and-iscsi2nfs/logs/tempest-tests-tempest-tests-runner.log

2025-03-11 00:33:53.499 28 ERROR tempest   File "/usr/lib/python3.9/site-packages/config_tempest/services/base.py", line 80, in do_get
2025-03-11 00:33:53.499 28 ERROR tempest     raise ServiceError("Request on service '%s' with url '%s' failed"
2025-03-11 00:33:53.499 28 ERROR tempest config_tempest.services.base.ServiceError: Request on service 'image' with url 'https://glance-default-public-openstack.apps.ocp.openstack.lab' failed with code 503 

(so in the end it does not run any tests and the job finishes with spurious SUCCESS status, but that is some test-operator issue to be handled as separate OSPCIX-726)