Description of problem: For an engine that was upgraded from 4.2.6 to 4.2.7 and was running also as earlier versions (starting 3.1), the ImageProxyAddress key in vdc_options doesn't get updated with the engine FQDN. We guess that ImageProxyAddress key never existed while the engine was initlially installed (aroud RHV 3.1) so when it was updated to a version that added this key, the key was set with a default value - 'localhost:DEFAULT_IMAGEIO_PORT'. Version-Release number of selected component (if applicable): Current version - rhvm-4.2.7.4-0.1.el7ev.noarch This engine was updated many times, starting somewhere around RHV 3.1 Not sure which info is relevant here, please raise a need-info if any additional info is required.
Daniel, is this our realm or integration?
(In reply to Tal Nisan from comment #1) > Daniel, is this our realm or integration? @Asaf - could it be related to bug 1519194? is it a similar code perhaps?
Didi, can you please have a look?
Please attach sosreport from the engine vm. Thanks. Can mark as private if it's a production system.
The guess in comment 0 seems accurate. The code updating vdc_options indeed runs only on new setups, not on upgrade. It was added to fix bug 1342322. The code was mostly copied from similar code for websocket-proxy, so we likely have the same bug about vdc option 'WebSocketProxy'. Fixing is trivial - just removing the condition on NEW_DATABASE. But is this what we want? In particular: What if the user manually changed it? This can happen due to several reasons, not only rename - e.g. they might have several IP addresses on the machine and want to use a specific one for the imageio proxy, so set to a name that resolves to this address. I might agree to changing it if it's set to 'localhost', but not certain this is a good idea either.
Can we compare engine FQDN with content of the vdc option during configuration step and ask if we want it updated or not in next stages? So if user changed it on purpose we won't overwrite the change and if it comes from previous versions that missed the key user can fix it as part of the upgrade.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
(In reply to Avihai from comment #9) > Hi Didi, > > As we do not have the original setup with multiple upgrades I did the > following on 4.3.2.1(with ovirt-imageio-1.5.1) engine: Please start from a 4.1 engine and upgrade it to 4.2 then 4.3. If not done already, please open a bug/ticket in QE to have this and similar upgrade flows checked automatically. I realize this will require quite a lot of work, but IMO will be worth it. > > 1) I set via engine-config 'ImageProxyAddress' to 'localhost' This is incorrect. The code (both that inserts this key and that uses this key) uses host:port, not only host. Specifically, the upgrade code (with the fix for current bug) will change the key only if it's exactly 'localhost:54323'. But please do not rely on this, and start from 4.1 as suggested above. Verify that in the upgrade to 4.2 it's not updated (that's current bug), then that upgrade to 4.3.2 updates it (so it's fixed). Thanks.
Verified on ovirt-imageio-proxy-setup-1.5.1-0.el7ev.noarch
This bugzilla is included in oVirt 4.3.2 release, published on March 19th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.