The issue triggered by gabbi 2.5.0 was temporarily resolved by pinning it to 2.4.0 .
The gate is unblocked, I believe (We found an issue with a functional job
for stable/train which is being fixed now).
We can remove that pin once the issue with urllib3 is resolved.
> Should we consider using only https for endpoint access in the future?
Maybe ? But this is a separate topic, IMHO, and I don't have any strong
opinion about this.
There are several devstack plugins (like heat, aodh, ...) which don't support
setting up tls-proxy for https endpoints yet and we need to fix each plugin
if we take this direction.
Thank you Takashi for looking into this.
Should we consider using only https for endpoint access in the future?
I have opened an issue for urllib3[1], too, and created a PR to discuss a potential fix.
Because it'd take some time until we get feedback from these two communities,
I've proposed a change to pin gabbi to 2.4.0[2].
The issue might affect other projects using gabbi as well, unless https, instead of http,
is used for endpoint access.
I've looked into this but it seems the following error was actually caused by the latest release of gabbi(2.5.0).
TypeError: __init__() got an unexpected keyword argument 'server_hostname'
I've reported that issue to gabbi in [1] but if my observation is correct the problem should be
fixed in urllib3 which gabbi is dependent on.
Hello,
most of the tests of heat-tempest-plugin have started failing. We noticed that in interop [1], however, we reproduced that in the project's gates as well [2].
I suspect it might be an issue with the new gabbi package - there has been an update recently.
Could you please have a look.
Thank you,
--
Martin Kopec
Senior Software Quality Engineer
Red Hat EMEA
--