Endpoint issues

[Javier Castillo]

I don't know whether this bug should be linked with designate-api server or with python-designateclient.

After installing Designate (ocata/ubuntu), I have the endpoints well defined:

$ openstack endpoint list | grep dns
| 028f918d068743f0a5783b50409d8d61 | RegionOne | designate | dns | True | public | https://<public fqdn>:9001 |
| 4353ba02051e46dca2f66c4f79a341b7 | RegionOne | designate | dns | True | admin | http://192.168.12.254:9001 |
| 4ddd5fe96c73457db706682fd18d959e | RegionOne | designate | dns | True | internal | http://192.168.12.254:9001 |

but any client from internet, when tries to make a call to designate service, it tries to contact with internal endpoint, getting a timeout of course

REQ: curl -g -i -X GET http://192.168.12.254:9001/v2/zones? -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}0c47a347034804fcbd8b320e684965ceda2bdf2a" -H "User-Agent: python-designateclient-2.6.0"
Starting new HTTP connection (1): 192.168.12.254

[Javier Castillo (javcasalc)]

server version:

$ designate --version
designate 2.6.0

client-side versions:
- python-designateclient-2.7.0 (pip install python-designateclient)

[Tim Simmons (timsim)]

Could we see more context for how you're making the request? openrcs, commands used, etc.

[Javier Castillo (javcasalc)]

what do you need? I have tried with API v3 and v2 with same results.
Also, any openstack CLI command (openstack, nova, neutron, heat, murano, etc) works as expected.....so I think this is only related with designated CLI command.

[Dr. Jens Harbott (j-harbott)]

@Javier: please tell us what software is generation your failing request and how.

If I run simply "openstack zone list" in a default devstack environment, it will always use the public endpoint and fail with "public endpoint for dns service in RegionOne region not found" if I remove it, so not even a fallback to admin or internal happening.

[Javier Castillo (javcasalc)]

This is my openrc file:

export OS_AUTH_URL=https://<public fqdn>:5000/v3
export OS_PROJECT_ID=<PROJECT ID>
export OS_PROJECT_NAME="demo_prj"
export OS_USER_DOMAIN_NAME="Default"
export OS_USERNAME="demo"
export OS_REGION_NAME="RegionOne"
export OS_INTERFACE=public
export OS_IDENTITY_API_VERSION=3

Please notice the REPLY I get from server:

REQ: curl -g -i -X GET https://<public fqdn>:9001 -H "Accept: application/json" -H "User-Agent: osc-lib/1.7.0 keystoneauth1/3.0.0 python-requests/2.18.1 CPython/3.6.2"
Starting new HTTPS connection (1): <public fqdn>
https://<public fqdn>:9001 "GET / HTTP/1.1" 200 451

RESP: [200] Content-Type: application/json Content-Length: 451 Date: Fri, 01 Sep 2017 09:59:43 GMT
RESP BODY: {
  "versions": {
    "values": [
      {
        "id": "v1",
        "links": [
          {
            "href": "http://192.168.12.254:9001/v1",
            "rel": "self"
          }
        ],
        "status": "DEPRECATED"
      },
      {
        "id": "v2",
        "links": [
          {
            "href": "http://192.168.12.254:9001/v2",
            "rel": "self"
          }
        ],
        "status": "CURRENT"
      }
    ]
  }
}

[Dr. Jens Harbott (j-harbott)]

So it seems like you have set up your API incorrectly. https://review.openstack.org/498828 is a fix for similar issues in devstack, please check whether it can be applied to your setup, too.

[Javier Castillo (javcasalc)]

I've set

[oslo_middleware]
enable_proxy_headers_parsing = True

in designate.conf, but no changes :(

I think https://review.openstack.org/498828 makes reference to a bug with http and https parsing.

But my problem is different: a user makes a request via public endpoint, and then it's redirected to internal/admin endpoints.

[Dr. Jens Harbott (j-harbott)]

Your problem is the same: The answer from the unversioned public endpoint contains links to the wrong versioned endpoints.

What are you using as proxy between public endpoint and designate-api? If it is apache, you need to enable both mod_header and set 'RequestHeader set X-Forwarded-Proto "https"' for your virtual host in addition to setting the above option.

[Javier Castillo (javcasalc)]

Haproxy between client and designate-api.

listen designate_api_external
  bind <PUBLIC_IP>:9001 ssl crt /etc/haproxy/haproxy.pem
  http-request del-header X-Forwarded-Proto if { ssl_fc }
  server server1 server1:9001 check inter 2000 rise 2 fall 5
  server server2 server2:9001 check inter 2000 rise 2 fall 5
  server server3 server3:9001 check inter 2000 rise 2 fall 5

I haver set " http-request del-header X-Forwarded-Proto if { ssl_fc }" but it does not work. Any hint with haproxy?

[Dr. Jens Harbott (j-harbott)]

Don't know in detail about haproxy, but del-header sounds wrong, you would want to set the header and not remove it.

Also, please check the contents of the unversioned endpoints of your other services like nova and neutron. I'm pretty sure that your issue isn't specific to designate, it's just one of the few clients that is actively using version discovery.

[Javier Castillo (javcasalc)]

Without "http-request del-header X-Forwarded-Proto if { ssl_fc }" it fails too.

Believe me, all other services (nova, neutron, cinder, glance, heat, ceilometer, etc) work as expected, at least with regard to this endpoint URL issue.

There has to be something somewhere.

Where in the code is built the reply, from designate-api? Any hint on how to debug this? debug=True? any other useful parameter to debug?

[Javier Castillo (javcasalc)]

Got it.

I had

[service:api]
api_base_uri = http://192.168.12.254:9001

After setting "api_base_uri = https://<FQDN_PUBLIC_IP>:9001", now it works.