Fix bind host issue when kolla_external_address is different than kolla_internal address

Registered by Hui Kang

In current kolla ansible deployment, when kolla_external_address is set to be
different than kolla_internal_address, the service endpoint will be broken as
shown in the following example.

    export OS_PASSWORD=password
    export OS_AUTH_URL=

[root@kolla-upstream-03 tools]# openstack endpoint show glance
| Field | Value |
| adminurl | |
| enabled | True |
| id | 86a90f8548704b549f28d1cea7c5a10e |
| internalurl | |
| publicurl | |
| region | RegionOne |
| service_id | f2af7b31ea174d85a0e7a0ea37ea35c6 |
| service_name | glance |
| service_type | image |
[root@kolla-upstream-03 tools]# openstack image list
Unable to establish connection to

This is because the ansible generated glance-api.conf only binds to the the
interface with internal address, e.g.,

    bind_host =

After I change to "bind_host =", glance-api endpoint can be accessed.

So my colleague Marcio (launchpad ID: marcios) proposed a solution to this.

If kolla_external_address NOT EQUAL to kolla_external_address
    If enable_haproxy == "Yes"
         Add both private interface and public interface to the backend server
             for that service.
         set bind_host = in the service configuration file (e.g., glance-api.conf.j2)

This should be able to implemented in ansible.

Blueprint information

Not started
Hui Kang
Needs approval
Series goal:
Milestone target:

Related branches



This is not a mistake, but rather a design. We will not be binding to under any circumstances. But you as the deployer can update your configs to bind to if you wish. All services should be able to reach other services via the internal address. Where this is not the case services have ways to point to different catalog entries (check our cinder.conf template). To reiterate, the services should _not_ be binding to the external addresses under any circumstance (unless your external address is your internal address). --SamYaple

I totally agree with Sam. Binding to is totally sloppy. My suspicion is the problem i think you really have in your environment is you have two NIC interfaces on your glance node and one is internal and one is external. binding to works because it binds to all interfaces (the internal and the external one). That is the only logical explanation for why this approach would work for you. Binding as you pose could possibily be a security risk - I am not certain, but we are not doing it. --sdake


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.