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:
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
(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.
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.
This part is duplicated of Bug 998488 *** This bug has been marked as a duplicate of bug 998488 ***