Bug 1206068 - Mismatch between engine version and full version all APIs
Summary: Mismatch between engine version and full version all APIs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Ori Liel
QA Contact: Karolína Hajná
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-26 09:24 UTC by Israel Pinto
Modified: 2016-03-09 21:01 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 21:01:04 UTC
oVirt Team: Infra


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 39906 master ABANDONED restapi: Fix possible version mismatch (#1206068) Never
oVirt gerrit 40085 master MERGED restapi: Fix possible version mismatch (#1206068) Never

Description Israel Pinto 2015-03-26 09:24:56 UTC
Description of problem:
Connect via REST API to http://<engine>/api
in the response there is mismatch between version and full version, like:
<version major="3" minor="5" build="0" revision="0"/>
<full_version>3.5.1-0.2.el6ev</full_version>

Actual results:
mismatch between version and full version

Expected results:
The version match the full version

It also happens in other APIs

Comment 1 Juan Hernández 2015-03-30 10:02:14 UTC
The RESTAPI gets the value of the "version" attribute from the "VdcVersion" configuration option, so that is what needs to be fixed. To verify please check the result of the following:

  # rhevm-config -s VdcVersion=3.5.1.0
  # service ovirt-engine restart

Then try again to get the version from the RESTAPI, it should be 3.5.1.0.

Comment 2 Israel Pinto 2015-03-30 10:17:02 UTC
I checked it and it works.
Steps:
1. set version with rhevm config: rhevm-config -s VdcVersion=3.5.1.0
2. service ovirt-engine restart
3. Get version with REST: 
<version major="3" minor="5" build="1" revision="0"/>
<full_version>3.5.1-0.2.el6ev</full_version>

It is engine problem with the vds version.

Comment 3 Oved Ourfali 2015-04-12 13:14:50 UTC
According to the code, the VdcVersion (version) and ProductRPMVersion (full_version), are both set for the 3.5.0.0.
Where are you getting 3.5.1-0.2.el6ev?
Can we access the installation?

Comment 4 Israel Pinto 2015-04-12 13:47:07 UTC
Connect via REST API to http://<engine>/api
look for:
<version major  ....>
<full_version> ..</full_version>

Comment 5 Oved Ourfali 2015-04-12 13:49:14 UTC
(In reply to Israel Pinto from comment #4)
> Connect via REST API to http://<engine>/api
> look for:
> <version major  ....>
> <full_version> ..</full_version>

I understand that.... I was asking where did you see that? in what version? what build?

Comment 6 Israel Pinto 2015-04-12 14:00:18 UTC
vt14.1

Comment 7 Yedidyah Bar David 2015-04-15 10:02:58 UTC
(In reply to Oved Ourfali from comment #3)
> According to the code, the VdcVersion (version) and ProductRPMVersion
> (full_version), are both set for the 3.5.0.0.
> Where are you getting 3.5.1-0.2.el6ev?

It's set by engine-setup [1].

[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/config/plugins/ovirt-engine-setup/ovirt-engine/config/options.py;h=8acf431b4d390e6bf0c9b526cd5a21bc8334c820;hb=HEAD#l156

Comment 8 Ori Liel 2015-04-16 09:10:29 UTC
Patch posted: 

  https://gerrit.ovirt.org/#/c/39906/1

Comment 9 Yedidyah Bar David 2015-04-16 09:38:35 UTC
(In reply to Israel Pinto from comment #0)
> Description of problem:
> Connect via REST API to http://<engine>/api
> in the response there is mismatch between version and full version, like:
> <version major="3" minor="5" build="0" revision="0"/>
> <full_version>3.5.1-0.2.el6ev</full_version>
> 
> Actual results:
> mismatch between version and full version
> 
> Expected results:
> The version match the full version

Why?

> 
> It also happens in other APIs

Please see also bug 905398.

Comment 10 Ori Liel 2015-05-05 10:33:12 UTC
Patch merged: 

  https://gerrit.ovirt.org/#/c/40085/

Comment 11 Sandro Bonazzola 2015-05-06 06:12:09 UTC
Ori, why has the patch been merged? There's an open needinfo on Israel Pinto about this change being not needed.

Comment 12 Oved Ourfali 2015-05-06 07:26:40 UTC
(In reply to Yedidyah Bar David from comment #9)
> (In reply to Israel Pinto from comment #0)
> > Description of problem:
> > Connect via REST API to http://<engine>/api
> > in the response there is mismatch between version and full version, like:
> > <version major="3" minor="5" build="0" revision="0"/>
> > <full_version>3.5.1-0.2.el6ev</full_version>
> > 
> > Actual results:
> > mismatch between version and full version
> > 
> > Expected results:
> > The version match the full version
> 
> Why?
> 
> > 
> > It also happens in other APIs
> 
> Please see also bug 905398.

It makes no sense to write build = 0 when we refer to 3.5.1.
The fix addresses that.

Comment 13 Yedidyah Bar David 2015-05-06 07:40:47 UTC
(In reply to Oved Ourfali from comment #12)
> (In reply to Yedidyah Bar David from comment #9)
> > (In reply to Israel Pinto from comment #0)
> > > Description of problem:
> > > Connect via REST API to http://<engine>/api
> > > in the response there is mismatch between version and full version, like:
> > > <version major="3" minor="5" build="0" revision="0"/>
> > > <full_version>3.5.1-0.2.el6ev</full_version>
> > > 
> > > Actual results:
> > > mismatch between version and full version
> > > 
> > > Expected results:
> > > The version match the full version
> > 
> > Why?
> > 
> > > 
> > > It also happens in other APIs
> > 
> > Please see also bug 905398.
> 
> It makes no sense to write build = 0 when we refer to 3.5.1.
> The fix addresses that.

It does, if this is our "api compatibility version", if we have such a thing.

I read the discussion on bug 905398 and can't clearly understand if we have such a thing, if we intend to have such a thing, etc.

Are client applications expected to check this version and decide what's supported/unsupported accordingly? Do we publish this anywhere? Or is this just for reporting?

What do we have VdcVersion for, then? Do we publish or check it anywhere?

Comment 14 Oved Ourfali 2015-05-07 10:51:58 UTC
Juan - do you have information on who uses <version> and for what reason?

Comment 16 Juan Hernández 2015-05-07 11:11:43 UTC
(In reply to Yedidyah Bar David from comment #13)
> It does, if this is our "api compatibility version", if we have such a thing.

It isn't, the version numbers presented here, both "version" and "full_version", are informative only, they don't have any meaning other than identifying the version of the product.

> I read the discussion on bug 905398 and can't clearly understand if we have
> such a thing, if we intend to have such a thing, etc.

We don't have such a thing and we don't have short term plans to have it.

> Are client applications expected to check this version and decide what's
> supported/unsupported accordingly? Do we publish this anywhere? Or is this
> just for reporting?

Applications can check this version, but they aren't expected or required to do it, and as far as I know no application does so, including our own SDKs and CLI. 

Applications can cross check this information with the information available in the /capabilities resource, where we list the features of each X.Y version. However the information about features available in the /capabilities resource is basically textual, hard to consume for applications, so I think that no application is actually using it.

Comment 17 Karolína Hajná 2015-05-25 11:31:28 UTC
verified on 3.6.0-0.0.master.20150519172222.git9a2e2b3.el7

Comment 18 Oved Ourfali 2015-11-24 06:40:12 UTC
*** Bug 1284654 has been marked as a duplicate of this bug. ***

Comment 20 errata-xmlrpc 2016-03-09 21:01:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html


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