haproxy context doesn't consider bindings

[Gábor Mészáros]

Setup:
Using separate subnets for admin, public and private networks.
E.g. glance application with 3 unit HA deployment.

Current behavior:
Deploying charms in HA using haproxy use private-address as their only frontend and backend endpoints when os-{}-network is not provided via config options.

Expected behavior:
When using charm bindings, haproxy should also get endpoints from the networks specified there.

Where it fails:
[0]: https://github.com/juju/charm-helpers/blob/master/charmhelpers/contrib/openstack/context.py#L578

Workaround applied:
configuring os-{}-network on the desired subnet will render frontends and backends on the correct subnet, but also leaves the private-network configuration, which isn't always required.

[Tytus Kurek (tkurek)]

I have taken an initial look on that and the bug looks a bit complex. Either we would need to fully re-write the existing code or we would need a function which checks whether certain binding is used or not. Unfortunately, I cannot find such function in the charm helpers documentation:

https://pythonhosted.org/charmhelpers/

[James Page (james-page)]

charms.openstack is actually OK:

    def add_network_split_addresses(self):
        """Populate cluster_hosts with addresses of this unit and its
           peers on each address type

           @return None
        """
        for addr_type in ADDRESS_TYPES:
            cfg_opt = os_ip.ADDRESS_MAP[addr_type]['config']
            laddr = ch_ip.get_relation_ip(
                os_ip.ADDRESS_MAP[addr_type]['binding'],
                self.config.get(cfg_opt))
            if laddr:
                self.cluster_hosts[laddr] = \
                    self.local_network_split_addresses()[laddr]
                key = '{}-address'.format(
                    os_ip.ADDRESS_MAP[addr_type]['binding'])
                for _unit, _laddr in self.relation.ip_map(address_key=key):
                    if _laddr:
                        self.cluster_hosts[laddr]['backends'][_unit] = _laddr

Already using get_relation_ip

[David Ames (thedac)]

I have uploaded this change to the glance charm to the charm store:

cs:~thedac/glance-0

Can anyone please give this a test run in their environments. My testing looks good. I'd like independent confirmation.

[OpenStack Infra (hudson-openstack)]

Change abandoned by David Ames (<email address hidden>) on branch: master
Review: https://review.openstack.org/535499
Reason: Ch-syncs completed this.

[Tytus Kurek (tkurek)]

Why has "charms.openstack" been marked as invalid? The issue is present in designate charm for example. I will create a separate bug report.

[Tytus Kurek (tkurek)]

I created bug 1745389.

[Jason Hobbs (jason-hobbs)]

Can this be backported to stable?

[Gábor Mészáros (gabor.meszaros)]

I'm not sure that this fixes the issue. In these environments we have os-{}-network configuration options unset. Charmhelpers still queries these options directly, but as they are not preset, it will skip them and render only the private address.
The issue is still in this line: https://github.com/juju/charm-helpers/blob/117dfa32089f427fd1d71c3a29c8ca88a222e25e/charmhelpers/contrib/openstack/context.py#L637

[James Page (james-page)]

Jason - it has been - stable charmhelpers resyncs finished landing today.

[David Ames (thedac)]

A summary to close out this bug.

@Tytus As James has pointed out, Bug #1745389 is really a new bug and we will address it there.

@Gábor Line 645 [0] is where address selection actually takes place. It uses get_relation_ip [1] which takes os-*-network as an option. If it is None it is ignored, and network-get (the spaces aware tool) is used.

@jhobbs These changes are in stable/17.11 at this time.

[0] https://github.com/juju/charm-helpers/blob/117dfa32089f427fd1d71c3a29c8ca88a222e25e/charmhelpers/contrib/openstack/context.py#L645
[1] https://github.com/juju/charm-helpers/blob/117dfa32089f427fd1d71c3a29c8ca88a222e25e/charmhelpers/contrib/network/ip.py#L560

[Gábor Mészáros (gabor.meszaros)]

@thedac: yes I ran another few test rounds, it was a mistake on my end. The change fixes my issue.

[Tytus Kurek (tkurek)]

@David:

Righ, it's a new bug. I was thinking it had been resolved as a part of this bug. Sorry for the mess.