Bug 1264386

Summary: HTML5 VNC console is not load balancer compatible
Product: Red Hat CloudForms Management Engine Reporter: Martin Welk <mwelk>
Component: UI - OPSAssignee: Martin Povolny <mpovolny>
Status: CLOSED WONTFIX QA Contact: Ramesh A <rananda>
Severity: low Docs Contact:
Priority: medium    
Version: unspecifiedCC: amedeo.salvati, hkataria, jhardy, mpovolny, mwelk, obarenbo
Target Milestone: GA   
Target Release: cfme-future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: html5
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-21 13:04:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
eww ag ITandTEL cloud infrastructure external user access via load balancer none

Description Martin Welk 2015-09-18 10:39:54 UTC 
Description of problem:
The current implementation isn't load balancer aware. When opening a HTML5 VNC console, it redirects to the host name of the CFME UI where the user is logged on, bypassing a load balancer. Furthermore, it uses a different port range for external connectivity (f. e. 5900-5999) for the incoming VNC console.

Version-Release number of selected component (if applicable):
5.4.x

How reproducible:

Steps to Reproduce:
1. Put a load balancer or reverse proxy in front of CFME which does SSL offloading or at least SSL session affinity 
2. login to CFME
3. open a console to a virtual machine

Actual results:
When analyzing the console page, it becomes visible that the connection goes to the external hostname and a port in the defined VNC port range.
The load balancer isn't aware of the VNC ports and cannot know on which UI the user is logged in. The connection may go to the wrong CFME instance, the console connection doesn't start.

Expected results:
The console part shouldn't create absolute URLs.
The connection should be redirected to the CFME UI where the user is logged on.
This could be achieved with SSL affinity on the load balancer or reverse proxy, and the VNC connection going the same way that all other requests go. That means,it should through port 80 or 443. 

Additional info:
If a CFME UI instance fails - goes down, is shutdown, whatever -, existing connections will be dropped, users will have to reconnect - that's acceptable.
Comment 1 Martin Welk 2015-09-18 10:46:17 UTC 
One more to add: CFME users (external customers for a cloud provider) will have to open our console port range (5900-5999) from their users desktops to the CFME UI. They won't like that. They want to be able to pass that traffic through an existing ruleset covering HTTPS, and probably a proxy or an application layer gateway.
Comment 4 Martin Welk 2015-10-15 14:28:40 UTC 
Created attachment 1083280 [details]
eww ag ITandTEL cloud infrastructure external user access via load balancer

This is an overview about the architecture that the customer would like to use for external CloudForms access. External users come in via 443/HTTPS only. The HTML5 console is also tunneled through 443U/HTTPS. There will be an SSL proxy and load balancer in front of two CFME UIs. Internal traffic between load balancer and CFME will be HTTP or HTTPS. HTTP will be fine as it is internal traffic, but it doesn't matter.
Comment 5 Martin Povolny 2016-05-09 10:30:24 UTC 
With the changes we did in 5.6, all the wss:// is proxied through :443.

I'd say that we can close this issue, but I have not tested this setup.

Martin, can you, please, test if 5.6 meets your requirements?
Comment 6 Martin Welk 2016-05-11 05:06:34 UTC 
(In reply to Martin Povolny from comment #5)

> With the changes we did in 5.6, all the wss:// is proxied through :443.
> 
> I'd say that we can close this issue, but I have not tested this setup.
> 
> Martin, can you, please, test if 5.6 meets your requirements?

This sounds like a good solution, but right now, I have no chance to test this: at the moment, I'm not on-site on the affected customer. My current customer has similar requirements, but of course, they are using CFME 5.5.3 at the moment.
Can we backport this to 5.5 for testing (probably temporarily)?
We have a test UI there where we could put it on.
Comment 7 Martin Povolny 2016-10-12 09:24:11 UTC 
I am afraid that it's not feasible to backport this to 5.5.3. The changes are quite complex and include a new worker.

Could you suggest some proxy software that we could you to verify/demo that this actually works now?

Thx!
Comment 8 Martin Welk 2016-10-12 14:12:02 UTC 
My customer is preparing the upgrade to 5.6 now. I will check with them if they can test the scenario.
Comment 9 Amedeo Salvati 2017-01-13 13:09:11 UTC 
We deployed both cfme 5.6 and cfme 5.7, and seems that this bug is still open, isnt't it?

thanks
Amedeo
Comment 10 Martin Welk 2017-01-14 20:09:38 UTC 
Well, since the HTML5 console connectivity runs now through the Apache HTTP Server on port 443 with the host name of the appliance, I think it should be load balancer aware now, if the load balancer supports "sticky" SSL sessions. This makes perfect sense as the console connection won't work in case of an automatic failover to another UI appliance anyway, it has to be re-established.
Unfortunately I have no chance to verify this in a customer environment at the moment.
Documentation for the HTML console details could be better.
I do not insist on keeping this BZ open :)
Comment 11 Amedeo Salvati 2017-01-16 09:28:57 UTC 
(In reply to Martin Welk from comment #10)
> Well, since the HTML5 console connectivity runs now through the Apache HTTP
> Server on port 443 with the host name of the appliance, I think it should be
> load balancer aware now, if the load balancer supports "sticky" SSL
> sessions. This makes perfect sense as the console connection won't work in
> case of an automatic failover to another UI appliance anyway, it has to be
> re-established.
> Unfortunately I have no chance to verify this in a customer environment at
> the moment.

in the next few days / weeks, we could verify in our environment :D

thanks!!
Amedeo

> Documentation for the HTML console details could be better.
> I do not insist on keeping this BZ open :)
Comment 12 Chris Pelland 2017-08-21 13:04:36 UTC 
This bug has been open for more than a year and is assigned to an older release of CloudForms. 

If you would like to keep this Bugzilla open and if the issue is still present in the latest version of the product, please file a new Bugzilla which will be added and assigned to the latest release of CloudForms.