Bug 1132394

*** This bug has been marked as a duplicate of bug 1123751 ***

Seems like a duplicate of bug #1123751 . Not sure how you verified that one and failed here.

You seem to have not run 'rhevm-reports-setup' after upgrading to 3.3.

Did you verify there separately the case of upgrading dwh and not reports (to 3.3)?

Part of the solution there was, in order to recognize if we have 3.2 or 3.3 setup, to check for the existence of /usr/share/jasperreports-server-pro/buildomatic/build_conf/default/dev , which at least on my system existed after a 3.2 setup and was removed by an upgrade to 3.3. Not sure how this didn't happen on yours.

It's not exactly bug #1123751.

You did run rhevm-reports-setup of 3.3, but it failed! Didn't you notice? any chance you still have the output somewhere?

I logged into your machine (found the address in the attached log), and there, in /var/log/ovirt-engine/libovirt-engine-reports-setup-2014_08_20_17_38_07.log :
================================================================================
2014-08-20 17:47:17::DEBUG::rhevm-reports-setup::851::root:: Host's FQDN: yd-dwh-reports.rhev.lab.eng.brq.redhat.com
2014-08-20 17:47:17::DEBUG::rhevm-reports-setup::928::root:: downloading certificates https://yd-dwh-reports.rhev.lab.eng.brq.redhat.com:443
2014-08-20 17:47:17::DEBUG::common_utils::1025::root:: Executing command --> '/usr/share/ovirt-engine-reports/ssl2jkstrust.py --host=yd-dwh-reports.rhev.lab.eng.brq.redhat.com --port=443 --keystore=/etc/ovirt-engine/ovirt-engine-reports/trust.jks --storepass=mypass' in working directory '/root'
2014-08-20 17:47:17::DEBUG::common_utils::1080::root:: output = 
2014-08-20 17:47:17::DEBUG::common_utils::1081::root:: stderr = Traceback (most recent call last):
  File "/usr/share/ovirt-engine-reports/ssl2jkstrust.py", line 98, in <module>
    main()
  File "/usr/share/ovirt-engine-reports/ssl2jkstrust.py", line 76, in main
    for c in getChainFromSSL((options.host, int(options.port)))[1:]:
  File "/usr/share/ovirt-engine-reports/ssl2jkstrust.py", line 28, in getChainFromSSL
    sock.connect(host)
  File "/usr/lib64/python2.6/site-packages/M2Crypto/SSL/Connection.py", line 181, in connect
    self.socket.connect(addr)
  File "<string>", line 1, in connect
socket.gaierror: [Errno -2] Name or service not known

2014-08-20 17:47:17::DEBUG::common_utils::1082::root:: retcode = 1
2014-08-20 17:47:17::ERROR::rhevm-reports-setup::1298::root:: Failed to complete the setup of the reports package!
2014-08-20 17:47:17::DEBUG::rhevm-reports-setup::1299::root:: Traceback (most recent call last):
  File "/usr/bin/rhevm-reports-setup", line 1269, in main
    updateApplicationSecurity()
  File "/usr/bin/rhevm-reports-setup", line 938, in updateApplicationSecurity
    failOnError=True,
  File "/usr/share/ovirt-engine-reports/common_utils.py", line 1085, in execCmd
    raise Exception(msg)
Exception: Return Code is not zero
================================================================================

So the root cause was that the configured fqdn yd-dwh-reports.rhev.lab.eng.brq.redhat.com
wasn't resolvable.

Entire sequence:
* 3.2 reports setup
* 3.3 reports setup failed, and its rollback wasn't perfect - in particular, it
did not restore the path [1].
* 3.4 setup was recently changed (for bug #1123751) to prevent 3.2->3.4 direct
upgrade, by checking if that path exists. It didn't, so it assumed 3.3 was
correctly setup, continued, and failed.

[1] /usr/share/jasperreports-server-pro/buildomatic/build_conf/default/dev

Currently closing WONTFIX.

Note that solving it (meaning, preventing the upgrade by adding another check in addition to that path) will not be very easy, and I do not think it's worth it. Users that ran 3.3 setup and it failed, should first make sure they fix that, then try to upgrade to 3.4.

You might try to repeat this, doing:

* 3.2 setup
* fail upgrade to 3.3 by having the fqdn un-resolvable
* make it resolvable
* try again upgrade to 3.3 (will it work?)
* try to upgrade to 3.4

If one of the last two steps do fail, we might decide to actually try harder to solve. Otherwise, if this succeeds, that's the workaround for the current bug.

BTW, as a general rule for 3.2->3.3 dwh/reports upgrade, besides the fact that it's an old release and accepts only critical security fixes, we decided that a perfect rollback isn't important, because if the engine was already upgraded to 3.3 (which is generally a must), dwh/reports 3.2 won't work with it anyway, so a rollback should only leave the system in a state that if the root cause for a failure is fixed, another upgrade attempt will be possible (and hopefully succeed).

removing old needinfo