Not sure whether this is really the same issue still or if we should rather have a new bug for that, but the novnc config in tempest-multinode-full looks wrong to me.
So I'm assuming the job only passes when the test VM gets scheduled on the controller and fails when it gets scheduled on compute1. For fixing the issue, the above config should contain the local IPs as set in my_ip instead of 127.0.0.1.
Not sure whether this is really the same issue still or if we should rather have a new bug for that, but the novnc config in tempest- multinode- full looks wrong to me.
https:/ /logs.opendev. org/92/ 651492/ 7/check/ tempest- multinode- full/ac24db2/ controller/ logs/etc/ nova/nova- cpu_conf. txt.gz proxyclient_ address = 127.0.0.1 base_url = http:// 10.211. 2.5:6081/ console 10.211. 2.5:6080/ vnc_auto. html
my_ip = 10.211.2.5
[vnc]
server_
server_listen = 127.0.0.1
xvpvncproxy_
novncproxy_base_url = http://
https:/ /logs.opendev. org/92/ 651492/ 7/check/ tempest- multinode- full/ac24db2/ compute1/ logs/etc/ nova/nova- cpu_conf. txt.gz proxyclient_ address = 127.0.0.1 base_url = http:// 10.211. 2.5:6081/ console 10.211. 2.5:6080/ vnc_auto. html
my_ip = 10.211.2.46
[vnc]
server_
server_listen = 127.0.0.1
xvpvncproxy_
novncproxy_base_url = http://
The section that generates this config in devstack however says:
# Address on which instance vncservers will listen on compute hosts.
# For multi-host, this should be the management ip of the compute host.
https:/ /opendev. org/openstack/ devstack/ src/branch/ master/ lib/nova# L621
So I'm assuming the job only passes when the test VM gets scheduled on the controller and fails when it gets scheduled on compute1. For fixing the issue, the above config should contain the local IPs as set in my_ip instead of 127.0.0.1.