Unable to use console-ssl-cert with spice

spice-html5 should be switching to wss mode automatically based on the fact that the connection is a https secure connection - please can you confirm which release of openstack you see this issue with.

This was Queens on Xenial.

I reproduced this issue, the problem is specifically when first configuring SSL (or disabling SSL) for the console. In my case I was using VNC and not SPICE..

The problem is multi-part

(1) The horizon session appears to cache the access_url base (and thus whether it has SSL or not). You need to logout and then login to the horizon session, for the HTML URL to have the correct protocol.

Note that the websocket connection itself uses the same protocol and port as the novnc webpage, it's not explicitly configured.

(2) After changing the URL, once you logout/login, while the page/websocks work, I get an invalid token error. On my current deployment I can't get it to work again the tokens are always invalid and it's not clear to me why. This happened when going from SSL on the console only, to none. Further debugging required.

(3) Related bug #1800024 - when you configure SSL for the console (console-ssl-cert/key) and for the nova-cloud-controller itself (ssl_key/ssl_ca/ssl_cert) the same cert= and key= option is set in nova.conf in the same [DEFAULT] section. So enabling SSL for either, enables SSL for both. However only if console-ssl-{key,cert} is set, does the novncproxy_base_url also get set to include https. Hence if you set ssl_key/ssl_cert for nova but not the console, the proxy listens on SSL but the URL generated does not have SSL and it does not work. It's not clear where the cert= and key= entries come from in the case of ssl_key.. it's not directly in the template but seems to be set as a variable list of key,values in the charm somewhere - did not determine where.

As a side note, apparently for Cells V2 this access_url is cached in the database since the proxy runs per-cell and does not have access to the access_url. This cache may also need to be busted in such a case. Refer to https://review.openstack.org/#/c/334614/ - consoleauth is being removed in stein and the tokens are stored in the DB instead. In queens/rocky they are stored in both.

Looking at the original bug description closer, we can see that in fact the original web page (the SPICE client) was loaded as https, but the websocket was definitely insecure.

That is different to the multiple other related issues I ran into. In the novnc code base it inherits the domain/port/protocol from the page it was loaded on - it's never explicitly set. We should check the code for the spice client to see if it's doing the same or not. (in xenial-queens which the original environment was)

Side note: This is working fine for me on bionic-rocky

I wonder if https://bugs.launchpad.net/charm-nova-cloud-controller/+bug/1828458 is related. (Has a similar "invalid token" error, but it is on a newer release of Openstack.)