Stanislav Zaborin

I think we are just lacking feature which would allow us to flexibly specify which interfaces haproxy should bind. It is assumed that haproxy should listen to at least assigned...

I do not select a specific microversion and, as I mentioned, the very same thing works on CAPO `v0.11.5`, but fails on `v0.12.2`. So maybe `v0.12.2` dropped support for some...

@mdbooth I will try to collect more information and will let you know

Collected verbose logs where we can see different request path/headers On v0.11.5 ``` I0403 05:16:31.430777 1 provider.go:251] "OpenStack Request URL: GET http://ip:port/v2/8b15e6751b4747b8ba0db5616392682f/os-availability-zone" controller="openstackcluster" controllerGroup="infrastructure.cluster.x-k8s.io" controllerKind="OpenStackCluster" OpenStackCluster="default/test" namespace="default" name="test" reconcileID="730bfd46-f99b-478a-90f9-84bf9fc7f387" cluster="test"...

It seems the error comes from this code https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/v0.12.2/pkg/clients/compute.go#L94 It was not present in v0.11.5, this is why we see this error only on v0.12.2 https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/v0.11.5/pkg/clients/compute.go#L65 Since on v0.11.5 cluster...

``` >>> conn.compute.get('').json() >>> conn.compute.get('/').json() ``` These both commands give the same 404 error, judging by debug logs, openstacksdk adds trailing slash in both cases ``` >>> conn.compute.get('').json() ... REQ:...

> And if you run the curl command manually without the trailing slash? I'd just like to nail down whether that's the issue. I get 401 error, not sure how...

I tried using `openstack token issue`, it helped, but unfortunately I get 404 both with and without trailing slash. ```bash $ curl -g -i -X GET http://ip:port/v2/8b15e6751b4747b8ba0db5616392682f/ -H "X-Auth-Token: ***"...