Description of problem: ======================= nova-novncproxy does not work. Deployed with packstack (answer file attached). It works for some topologies, yet it fails for a distributed topology that consists from: controller, networker, 2 computes. Version-Release number of selected component (if applicable): ============================================================= RHEL-OSP6: 2015-03-20.2 openstack-packstack-2014.2-0.18.dev1462.gbb05296.el7ost.noarch openstack-packstack-puppet-2014.2-0.18.dev1462.gbb05296.el7ost.noarch How reproducible: ================= 2/2 Steps to Reproduce: =================== 1. Deploy openstack using packstack with the attached answer file. 2. Boot an instance. 3. Try to open VNC console. Actual results: =============== VNC Console fails to open. snipped from nova-novncproxy: File "/usr/lib/python2.7/site-packages/websockify/websocket.py", line 711, in top_new_client self.new_client() File "/usr/lib/python2.7/site-packages/nova/console/websocketproxy.py", line 177, in new_client self.new_websocket_client() File "/usr/lib/python2.7/site-packages/nova/console/websocketproxy.py", line 108, in new_websocket_client raise exception.ValidationError(detail=detail) ValidationError: Origin header protocol does not match this host. Expected results: ================= Should work with no errors.
Created attachment 1005055 [details] packstack logs
Can you confirm that (a) you are accessing your dashboard via https and (b) the output of "nova get-vnc-console <instance_name_or_id> novnc" returns an http url? If you click on the "Click here to show only console" link, does that work?
(In reply to Lars Kellogg-Stedman from comment #7) > Can you confirm that (a) you are accessing your dashboard via https and (b) > the output of "nova get-vnc-console <instance_name_or_id> novnc" returns an > http url? > > If you click on the "Click here to show only console" link, does that work? I re-installed to verify the answers for your questions. a) Horizon works now (for some reason..) and I can access it via https. due i have to say it seems that the login stage is a bit slow.. b) the output of get-vnc-console is an https url.
I've had a chance to look at this environment, and there are at least two things going on here. The error described in this biz... ValidationError: Origin header protocol does not match this host. ...is caused because nova-novncproxy is comparing the protocol being used to access the proxy (https) against the url used in novavncproxy_base_url in /etc/nova/nova.conf. This is a problem, because in general that setting is only required on the compute nodes, and is left unset on the controller. The short term solution is to modify that setting on the controller to match the setting on the compute hosts: novncproxy_base_url=https://10.35.161.235:6080/vnc_auto.html Setting this resolves the 'protocol does not match' error. However, I am still unable to get the console to operate because novncproxy is throwing the following exception: 2015-03-26 15:36:38.726 25407 INFO nova.console.websocketproxy [-] Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/websockify/websocket.py", line 697, in top_new_client File "/usr/lib/python2.7/site-packages/websockify/websocket.py", line 629, in do_handshake # Continue on to handle WebSocket upgrade AttributeError: WSRequestHandler instance has no attribute 'last_code' The Internet suggests that this may be indicative of some sort of certificate problem, although it also appears to be a clear bug in nova-novncproxy, which is expecting this attribute to be available at all times when clearly it is not.
With websockify 0.6.0, the "WSRequestHandler instance has no attribute 'last_code'" exception is gone, but the browser connection is still closing for some reason...but I can't rule out my connectivity to the TLV lab, which seems to be pretty awful today. In any case, that's a separate issue; we've identified the cause behind this bz and should probably just update packstack to handle the nova configuration on the controller appropriately.
I opened https://bugs.launchpad.net/puppet-nova/+bug/1436969 against puppet-nova, since anything relying on those modules is going to experience the same problem.
If we solve this in packstack, we could do it like this: https://review.openstack.org/#/c/168099/ ichavero is working on a puppet-nova fix.
Can i have acks qe and pm acks for this bug? thanks!
New patches are here: puppet-nova: https://review.openstack.org/#/c/168545/ packstack: https://review.openstack.org/#/c/168547/
This bug also needs a new OPM packages: openstack-puppet-modules-2014.2.12-4.el7ost
FYI: The puppet-nova patch was rejected and needed to be re-worked. There are new patches available at: [puppet-nova] https://review.openstack.org/#/c/168545/ [packstack] https://review.openstack.org/#/c/169079/
created a package with a more accepted upstream patch.
verified novnc works using the attached answer file, on: # rpm -qa |grep openstack-packstack-2014 openstack-packstack-2014.2-0.20.dev1467.g70c9655.el7ost.noarch
verified: use the attached answerfile. nova get-vnc-console INSTANCE_NAME novnc open the output url in the browser and it worked
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0789.html