Comment 6 for bug 1669468

Michelle Mandel figured it out, all credits to her, I'm only summarizing things here:

The compute node in the multinode tests has a wrong value for the config
option "vnc.vncserver_proxyclient_address". It uses 127.0.0.1, but it
should be the IP address of the controller node. This is also described
in the help of that config option [1]:

    > "Private, internal IP address or hostname of VNC console proxy.

    > The VNC proxy is an OpenStack component that enables compute service
    > users to access their instances through VNC clients.

    > This option sets the private address to which proxy clients, such as
    > ``nova-xvpvncproxy``, should connect to."

As the multinode test job uses a controller node (*with* compute services)
+ compute node, this also explains why this fails intermittently. The test
passes if the instance gets scheduled onto the controller (*with* compute)
and fails if the instance gets scheduler onto the compute node.

Steps to check that assumption:
* check the failure in "screen-n-novnc.txt"
* note down the instance_uuid of the failing connection attempt
* check the file "subnode-2/screen-n-cpu.txt", the instance_uuid
  should be there

I checked this with these multiple failing test runs.

Options:
1) skip multinode tests for this test case
2) enforce scheduling onto the controller (*with* compute services)
3) change the multi node test job config to setup the vnc options correctly

Personally, I tend to option 3), as this is a more realistic scenario.
It should also not be that big of a change. Should be these 3 options (max,
I haven't yet tested the minimum to change)
* NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
* VNCSERVER_LISTEN=$HOST_IP
* VNCSERVER_PROXYCLIENT_ADDRESS=$VNCSERVER_LISTEN

References:
[1] https://github.com/openstack/nova/blob/cd3b57d0c0cb867ef48a6e9721d9b3e28cb08e84/nova/conf/vnc.py#L70-L78