Failed to connect to server(code:1006) - Console access issue

[Bilal Baqar]

I am getting a "Failed to connect to server(code:1006)" error when accessing the console of an instance. Refreshing the page fixes this.

I am deploying cs:trusty/nova-cloud-controller-63 along with cs:trusty/openstack-dashboard-16 for kilo. I have also tried deploying the latest revision of both charms but hitting the same issue.

Here is my config for both charms:

openstack-dashboard:
    vip: "192.168.100.57"
hacluster-dashboard:
    cluster_count: 3
    corosync_transport: unicast
    monitor_host: "192.168.100.1"

nova-cloud-controller:
    network-manager: "Neutron"
    console-access-protocol: "novnc"
    openstack-origin: "cloud:trusty-kilo"
    quantum-security-groups: "yes"
    region: "serverstack"
    vip: "192.168.100.58"
hacluster-nova-cc:
    cluster_count: 3
    monitor_host: "192.168.100.1"
    corosync_transport: unicast

Let me know if this is a config issue.

[Takashi Natsume (natsume-takashi)]

Add the following information.

* nova version (kilo?)
* log message (log files)
- nova-novncproxy
- nova-consoleauth
- nova-api

[Junaid Ali (junaidali)]

Hi Takashi,
Providing you the required information on Bilal's behalf.

* Nova version is Mitaka (We're hitting the same issue on Kilo as well, haven't tested this out on Liberty)
* log files attached

Versions:
* nova-novncproxy
      13.0.0
* nova-consoleauth
      13.0.0
* nova-api-os-compute
      13.0.0

[Sean Dague (sdague)]

This really looks like this is a configuration issue, the juju charms folks should weigh in first.

[Junaid Ali (junaidali)]

Hi Sean,
Thanks for the response. The configuration shared initially were of Kilo, below is the configuration we're using for Mitaka. We are not facing this issue on a single controller environment, its only hitting in HA environment.

Here is the nova.conf of one compute
http://paste.ubuntu.com/18295909/
Do you think, this might be due to config issue in nova configuration file?

openstack-dashboard:
     vip: "<DASHBOARD_VIP>"
     openstack-origin: "cloud:trusty-mitaka"
hacluster-dashboard:
     cluster_count: 3
     corosync_transport: unicast
     monitor_host: "<MONITOR_HOST_IP>"
nova-compute:
     enable-live-migration: "True"
     enable-resize: "True"
     openstack-origin: "cloud:trusty-mitaka"
     migration-auth-type: "ssh"
     manage-neutron-plugin-legacy-mode: False
nova-cloud-controller:
     network-manager: "Neutron"
     console-access-protocol: "novnc"
     openstack-origin: "cloud:trusty-mitaka"
     region: "serverstack"
     vip: "<NOVA_CC_VIP>"
hacluster-nova-cc:
     cluster_count: 3
     monitor_host: "<MONITOR_HOST_IP>"
     corosync_transport: unicast

[James Page (james-page)]

I agree with Sean - this is probably a charm problem; for console access in HA configurations, there are a few options for caching of access tokens for the nova-consoleauth process - you can either you the memcache charm with multiple nova-consoleauth processes running OR the charms can configure things so that only a single process runs across the clustered units.

[Junaid Ali (junaidali)]

The "single-nova-consoleauth" config option is "True" in my case, which allows only a single consoleauth service to be running. I will try out the memcache charm and will update if it solves the issue.

[Junaid Ali (junaidali)]

Thanks James, using memcached charm solved this issue. Thanks for helping me out.

[James Page (james-page)]

Marking all bug tasks as invalid, as switching to using memcache resolved this issue.