Comment 4 for bug 1858132

TRIAGE:

I still need to get a setup to fully reproduce this. I am going to get more members of my team to look at this.

As Alvaro has pointed out the bug is in layer-openstack (and possibly charms.openstack) and thus affects all reactive charms (at least).

Still need to verify how classic charms behave in this scenario.

First a challenge to what our goal state should look like:

I would argue that the state we want is one in which *all* back end servers are in the space that cluster is bound to. We are asserting the communication between peers (on the cluster relation) should use the space cluster is bound to. So regardless of the front end IP *all* back end servers should use their cluster relation IP.

It should look something like this:

backend gnocchi-api_admin_192.168.1.2
    balance leastconn
    server gnocchi-1 192.168.0.2:8031 check
    server gnocchi-2 192.168.0.3:8031 check
    server gnocchi-3 192.168.0.4:8031 check

backend gnocchi-api_admin_192.168.2.2
    balance leastconn
    server gnocchi-1 192.168.0.2:8031 check
    server gnocchi-2 192.168.0.3:8031 check
    server gnocchi-3 192.168.0.4:8031 check

backend gnocchi-api_admin_192.168.0.82
    balance leastconn
    server gnocchi-1 192.168.0.2:8031 check
    server gnocchi-2 192.168.0.3:8031 check
    server gnocchi-3 192.168.0.4:8031 check

Next steps:

Determine the (team agreed upon) goal state
Re-create in a testing env (possibly with juju 2.8.x and openstack provider spaces)
Confirm the behavior of classic charms in a similar scenario
Determine if this is a bug in charms.openstack or layer-openstack or something else.
Fix all the bugs