[Rdo-list] astapor: using nova_host for vncserver_host is problematic

[Florian Haas]

Hi everyone,

in https://github.com/redhat-openstack/astapor/blob/b11e159d/puppet/modules/quickstack/manifests/compute_common.pp#L204,
the nova_host global variable is used to set vncserver_host on the
::nova::compute class (which then uses it to construct the
novncproxy_base_url config option for nova.conf).

That's a bit problematic if your nova_host is an IP address on the
private management network, because that IP address will then show up
as the result of "nova get-vnc-console <host> novnc" and also pop up
in Horizon, but will typically not be reachable from the outside.

If instead you configure your nova_host for the compute nodes to the
*public* IP (or hostname) of your Nova API endpoint, then nova
get-vnc-console returns, and Horizon contains, a publicly available
URL.

However, because
https://github.com/redhat-openstack/astapor/blob/b11e159d/puppet/modules/quickstack/manifests/neutron/compute.pp#L108
also uses nova_host, then that means that in a Neutron-based
environment, python-neutronclient invoked by nova-compute will now
*also* try to contact Nova via the public IP, which may not be
reachable from inside the management network (and even if it is, that
detour would still seem ugly to me).

So my proposal would be to introduce a separate "vncserver_host"
parameter that defaults to nova_host, such that nova_host can be set
to the private IP and vncserver_host to the public hostname. Does that
make sense?

Cheers,
Florian