Openstack-dashboard needs shared-db and internal network binding


Openstack-dashboard fails deployment when shared-db network binding is used.

I have assigned a “shared-db” network to be disjoint from my mgmt interfaces (see bundle).

The openstack-dashboard cannot communicate with the database because not in the same address space.

$ juju debug-log |

$ cat spaces-bundle.yaml |

$ juju status |

I assume the openstack-dashboard will have similar problems communicating with keystone without a network binding for the internal endpoint.

Is it possible to get “sharded-db”, and “internal” network bindings for the openstack-dashboard?



Thank you for socializing this here. However, the best course to a resolution in an OpenStack Charm is generally through raising a bug. That will allow us to triage it and track its status and log attachments as it progresses, in alignment with the other OpenStack Charms.

Here is an extract from a known-good bundle which illustrates shared-db space usage on the openstack-dashboard charm. Please look this over and raise a bug if the issue persists. Thanks again!

series: bionic
  oam-space:           &oam-space           oam-space
  admin-space:         &admin-space         oam-space
  public-space:        &public-space        oam-space
  internal-space:      &internal-space      internal-space
  overlay-space:       &overlay-space       oam-space
    charm: cs:xenial/openstack-dashboard
    num_units: 3
      "": *public-space
      shared-db: *internal-space
      webroot: "/"
      secret: REDACTED
      vip: *dashboard-vip
      neutron-network-l3ha: True
      neutron-network-lb: True
      neutron-network-firewall: False
      cinder-backup: False
      password-retrieve: True
      endpoint-type: publicURL
    - lxd:3 
    - lxd:5 
    - lxd:6 


@beisner Thanks for that, I did want to discuss things here first.

From what I can tell openstack-dashboard doesn’t have endpoint bindings for “shared-db”, see

@beisner where are you getting “shared-db” from?


Loosely-speaking, each relation/interface can be bound to a space.

Please see the examples in the percona-cluster charm (the other end of this relation):

Also, here is another bundle example which illustrates this usage (plucked from a totally-unrelated bug attachment):


I must not be getting the point across very clearly … does anyone else see where I’m coming from?

@beisner can you please link me to where the “shared-db” endpoint is that you refer to? I’m not seeing it here


To directly answer that:


@beisner Thanks for that … is an interface, not a network endpoint binding…

If I’m picking up what you are laying down, you are telling me that we can bind regular relation endpoint interfaces to spaces as well as network-binding endpoints?

The “shared-db” endpoint that you have referenced is not actually a network-binding, it’s a “requires” interface endpoint that you are binding to the space (I think).

If this is the case, then what is the point of network-bindings?


If you mean “extra-bindings,” two doc links on the topic:

TL;DR extra-bindings can be used for non-relation bindings.


Oh how I feel silly for not knowing this. This is my missing link here. Thanks @beisner!