Openstack-dashboard needs shared-db and internal network binding

juju
1

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 | Ubuntu Pastebin

$ cat spaces-bundle.yaml | Ubuntu Pastebin

$ juju status | Ubuntu Pastebin

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?

Thanks

2

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
variables:
<snip>
  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
<snip>
applications:
  openstack-dashboard:
    charm: cs:xenial/openstack-dashboard
    num_units: 3
    bindings:
      "": *public-space
      shared-db: *internal-space
    options:
      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
    to:
    - lxd:3 
    - lxd:5 
    - lxd:6 
<snip>
3

@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 https://api.jujucharms.com/charmstore/v5/openstack-dashboard/archive/metadata.yaml.

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

4

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):
https://github.com/openstack/charm-percona-cluster/blob/47cde88fd7e046dabb00f7f78eb1311efaddd329/README.md#network-space-support

Also, here is another bundle example which illustrates this usage (plucked from a totally-unrelated bug attachment):
https://launchpadlibrarian.net/390625150/bundle.yaml

5

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 https://github.com/openstack/charm-openstack-dashboard/blob/master/metadata.yaml#L10

6

To directly answer that:

https://github.com/openstack/charm-openstack-dashboard/blob/master/metadata.yaml#L34

7

@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?

8

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

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

1 Like
9

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

1 Like
10

Hey dear @beisner , your replies clear many points to me for openstack bundle deployment. but can you please explain this to me:
in the openstack bundle example there is one or two vip assigned to each service with hacluster as below:

ceilometer-vip:      &ceilometer-vip      "10.244.40.81 192.168.33.3"
dashboard-vip:       &dashboard-vip       "10.244.40.83"

first can you specify each subnet related to which network space? I mean 10.244.40.81 is from oam, admin, or public space. and same for 192.168.33.3.

for my case I deployed the same bundle but the dashboard default binding is to oam space which is the only space that have access to the internet for deploying (while in the example the default binding is to the public space) and I am not able to access the dashboard from any vip.
then I tried to bind public endpoint of dashboard to public-api space and here I were able to access but can’t do anything from the admin tab in the left menu of openstack dashboard.