The customer wanted to note that he's able to test anything that we'd like to attempt to get this working in the UI. Currently rather than not working as expected the feature is not working at all so some direction as to what could be the problem for not allowing configuration in the first place.

I'm not sure I fully understand. This is what I get from the description:
 - previously (before update?) 'spice-html5' radio button was greyed-out.
 - now it's enabled, but after selecting and clicking nothing happens (i.e. 'Console options' dialog doesn't disappear). Selecting other implementations 'Native' or 'Plugin' works fine.
Is that right?

Can I ask whether the WebSocketProxy option is configured in the engine? You can find out using engine-config like this:
$ engine-config -g WebSocketProxy

Also, it's quite probable this is a frontend issue. Logs would be really helpful.
In firefox, open javascript console (usually menu->web developer->web console), then try to reproduce the bug and watch the console for any errors/warnings. Pasting all error text (as private) here would be great.

Cheers!
Franta.

Hi! Here's the requested information:

 - previously (before update?) 'spice-html5' radio button was greyed-out.
 - now it's enabled, but after selecting and clicking nothing happens (i.e.
'Console options' dialog doesn't disappear). Selecting other implementations
'Native' or 'Plugin' works fine.
Is that right?

    </snip>

    Not quite.  The radio button was always 'active' ie; not insensitive.
    It used to popup a new window with a grey rectangle and a smaller
    grey rectangle at the bottom.

    Now what it does is that it allows me to select html5 as a console
    type but I cannot dismiss the Console Options dialog.  The Ok button
    appears to activate but does nothing.  I can only select another
    type of console - auto, native, or plugin or hit cancel.  The other
    spice options, map control-alt delete, enable usb auto share open in
    full screen and enable spice proxy are all able to be set, but have
    no effect.  In other words, selection of html5 console apparently
    overrides ability to select ok.

    <snip>

Can I ask whether the WebSocketProxy option is configured in the engine? You can
find out using engine-config like this:
$ engine-config -g WebSocketProxy
    </snip>

[root@bl280g6-tux16v1 ~]# engine-config -g WebSocketProxy
WebSocketProxy: 5000 version: general

    <snip>

Also, it's quite probable this is a frontend issue. Logs would be really
helpful.
In firefox, open javascript console (usually menu->web developer->web console),
then try to reproduce the bug and watch the console for any errors/warnings.
Pasting all error text (as private) here would be great.
    </snip>

If I turn on the Firefox console logging and set it to 'Log' I get the following
when I click on the OK button with HTML5 selected:

"Thu Jan 29 15:04:42 GMT-500 2015 com.google.gwt.logging.client.LogConfiguration
SEVERE: Exception caught: Config value must be in following form: host:port
com.google.gwt.event.shared.UmbrellaException: Exception caught: Config value
must be in following form: host:port
        at Unknown.Jp(Unknown Source)
        at Unknown.Qp(Unknown Source)
        at Unknown.KQ(Unknown Source)
        at Unknown.NQ(Unknown Source)
        at Unknown.YP(Unknown Source)
        at Unknown.ULd(Unknown Source)
        at Unknown.cMd(Unknown Source)
        at Unknown.LL(Unknown Source)
        at Unknown.WLd(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/PXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.Uu(Unknown Source)
        at Unknown.c3d(Unknown Source)
        at Unknown.psi(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/NXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.anonymous(Unknown Source)
Caused by: java.lang.IllegalArgumentException: Config value must be in
following form: host:port
        at Unknown.Ip(Unknown Source)
        at Unknown.Np(Unknown Source)
        at Unknown.Pp(Unknown Source)
        at Unknown.RCe(Unknown Source)
        at Unknown.t5h(Unknown Source)
        at Unknown.q4h(Unknown Source)
        at Unknown.c5h(Unknown Source)
        at Unknown.vek(Unknown Source)
        at Unknown.Hrm(Unknown Source)
        at Unknown.dci(Unknown Source)
        at Unknown.Rbi(Unknown Source)
        at Unknown.d$h(Unknown Source)
        at Unknown.KXh(Unknown Source)
        at Unknown.eM(Unknown Source)
        at Unknown.gQ(Unknown Source)
        at Unknown.YP(Unknown Source)
        at Unknown.ULd(Unknown Source)
        at Unknown.cMd(Unknown Source)
        at Unknown.LL(Unknown Source)
        at Unknown.WLd(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/PXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.Uu(Unknown Source)
        at Unknown.c3d(Unknown Source)
        at Unknown.psi(Unknown Source)
        at Unknown.x3d(Unknown Source)
        at Unknown.pMd(Unknown Source)
        at Unknown.qWd(Unknown Source)
        at Unknown.VXd/NXd<(Unknown Source)
        at Unknown.lr(Unknown Source)
        at Unknown.or(Unknown Source)
        at Unknown.nr/<(Unknown Source)
        at Unknown.anonymous(Unknown Source)"
730FB6A1EE8850B9282ACA97E522C456.cache.html:17783

Thanks for a fast and detailed response!

It looks like the WebSocketProxy option is malformed. The option has 3 possible forms:
1, Off - websocket proxy is turned off (neither spice-html5 nor noVNC are enabled)
2, Engine:<port> (e.g. Engine:5000), websocket proxy is configured on the same machine as the engine (this is common when websocket proxy infrastructure is configured by engine-setup)
3, Host:<port> (e.g. Host:6100) denotes multiple instances of websocket proxy deployed on every host (non trivial setup, better load-balancing),
4, <fqdn>:<port> (e.g. myengine.com:6100) - websocket proxy runs on given fqdn, in this example myengine.com.

So, in the customer case something is wrong - the option only contains value '5000' and must be reconfigured based on their setup to match one of beforementioned cases using engine-config.

(if the proxy runs on engine, then it should be simple as this:

$ engine-config -s WebSocketProxy=Engine:5000

, although I'm little affraid that customer doesn't typical deployment done by engine-setup)

I hope this helps.
Cheers,
Franta.

Franta,

I also appreciate the really quick turnaround from engineering! Here's what I've been able to find out:

	Is the websocket proxy supposed to point to an
	*existing* proxy, like squid, in the way that SpiceServerProxy
	is setup?   Or is it supposed to be independent?

	For Spice server to work,  the customer has squid setup on port
	2301.  This works.

	He tried setting the websocket proxy to use this same
	port and got an error when trying to start the service:


Starting oVirt Engine websockets proxy:                    [  OK  ]
[root@bl280g6-tux16v1 ~]# WebSocket server settings:
  - Listen on *:2301
  - Flash security policy server
  - SSL/TLS support
  - Recording to '/tmp/websocket-trace.*'
ovirt-websocket-proxy[2317] ERROR run:532 Error: [Errno 98] Address already in use

	This makes us wonder if the websocket proxy is something
	completely different than what Spice server is and it needs
	completely different management and can't share the same
	proxy as SpiceServer.

	Is this a correct understanding?

Regards,
Robert McSwain

Hi Robert,

correct - Spice proxy and Websocket proxy are two different things. And they actually don't work together.

1, The purpose of SPICE proxy is to redirect SPICE traffic through the proxy. It applies for 'Native' and 'Plugin' client (SPICE only).

2, Websocket proxy is needed for SPICE-HTML5 and noVNC clients. These clients use web sockets for talking with spice/vnc server. Since our spice/vnc server don't support web sockets directly, we use websocket proxy to do the conversion.

Anyway: If customer has already spice proxy (e.g. squid), they should configure SPICE proxy on cluster (Cluster->Edit->Console->Override spice->fill in address/fqdn:port of their proxy [like 10.20.30.40:2301]). After this, they should select spice 'Native' or 'Plugin' option in 'Console option' for a VM and check spice proxy checkbox in the very same dialog. Then the spice traffic should flow through the proxy.

(I believe the documentation on this topic needs improvements...)

I created a patch that should prevent such incorrect configuration.

Verified on rhevm 3.6.0-15

Checked the added WebSocketProxy config value validation is working as expected.
This validation prevents the situation in this bug, by blocking defining WebSocketProxy: 5000 version: general   : 

[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=5000
Cannot set value 5000 to key WebSocketProxy. Correct values are: Off (proxy is not deployed), Engine:<port> (Engine is reserved keyword meaning proxy is deployed on the same machine as the engine (on given port)), Host:<port> (Host is reserved keyword meaning proxy is deployed on each host on given port (if the deployment has more hosts, proxy must be deployed on each of them)), <hostname>:<port> (proxy is deployed on a machine identified by given hostname or ip and port).

Here are some more trials to test the validation:
1.
[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=
Cannot set value  to key WebSocketProxy. The WebSocketProxy can't be empty.
2.
[root@istein-rhevm36 ~]# engine-config -s WebSocketProxy=Engine:
Cannot set value Engine: to key WebSocketProxy. Correct values are: Off (proxy is not deployed), Engine:<port> (Engine is reserved keyword meaning proxy is deployed on the same machine as the engine (on given port)), Host:<port> (Host is reserved keyword meaning proxy is deployed on each host on given port (if the deployment has more hosts, proxy must be deployed on each of them)), <hostname>:<port> (proxy is deployed on a machine identified by given hostname or ip and port).

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/RHEA-2016-0376.html