Bug 975670

Summary:	[Docs][Install] force Apache proxy on upgrade and clean install
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tim Hildred <thildred>
Component:	Documentation	Assignee:	Andrew Burden <aburden>
Status:	CLOSED NOTABUG	QA Contact:	ecs-bugs
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	aburden, acathrow, alonbl, alourie, gklein, sbonazzo, yeylon, zdover
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:	967353	Environment:
Last Closed:	2013-12-09 04:38:26 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:
Bug Depends On:	967353
Bug Blocks:

Description Tim Hildred 2013-06-19 05:49:26 UTC

I don't know if this will actually change the installation process, but it will be good to let users know what is actually going on with regard to port selection.

+++ This bug was initially created as a clone of Bug #967353 +++

cloned upstream ovirt bug to rhev

+++ This bug was initially created as a clone of Bug #905754 +++

Description of problem:

Any 3.2 should use apache and ports redirection on the default 80/443 ports.

--- Additional comment from Itamar Heim on 2013-01-30 03:54:09 EST ---

shouldn't this be "any 3.3"?

--- Additional comment from Sandro Bonazzola on 2013-04-29 11:26:41 EDT ---

(In reply to comment #0)

> Any 3.2 should use apache and ports redirection on the default 80/443 ports.

the above statement become:
Any 3.3 instance must use apache and should use ports redirection.
So, httpd proxy enabled (not an option) on scratch installation and forced migration to http proxy on upgrade.
Port redirection must be still configurable by the user during setup (80/443 by default)

engine-upgrade must keep the existing ports in non-interactive executions and prompt the user in interactive executions allowing to change them to 80/443.

--- Additional comment from Sandro Bonazzola on 2013-05-02 10:26:01 EDT ---

I'm looking in the code and I've found a point where I'm in doubt about how to handle the case.

The current engine-setup implementation perform some checks that change the behavior of the installer documented as:

1. Check whether the relevant httpd configuration files were changed,
   As it's an indication for the setup that the httpd application is being actively used,
   Therefore we may need to ask (dynamic change) the user whether to override this configuration.
2. Check if IPA is installed and drop port 80/443 support.

What the script really do is setting OVERRIDE_HTTPD_CONFIG default to False in both cases and just for case 2 call also setHttpPortsToNonProxyDefault.

How have I to handle those 2 cases which conflict with the forced proxy policy?

--- Additional comment from Sandro Bonazzola on 2013-05-20 09:54:58 EDT ---

We split the http configuration into three:
1. Install ajp proxy per our URIs[1][2].
2. Optionally set root redirection from / to /ovirt-engine
3. Optionally configure mod_ssl with our certificate.

The mandatory apache configuration[1] does not alter any configuration file.
[1] http://gerrit.ovirt.org/13318
[2] http://gerrit.ovirt.org/14304

So there is no reason for checking if user has changed the http
configuration for just forcing proxy.

About IPA conflicts if I've understood correctly there is only collision
between mod_nss used by IPA and mod_ssl used if we enable mod_ssl
configuration.
It seems there was an issue with mod_proxy and using 2 different SSL
certificates (IPA & RHEV) on the same apache server.

So, I can force proxy enabled and I can force SSL configuration disabled
if IPA is detected.
I can leave root redirection optional in any case.

otopi implementation already force proxy enabled so there should be just
to disable ssl if IPA is detected.

--- Additional comment from Sandro Bonazzola on 2013-05-24 09:59:02 EDT ---

patches pushed upstream for legacy engine-setup and engine-upgrade.

engine-upgrade verified only upgrading from nightly because it seems that engine-upgrade from master fails on fkvalidator_sp.sql when upgrading from 3.2.2 stable.

otopi implementation of engine-setup-2 doesn't need any change for the setup mode. It may need some changes in upgrading mode.

Comment 1 Tim Hildred 2013-08-05 05:47:57 UTC

Sandro:
I've looked at the PRD for this bug, and I have some questions.

- If I am upgrading from 3.2, and I previously I used ports 8080(http) and 8443(https), what happens during an interactive installation? 


- If I am upgrading from 3.2, and I previously used ports 5050(http) and 0666(https), what happens during an interactive installation?

- when we force proxy, we are recieving traffic on ports 80 and 443, and proxying them over to jboss on ports 8080 and 8443, right?


- why do we do that instead of just making jboss listen on 80 and 443? Is this purely from when IPA was going to be installed along-side RHEV?

- when we select non-standard ports as part of our 3.3 scratch installation, have we just selected non standard ports for apache to proxy from? jboss is listening on 8080 and 8443 anyways, right? 

- under what circumstances would jboss not be listening on 8080 and 8843?

Comment 2 Sandro Bonazzola 2013-08-05 11:56:08 UTC

(In reply to Tim Hildred from comment #1)
> Sandro:
> I've looked at the PRD for this bug, and I have some questions.
> 
> - If I am upgrading from 3.2, and I previously I used ports 8080(http) and
> 8443(https), what happens during an interactive installation? 

If apache proxy was disabled in 3.2, at the end of interactive installation the portal will be reachable on port 80 and 443 served by apache and 8080 and 8443 served by JBoss.
If apache proxy was already enabled, nothing should be changed in http ports configuration.



> - If I am upgrading from 3.2, and I previously used ports 5050(http) and
> 0666(https), what happens during an interactive installation?

If apache proxy was disabled in 3.2, at the end of interactive installation the portal will be reachable on port 80 and 443 served by apache and 5050 and 0666 served by JBoss.
If apache proxy was already enabled, nothing should be changed in http ports configuration.


> - when we force proxy, we are recieving traffic on ports 80 and 443, and
> proxying them over to jboss on ports 8080 and 8443, right?

No, if I've understood correctly it is used port 8702 as default for AJP connection between apache and jboss.


> - why do we do that instead of just making jboss listen on 80 and 443? Is
> this purely from when IPA was going to be installed along-side RHEV?

IPA installed along-side with RHEV is not a supported configuration.
There is a conflict at package level to ensure that both packages are not installed on the same host.


> - when we select non-standard ports as part of our 3.3 scratch installation,
> have we just selected non standard ports for apache to proxy from? jboss is
> listening on 8080 and 8443 anyways, right? 

during interactive installation is not allowed anymore to specify non standard ports for apache. The apache administrator should be able to change the needed parameters for changing the listening ports.


> 
> - under what circumstances would jboss not be listening on 8080 and 8843?

When engine-setup is upgrading from a 3.2 instance where jboss was not set to use those ports or if jboss default ports are changed using environment variables passed by command line or answer file.

Alon, Alex, please correct me if I'm wrong.

Comment 3 Alon Bar-Lev 2013-08-05 19:51:02 UTC

(In reply to Sandro Bonazzola from comment #2)
> > 
> > - under what circumstances would jboss not be listening on 8080 and 8843?
> 
> When engine-setup is upgrading from a 3.2 instance where jboss was not set
> to use those ports or if jboss default ports are changed using environment
> variables passed by command line or answer file.

Not sure I understand the question.... if ovirt-engine-3.2 was configured to use apache proxy then it did not used any port apart AJP, similar to what we are forcing in 3.3.

Comment 4 Zac Dover 2013-12-09 04:38:26 UTC

I don't see a location in the Installation Guide where this information would materially contribute to the book, so I'm closing this NOTABUG.