Bug 1170229

Summary:	Issues with rename
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Yedidyah Bar David <didi>
Component:	ovirt-engine	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	movciari
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.5.0	CC:	bazulay, didi, eedri, gklein, lsurette, rbalakri, Rhev-m-bugs, sbonazzo, sherold, yeylon, ykaul, ylavi
Target Milestone:	ovirt-3.6.0-rc	Keywords:	ZStream
Target Release:	3.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1181651 1181691 (view as bug list)		Environment:
Last Closed:	2016-03-11 07:33:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1181691

Description Yedidyah Bar David 2014-12-03 14:25:55 UTC

Description of problem:

/usr/share/ovirt-engine/setup/bin/ovirt-engine-rename fails with:

[ ERROR ] Failed to execute stage 'Misc configuration': Cannot locate application option RedirectServletReportsPage

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

3.5

How reproducible:

Always

Steps to Reproduce:
1. see above
2.
3.

Actual results:

failure

Expected results:

success

Additional info:

This option was dropped in 3.5 while working on supporting setup of reports on a separate host. It was replaced with a setting in a conf file.

I pushed a patch to gerrit but didn't verify it yet. I didn't run rename lately, there might other issues with it.

Comment 1 Yedidyah Bar David 2014-12-08 15:26:22 UTC

Verified that the patch in gerrit works. That is, the rename tool finishes without error.

Then checked if the old name still appears anywhere. Found it in these places:

1. /etc/ovirt-engine/engine.conf.d/10-setup-reports-access.conf, in the line ENGINE_REPORTS_BASE_URL

This one probably does require a fix to make reports work after a rename.

2. in the engine db, table 'dwh_history_timekeeping', row 'dwhHostname' is not updated.

IIRC this affects only reporting (logs etc) and not actual logic.

Both were fixed by running 'engine-setup'.

Comment 2 Yedidyah Bar David 2014-12-09 13:41:34 UTC

Moving back to post because the reports file is not finished yet

Comment 3 Eyal Edri 2014-12-10 11:18:26 UTC

following a discussion with the developer, understanding this is not urgent and far from a blocker, moving to 3.5.1, since this won't make it to the last build date.

Comment 5 Sandro Bonazzola 2014-12-11 07:52:49 UTC

Re-targeting to 3.5.1 and drop from blockers as per comment #3.

Comment 6 Yaniv Lavi 2014-12-23 14:00:24 UTC

Why is this not MODIFIED yet?

Comment 7 Yedidyah Bar David 2014-12-23 22:55:45 UTC

(In reply to Yaniv Dary from comment #6)
> Why is this not MODIFIED yet?

Not sure, I guess I wanted to wait until we decide about the localhost special case of http://gerrit.ovirt.org/35473 . Moving to MODIFIED, we can always fix again rename if we decide we need to, which we currently decided we do not.

Comment 8 Yedidyah Bar David 2015-01-13 14:29:33 UTC

Another issue:

1. engine-setup, configure also websocket-proxy, configure 'Red Hat Access Plugin' (you must reply yes or no, either counts)
2. rename
3. engine-setup - asks again about websocket-proxy, asks again about 'Red Hat Access Plugin'.

Moving to POST.

Comment 10 movciari 2015-11-26 17:14:12 UTC

after calling the rename utility, old name still appears in /etc/ovirt-engine/ovirt-vmconsole-proxy-helper.conf.d/10-setup.conf in variable ENGINE_BASE_URL
this should be changed, right?

Comment 11 Yedidyah Bar David 2015-11-29 07:46:57 UTC

(In reply to movciari from comment #10)
> after calling the rename utility, old name still appears in
> /etc/ovirt-engine/ovirt-vmconsole-proxy-helper.conf.d/10-setup.conf in
> variable ENGINE_BASE_URL
> this should be changed, right?

Indeed, thanks for catching this. But please open another bug, even though current one was "designed" to catch all known issues at the time.

We should probably have an automated test in QE/CI to catch such things.