Received ConnectionResetError when issuing "openstack quota set"

[Jeffrey Chang]

In SQA run - https://solutions.qa.canonical.com/testruns/47c1637e-6574-4dd8-9559-915f1fcb37a0
We deployed openstack yoga/stable with cinder charm rev 667.
While running "openstack quota set --volumes 400 7102ef7951454ffda4af9b5aca6a9da0" cmd,
We see below error
Unable to establish connection to https://cinder.silo2.lab1.solutionsqa:8776/v3/7102ef7951454ffda4af9b5aca6a9da0/os-quota-sets/7102ef7951454ffda4af9b5aca6a9da0: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))

However, I could not find any error in cinder related log files.

Crashdump - https://oil-jenkins.canonical.com/artifacts/47c1637e-6574-4dd8-9559-915f1fcb37a0/generated/generated/openstack/juju-crashdump-openstack-2024-05-31-09.55.05.tar.gz

And same problem on 2nd run, https://solutions.qa.canonical.com/testruns/664f97d6-51c8-4d38-867a-89e9a41398be
All Artifacts - https://oil-jenkins.canonical.com/artifacts/664f97d6-51c8-4d38-867a-89e9a41398be/index.html

[Alex Kavanagh (ajkavanagh)]

I reviewed the juju_status.txt and cinder logs and indeed, there's nothing obvious there. As the command "openstack quota set ..." isn't retried, this could just be a transient outage of cinder.

Has anything changed in how the tests are run? Is it possible that the deployment is still settling prior to the commands being run (i.e. is it verified that the control plane is 'up') prior to running control plane commands?

It would be useful to know if some spaced retries would have succeeded where a single attempt failed.