Openstack-dashboard needs shared-db and internal network binding


#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 | https://paste.ubuntu.com/p/7ZhTttWnbg/

$ cat spaces-bundle.yaml | https://paste.ubuntu.com/p/pCx7xFyC8n/

$ juju status | https://paste.ubuntu.com/p/NGhQzK3hZD/

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:

https://docs.jujucharms.com/2.4/en/authors-charm-metadata

https://docs.jujucharms.com/2.4/en/charms-deploying-advanced

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


#9

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