ERROR no network config found for binding "public" with enforce-ssl=true

[Nobuto Murata]

$ juju deploy openstack-dashboard
Located charm "cs:openstack-dashboard-247".
Deploying charm "cs:openstack-dashboard-247".

$ juju config openstack-dashboard \
    enforce-ssl=true \
    ssl_cert=$(echo dummy | base64) \
    ssl_key=$(echo dummy | base64)

ERROR no network config found for binding "public"
Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/config-changed", line 361, in <module>
    main()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/config-changed", line 354, in main
    hooks.execute(sys.argv)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/core/hookenv.py", line 731, in execute
    self._hooks[hook_name]()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/horizon_utils.py", line 493, in wrapped_f
    f(*args, **kwargs)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/hardening/harden.py", line 79, in _harden_inner2
    return f(*args, **kwargs)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/config-changed", line 160, in config_changed
    CONFIGS.write_all()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/openstack/templating.py", line 276, in write_all
    [self.write(k) for k in six.iterkeys(self.templates)]
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/openstack/templating.py", line 265, in write
    _out = self.render(config_file)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/openstack/templating.py", line 236, in render
    ctxt = self.templates[config_file].context()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/openstack/templating.py", line 103, in context
    _ctxt = context()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/horizon_contexts.py", line 220, in __call__
    ctxt['ssl_addr'] = resolve_address()
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/contrib/openstack/ip.py", line 177, in resolve_address
    resolved_address = network_get_primary_address(binding)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/core/hookenv.py", line 853, in inner_translate_exc2
    return f(*args, **kwargs)
  File "/var/lib/juju/agents/unit-openstack-dashboard-0/charm/hooks/charmhelpers/core/hookenv.py", line 1037, in network_get_primary_address
    return subprocess.check_output(cmd).decode('UTF-8').strip()
  File "/usr/lib/python2.7/subprocess.py", line 574, in check_output
    raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['network-get', '--primary-address', 'public']' returned non-zero exit status 1
hook "config-changed" failed: exit status 1

[Nobuto Murata (nobuto)]

FWIW, openstack-dashboard charm does not accept "public" binding.

$ juju deploy openstack-dashboard --bind public=space-foo
Located charm "cs:openstack-dashboard-247".
Deploying charm "cs:openstack-dashboard-247".
ERROR invalid binding(s) supplied "public", valid binding names are "cluster", "dashboard-plugin", "ha", "identity-service", "nrpe-external-master", "shared-db", "website"

[Nobuto Murata (nobuto)]

A workaround is manually add two lines below into metadata.yaml. But it's not handy since we have to folk the charm.
====
extra-bindings:
  public:
====

[Nobuto Murata (nobuto)]

Even if the deployment succeeds with extra-bindings, the fix for the following bug is needed to me:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1713198

[Nobuto Murata (nobuto)]

https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1713198/comments/2
====
Using mod_rewrite, we don't need to guess ssl_addr. Also, we never be able to guess ssl_addr reliably because dashboard accepts access from various sources, like internal network, public network at the same time. Redirecting to internal access to public URL may not be users want.

If we use mod_rewrite, we can replace {% if ssl_addr %} with something like {% if enforce_ssl %} so we can fix bug 1710930 at the same time.
====

[Nobuto Murata (nobuto)]

https://review.openstack.org/#/c/498168/

[OpenStack Infra (hudson-openstack)]

Change abandoned by Nobuto Murata (<email address hidden>) on branch: master
Review: https://review.openstack.org/498168

[James Page (james-page)]

Linked change switches behaviour of charm to not actually need network space binding for configuration of SSL redirects.

I like that; seems cleaner - thanks Nobuto!

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/498168
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=289d5bb66ba404244e567c31027c5ed6928b02d8
Submitter: Jenkins
Branch: master

commit 289d5bb66ba404244e567c31027c5ed6928b02d8
Author: Nobuto Murata <email address hidden>
Date: Sat Aug 26 18:10:22 2017 +0700

    Rely on HTTP_HOST sent by clients for redirection

    The dashboard may have multiple networks and IP addresses. We never be
    able to determine where to redirect reliably. Also, redirecting an
    access from internal network to a public IP address may not be what
    users want. Instead, use HTTP_HOST sent by the client and let the
    client's browser reveal SSL related errors if any.

    Change-Id: I9f4c734a61d3ab07f3f7c9a1a073eede73ae4651
    Closes-Bug: #1710930
    Closes-Bug: #1713198

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/17.08
Review: https://review.openstack.org/510349

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/510349
Committed: https://git.openstack.org/cgit/openstack/charm-openstack-dashboard/commit/?id=3ed7f0bba8990ee3977845a439c91972923e3fc7
Submitter: Zuul
Branch: stable/17.08

commit 3ed7f0bba8990ee3977845a439c91972923e3fc7
Author: Nobuto Murata <email address hidden>
Date: Sat Aug 26 18:10:22 2017 +0700

    Rely on HTTP_HOST sent by clients for redirection

    The dashboard may have multiple networks and IP addresses. We never be
    able to determine where to redirect reliably. Also, redirecting an
    access from internal network to a public IP address may not be what
    users want. Instead, use HTTP_HOST sent by the client and let the
    client's browser reveal SSL related errors if any.

    Change-Id: I9f4c734a61d3ab07f3f7c9a1a073eede73ae4651
    Closes-Bug: #1710930
    Closes-Bug: #1713198
    (cherry picked from commit 289d5bb66ba404244e567c31027c5ed6928b02d8)