Comment 1 for bug 1762511

@hongbin, I was getting ready to open another bug for wss based on our discussion last week, but it looks like this is the same issue.

We are also using queens specifically version 1.0.1 with a multi-node setup using ubuntu 16.04.
  - controller: zun-api and zun-wsproxy
  - compute: zun-compute, kuryr-libnetwork and docker
  - zun-ui is on a separate node with horizon.

The above error in regards to trying to connect to a ws:/ socket while in a https:// session happens if they are setup for HTTPS but the conf file for zun has the base_url set to ws:// instead of wss://
and should produce this error "Error: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS". I believe this is and should be expected behavior. So the problem is when you set the base_url as wss:// to support a secure connection you still do not have access to the container for an interactive session with zun-ui or zun cli. The connection is refused at zun-wsproxy and never makes it to the compute node.

If everything is configured for https/wss you can interactively connect to any running container with "openstack appcontainer exec --interactive mycontainer /bin/sh", but can not connect through zun-ui.

If you try to spin up a container with an interactive session with "openstack appcontainer run -i --name mycontainer --net network=netuuid cirros /bin/sh" you get a connection refused just like you do in zun-ui. To my understanding zun-ui uses this same method to connect to the console session.

I bypassed zun-ui and the requirement for https to test ws:// and everything worked as expected. I can get any logs/configs you need, but a good chunk of it is in irc logs here: http://eavesdrop.openstack.org/irclogs/%23openstack-zun/%23openstack-zun.2018-11-08.log.html if needed for reference. The only thing that is not there is the successful one after switching back to ws://