Missing bindings for network spaces in metadata/readme

[Sandor Zeestraten]

# Issue
With the networking changes in Juju 2.1.x for containers (https://jujucharms.com/docs/2.1/charms-bundles#binding-endpoints-of-applications-within-a-bundle), it is now necessary to specify which network space the charm should be in.

When deploying openstack-dashboard charm in a LXD container, we ran into the issue where we had not defined it's bindings and therefore could not deploy (see logs) as it did not know which network space to deploy to.

Looking at the readme and metadata.yaml for the charm, there's no mention of which available bindings there are so that should probably be updated.

# Workaround
Adding the following to our bundle allows the LXD container to be deployed correctly on our admin network.

    bindings:
      "": admin

# Network spaces
$ juju spaces
Space Subnets
admin 10.42.2.0/23
os-data 172.16.100.0/23
os-internal 172.16.102.0/23
ceph-public 172.16.104.0/23
ceph-cluster 172.16.106.0/23

# Logs: machine-0.log
http://paste.openstack.org/show/601338/

[James Page (james-page)]

Any of the relations can be bound; so

  bindings:
    website: admin
    identity-service: os-internal

might make more sense here; I think Juju also now has the concept of a default network space for a model which might make sense here.