"api_base_uri" configuration parameter is not set properly when binding to multiple spaces

[Tytus Kurek]

When deploying the designate charm and binding it to multiple spaces as on example below, the "api_base_uri" parameter of "/etc/designate/designate.conf" file is set incorrectly causing which results in clients being unable to establish connection to the designate-api service.

The charm has been deployed with the following configuration:

  designate:
    charm: "./charms/designate"
    series: "trusty"
    num_units: 3
    constraints: "spaces=provisioning"
    bindings:
      admin: "openstack-admin"
      internal: "openstack-internal"
      public: "openstack-public"
      shared-db: "openstack-internal"
    options:
      debug: "true"
      openstack-origin: "cloud:trusty-mitaka"
      region: "RegionOne"
      use-syslog: "true"
      verbose: "true"
      vip: "10.24.111.14 10.24.112.14 10.24.113.14"
    to:
      - "lxd:controller/0"
      - "lxd:controller/1"
      - "lxd:controller/2"

This results in "api_base_uri" parameter being configured as follows:

api_base_uri = 'http://10.24.111.14 10.24.112.14 10.24.113.14:9001'

And the client is unable to establish the connection:

tytus@maas:~$ designate server-list
ERROR: Unable to establish connection to http://10.24.111.14 10.24.112.14 10.24.113.14:9001/v1/servers

When changing the value of the "api_base_uri" parameter to 'http://10.24.111.14:9001' the client can successfully establish the connection.

[Tytus Kurek (tkurek)]

Another workaround for that is to set "enable_host_header = True" parameter inside of the /etc/designate/designate.conf configuration file while commenting out the "api_base_uri" parameter at all. It looks like these two parameters are redundant - the "api_base_uri" is used only when the host header is not specified or is turned off.

[Alex Kavanagh (ajkavanagh)]

The bug is in charms_openstack/adapters.py line#726

charms.openstack reactive charms don't yet support multiple VIPs being configured in the 'vip' config option. This has (probably) been added to charmhelpers but it hasn't been added to charms.openstack.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/467287

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/467287
Committed: https://git.openstack.org/cgit/openstack/charm-designate/commit/?id=2e8eab733c1337ab7a15d892777036fbc86cf5e7
Submitter: Jenkins
Branch: master

commit 2e8eab733c1337ab7a15d892777036fbc86cf5e7
Author: Tytus Kurek <email address hidden>
Date: Tue May 23 17:28:55 2017 +0200

    Add support for enable_host_header parameter.

    Add config option and template setting.

    Change-Id: Ie8d7012036765488eee701423814b314416d2bf8
    Closes-Bug: 1692922
    Related-Bug: 1691452

[Dmitrii Shcherbakov (dmitriis)]

For this charm we need to use 'listen' directive which is supported starting with newton:

https://docs.openstack.org/releasenotes/designate/newton.html
"designate-mdns, designate-agent and designate-api can now bind to multiple host:port pairs via the new “listen” configuration arguments for each service."

Other options are singular and do not allow the mode of operation we need:

https://github.com/openstack/designate/blob/stable/ocata/designate/api/__init__.py#L30-L41

However, the current implementation for external_endpoints is broken in charms.openstack - it just takes the 'vip' field no matter how many vips are actually present there and puts them into .ip property as a string:
https://github.com/openstack/charms.openstack/blob/master/charms_openstack/adapters.py#L705-L736

This results in the following:

A string option
    cfg.StrOpt('api-base-uri', default='http://127.0.0.1:9001/'),

Gets filled with multiple vips:

        ip = getattr(self, 'vip', None) or self.local_address
...
                info[key]['url'] = '{proto}://{ip}:{port}'.format(**info[key])

----

Pretty much any reactive charm based on charms.openstack is affected by this.

[Alex Kavanagh (ajkavanagh)]

Just to be clear, the review https://review.openstack.org/467287 adds an option to work around the issue. The issue is still not resolved. I'm going to look at charms.openstack to see if I can resolve the issue.

[Alex Kavanagh (ajkavanagh)]

The review on charms.openstack (https://review.openstack.org/#/c/484808/) is the proposed fix to this. When that lands, the charm can be rebuilt and it should fix this bug.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/17.02
Review: https://review.openstack.org/488220

[Alex Kavanagh (ajkavanagh)]

As the related fix in charms.openstack is done, and the charm will be rebuilt for release, I'm marking this complete.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/488219
Committed: https://git.openstack.org/cgit/openstack/charm-designate/commit/?id=b67c676803bcede0ee193d9b1a9375cdecf079d1
Submitter: Jenkins
Branch: master

commit b67c676803bcede0ee193d9b1a9375cdecf079d1
Author: Dmitrii Shcherbakov <email address hidden>
Date: Fri Jul 28 01:23:00 2017 +0300

    rebuild the charm to include new charms.openstack

    fix in question:
    https://review.openstack.org/#/c/484808/

    Change-Id: Iaf064cc0fd101f37944ea2e69a8bd34f354e3142
    Related-Bug: #1691452

[OpenStack Infra (hudson-openstack)]

Change abandoned by James Page (<email address hidden>) on branch: stable/17.02
Review: https://review.openstack.org/488220
Reason: 17.08 release this week - dropping this review.