Bug 996666 - hosts set to non operational state because of wrong rpm version
hosts set to non operational state because of wrong rpm version
Status: CLOSED DUPLICATE of bug 998488
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
3.3
Unspecified Unspecified
high Severity urgent
: ---
: ---
Assigned To: Douglas Schilling Landgraf
Haim
infra
: Regression, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-13 12:12 EDT by Arik
Modified: 2013-09-01 03:57 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-28 12:25:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Arik 2013-08-13 12:12:03 EDT
Description of problem:
Hosts switched to non operational state when their vdsm version 4.12.0-rc3.3 with error saying:
Host <host name> is installed with VDSM version (<UNKNOWN>) and cannot join cluster <cluster name> which is compatible with VDSM versions [4.9, 4.11, 4.12, 4.10].
The problem is that the rpm version reported by vdsm which is vdsm-4.12.0-rc3.3.git06ed3cc.fc18 doesn't conform the standard, thus the engine can't parse it correctly (the 'rc' should be dropped or moved after the '3.3')

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


How reproducible:
100%

Steps to Reproduce:
1. run vdsm with rpm version like mentioned above
2. add the host using the webadmin
3. activate the host

Actual results:
the host is switched to non operational state

Expected results:
the host should be switched to up state

Additional info:
Comment 1 Douglas Schilling Landgraf 2013-08-23 10:28:25 EDT
Hi,

Closing this bug since last nightly bits vdsm doesn't include that nomination.

http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/
vdsm-4.12.0-67.git978b0a4.fc18.x86_64.rpm

Feel free to re-open this bug in case you are still facing that problem and share the repo that you are using.

Thanks
Comment 2 Arik 2013-08-25 01:33:37 EDT
(In reply to Douglas Schilling Landgraf from comment #1)
> Hi,
> 
> Closing this bug since last nightly bits vdsm doesn't include that
> nomination.
> 
> http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/
> vdsm-4.12.0-67.git978b0a4.fc18.x86_64.rpm
> 
> Feel free to re-open this bug in case you are still facing that problem and
> share the repo that you are using.
> 
> Thanks

It was not reproduced (probably) because the version you were checking it with was not an 'rc' version.

I think it's wrong to close this bug without having a fix for it, because we definitely have a regression here (because of patch http://gerrit.ovirt.org/#/c/17719/, so I this bug as a 'Regression'), and we'll encounter this in the future, where we'll have 'rc' version of vdsm.

IMO, this bug should be closed only if we're saying that we won't have rpm version of vdsm with the same pattern I mentioned above anymore or fixing the bug. If we want to fix the bug and you want to reproduce it, change the vdsm rpm version to begin with vdsm-4.12.0-rc67.
Comment 3 Douglas Schilling Landgraf 2013-08-28 12:25:32 EDT
Hi Arik,

(In reply to Arik from comment #2)
> (In reply to Douglas Schilling Landgraf from comment #1)
> > Hi,
> > 
> > Closing this bug since last nightly bits vdsm doesn't include that
> > nomination.
> > 
> > http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/x86_64/
> > vdsm-4.12.0-67.git978b0a4.fc18.x86_64.rpm
> > 
> > Feel free to re-open this bug in case you are still facing that problem and
> > share the repo that you are using.
> > 
> > Thanks
> 
> It was not reproduced (probably) because the version you were checking it
> with was not an 'rc' version.

Correct.

> 
> I think it's wrong to close this bug without having a fix for it, because we
> definitely have a regression here (because of patch
> http://gerrit.ovirt.org/#/c/17719/, so I this bug as a 'Regression'), and
> we'll encounter this in the future, where we'll have 'rc' version of vdsm.

It's not a regression because of this patch, please see my comment below.

> 
> IMO, this bug should be closed only if we're saying that we won't have rpm
> version of vdsm with the same pattern I mentioned above anymore or fixing
> the bug. If we want to fix the bug and you want to reproduce it, change the
> vdsm rpm version to begin with vdsm-4.12.0-rc67.

vdsm-4.12.0-rc67 or vdsm-4.12.0-rc3.3.git06ed3cc.fc18 are not valid rpm names according to the Fedora Packaging Guidelines and it affects Engine to make host join the cluster. As soon we see it we should open a bugzilla to fix the build as this one.

Guideline;
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

"
Pre-Release packages
Non-numeric versioned "pre-release" packages can be problematic so they must be treated with care. These are cases where the upstream "pre-release" version has letters rather than simple numbers in their version. Often they have tags like alpha, beta, rc, or letters like a and b denoting that it is a version before the "final" number. Unfortunately, we cannot simply put these letters into the version tag, so we'll use the Release field for this.

Release Tag for Pre-Release Packages: 0.%{X}.%{alphatag}

Where %{X} is the release number increment, and %{alphatag} is the string that came from the version. In this case, the period '.' should be used as the delimiter between the release number increment, and the non-numeric version string. No other extra characters should appear in the Release field. This is to prevent Release values such as "3jpp_2fc.42-spotwashere".
"

Here example of valid VDSM rpm with rc in a spec file:

Version: 4.12.0
Release: 0.1.rc3.3.gitt06ed3cc%{?dist}
vdsm-4.12.0-0.1.rc3.3.git06ed3cc.fc18

With above Version/Release we shouldn't have any problem and host will join the cluster.

Please let me know if you have any additional questions.
Comment 4 Yaniv Bronhaim 2013-09-01 03:57:45 EDT
This part is duplicated of Bug 998488

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

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