Bug 1125846 - When oVirt and Foreman are installed on the same host /api maps to oVirt
Summary: When oVirt and Foreman are installed on the same host /api maps to oVirt
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Yaniv Bronhaim
QA Contact:
URL:
Whiteboard: infra
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-01 08:53 UTC by Tareq Alayan
Modified: 2016-02-10 19:07 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Red Hat Enterprise Virtualization Manager and Foreman installed on the same host introduced a conflict in the API URL and prevented Foreman from being added as an External Provider. To workaround this issue, edit the /etc/httpd/conf.d/z-ovirt-engine-proxy.conf configuration file and remove 'api($|/)|' from <LocationMatch, but it may introduce untested and unknown issues in Red Hat Enterprise Virtualization due to backwards compatibility requirements around the API URL. Red Hat does not recommend you to install the Red Hat Enterprise Virtualization Manager and Foreman on the same host machine.
Clone Of:
Environment:
Last Closed: 2014-08-12 11:14:00 UTC
oVirt Team: Infra


Attachments (Terms of Use)
engine-log (19.44 KB, application/x-tar-gz)
2014-08-01 08:54 UTC, Tareq Alayan
no flags Details
production.log (1.47 KB, application/x-tar-gz)
2014-08-03 09:10 UTC, Tareq Alayan
no flags Details

Description Tareq Alayan 2014-08-01 08:53:33 UTC
Description of problem:
Cannot aff foreman as external provider

Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140722232058.git8e1babc.el6.noarch
foreman-1.6.0.32-1.el6sat.noarch

How reproducible:
always

Steps to Reproduce:
1. Try to add new host
2. check Use Foreman hosts provider


Actual results:
No list available --- 

Expected results:
list of discovered hosts 

Additional info:

Comment 1 Tareq Alayan 2014-08-01 08:54:48 UTC
Created attachment 923143 [details]
engine-log

Comment 2 Yaniv Bronhaim 2014-08-03 08:01:03 UTC
Hey,
lets start by understand the currently status. Engine log always reports "PROVIDER_FAILURE and code 5050" when there is an issue with the request. Foreman blocks "wrong" operations\request and sends reply with general meaning (this is something that should be considered from both sides - fyi https://bugzilla.redhat.com/show_bug.cgi?id=1113000).

To figure specific issue, first we need to understand the steps that led to it. when you added the external provider and clicked on the "Test" button did you see the green V ? if not, the problem starts with the communication to the provider (guess certificate issues because from the engine.log it seems that each request get the same response)

second, if it is green and you get error code 5050, please attach also /var/log/foreman/production.log or try look at it for more details for the problem (its quite clear from there most of the time).

So in that case (before mark it as urgent) we need to understand what happened exactly.. does the communication test pass?

Comment 3 Tareq Alayan 2014-08-03 09:09:49 UTC
No, obviousley there is no connection to foreman but still when i click OK I can see the foreman entry in the UI which in my opinion is a bug, OK button should be disabled if there is no connectivity to foremna.
No there is an error message when i click test:
Error while executing action ImportProviderCertificateChain: Internal Engine Error

No authentication URL found; please configure one using the 'engine-config' utility, then restart the engine servic

production log attached

Comment 4 Tareq Alayan 2014-08-03 09:10:39 UTC
Created attachment 923563 [details]
production.log

Comment 5 Yaniv Bronhaim 2014-08-03 09:22:51 UTC
The problem is with the setup and the certificate import. Lets use the guys that can assist in this area (as I suggested last week)
Not sure if its something specific or general, I still haven't encountered that with my foreman setup. Oved will take a look on that also

Comment 6 Oved Ourfali 2014-08-03 10:55:48 UTC
(In reply to Tareq Alayan from comment #3)
> No, obviousley there is no connection to foreman but still when i click OK I
> can see the foreman entry in the UI which in my opinion is a bug, OK button
> should be disabled if there is no connectivity to foremna.
> No there is an error message when i click test:
> Error while executing action ImportProviderCertificateChain: Internal Engine
> Error
> 
> No authentication URL found; please configure one using the 'engine-config'
> utility, then restart the engine servic
> 
> production log attached

Hi

It seems like the issue is having the engine and Foreman installed on the same machine... so /api directs to the ovirt-engine API, and that's why you fail.

So, we'll need to explore that, but it shouldn't block you from continuing your tests, as you can have two separate hosts for that.

As for adding the provider without the test connection passed, it is not a bug... someone can prepare a setup and add stuff even before they exist.... we shouldn't block on that... we just ease the deployment by allowing to test whether the url and credentials are good.... you can do that any time, even after adding the provider...

Comment 7 Oved Ourfali 2014-08-04 07:16:52 UTC
The certificate is imported successfully... so the title here is misleading.
The only issue here is the existence of Foreman and oVirt in the same machine.

Alon - do we always map http(s)://engine/api to the ovirt-engine API?
Or is it configurable?

Comment 8 Oved Ourfali 2014-08-04 07:17:54 UTC
The certificate is imported successfully... so the title here is misleading.
The only issue here is the existence of Foreman and oVirt in the same machine.

Alon - do we always map http(s)://engine/api to the ovirt-engine API?
Or is it configurable?

Comment 9 Alon Bar-Lev 2014-08-04 18:43:43 UTC
(In reply to Oved Ourfali from comment #7)
> The certificate is imported successfully... so the title here is misleading.
> The only issue here is the existence of Foreman and oVirt in the same
> machine.
> 
> Alon - do we always map http(s)://engine/api to the ovirt-engine API?
> Or is it configurable?

it is for the "backward compatibility" cause... it was a mistake to use it at first place, and it seems like foreman suffers from the same misbehavior of assuming it owns the server, just like other Red Hat products, this assumption is invalid.

since 3.4 we moved all uri namespace into /ovirt-engine/ but few uris that are required for older component interactions.

disabling is possible by editing /etc/httpd/conf.d/z-ovirt-engine-proxy.conf and removing 'api($|/)|' from <LocationMatch

another option is to put another configuration, such as /etc/httpd/conf.d/zz-XXXX with override back to foreman.

Comment 10 Oved Ourfali 2014-08-05 11:56:36 UTC
I think we should have a release note, specifying that having them on the same machine can be problematic, and it requires either the setting Alon wrote in Comment #9, or another setting in Satellite/Foreman, to give a prefix for the API.

Scott/Arthur - thoughts?

Comment 11 Scott Herold 2014-08-05 12:53:22 UTC
This is not a currently supported use case, but knowing there is interest in doing so, we'd like to highlight the workaround to get both RHEV-M and Foreman on the same host as a known issue.  Known Issue Doc Text proposed for Docs team

Comment 12 Oved Ourfali 2014-08-05 13:01:51 UTC
Tareq - just to make sure, other than the API issue, was there another issue you saw with working on rhev-m / satellite? Because it seems like the API issue is the only issue, but if there are more then we need to state that as well.

Comment 13 Tareq Alayan 2014-08-06 08:51:51 UTC
I had another issue when having both satellite and ovirt-engine on same machine. 
I had to add the following 2 lines on head of z-ovirt-engine-proxy.conf
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so


versions of httpd:
httpd-2.2.15-30.el6_5.x86_64
ovirt-engine-jboss-as-7.1.1-1.el6.x86_64

Comment 14 Oved Ourfali 2014-08-06 08:52:43 UTC
what was the issue?

Comment 15 Tareq Alayan 2014-08-06 10:15:25 UTC
the issue was when i tried to access http://hotname:/ovirt-engine i will be directed to foreman login page.

the z-ovirt-engine-proxy.conf starts with <IfModule proxy_ajp_module>
and this will evaluate to False, therefore i will reach foreman login page instead of hostname/ovirt-engine.

It evaluate False becuase this module (mod_proxy_ajp) wasn't loaded. Maybe becuase it is jboss upstream.

so adding:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

will cause the condition to be True and then to redirected to the ovirt-engine correct path.

and then it is possible to access http://hostname/ovirt-engine

Comment 16 Alon Bar-Lev 2014-08-06 11:14:20 UTC
these modules should be enabled by default, or ovirt-engine never had worked. unless something explicitly disables this.

Comment 17 Barak 2014-08-12 11:14:00 UTC
This bug should be CLOSED WONTFIX (with appropriate kb in case someone really insists on having them on the same host ... not recommended).
I find it hard to believe that any customer will choose to install it on the same host.

Per comment #11 moving to CLOSE WONTFIX doc text was added.


Note You need to log in before you can comment on or make changes to this bug.