Please add support for network bindings

[Xav Paice]

In a situation where a compute host has multiple addresses, e.g. a management network and an openstack overlay network, we need to be able to control which network is used for the binding for the prometheus relation. In one particular case, the compute hosts supplied the address from the overlay network to Prometheus for the target address, which is unreachable from the prometheus host.

[Drew Freiberger (afreiberger)]

The http interface type used on the scrape interface takes an optional "hostname=" argument to scrape_service.configure.

If unspecified, this runs: hookenv.unit_get('private_address')

This should be run in the reactive module to set hostname of the interface to the scrape binding in "configure_scrape_relation":

    scrape_service.configure(
        PORT_NUMBER, hostname=hookenv.network_get_primary_address('scrape')
    )

[Xav Paice (xavpaice)]

Exporting the bundle where this charm is installed gives me the following bindings:

  prometheus-libvirt-exporter:
    charm: cs:prometheus-libvirt-exporter-1
    bindings:
      "": alpha
      dashboards: alpha
      juju-info: alpha
      nrpe-external-master: alpha
      scrape: alpha

I guess, therefore, that I can fix the bindings to the correct space to match the Prometheus server and try again. It may be, looking at this, that the surface binding is the right one anyway.

[Xav Paice (xavpaice)]

I just tried re-deploying the application with the binding set to oam-space for the default (where the Prometheus host lives). That went perfectly - I think this bug could easily be closed just with a small note in the documentation.