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:
Created attachment 923143 [details] engine-log
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?
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
Created attachment 923563 [details] production.log
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
(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...
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?
(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.
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?
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
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.
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
what was the issue?
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
these modules should be enabled by default, or ovirt-engine never had worked. unless something explicitly disables this.
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.