| Summary: | Unable to upgrade agent plugins after a server upgrade | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Charles Crouch <ccrouch> |
| Component: | No Component | Assignee: | John Mazzitelli <mazz> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.0.0 | CC: | dvanbale, hbrock, hrupp, mazz, rsoares |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 812493 | Environment: | |
| Last Closed: | 2013-09-01 19:20:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 812493 | ||
|
Description
Charles Crouch
2012-04-18 21:17:32 UTC
I'm not sure whether the documented upgrade steps were executed, but if they were I think you would still hit the issue. I asked mazz to check what are plugin version comparator is returning comparing the 3.0.0 and 3.0.1 versions: Failed tests: foo(org.apache.maven.artifact.versioning.ComparableVersionTest): 1 should be before 2: 1=[4.2.0.JON300.GA]; 2=[4.2.0.JON.3.0.1.GA] So it looks like adding the periods to the 3.0.1 version string made it appear lexiographically before the 3.0.0 version. We'll need to investigate a fix to 3.0.1 to address this. It appears the new version string format is bad and results in RHQ thinking the new version is actually older. Our old version: 4.2.0.JON300.GA Our new version: 4.2.0.JON.3.0.1.GA Those added "." characters in the new version format is causing the version check algorithm to think the 3.0.1 version is older than the 3.0.0 version. Here's the problem - our version checking algorithm never expected a version inside a version. Here we have 4.2.0 and that is the version we parse (that is the major.minor.patch). But then we have this JON string that follows which is in the place of where "GA" or "RC" or something similar is supposed to go (based on our version syntax rules we use). Following "JON" we have ANOTHER apparent version string that we are somehow magically expecting RHQ to parse and understand as a major.minor.patch version string. That's not what is happening. We parse major.minor.patch that we see in the beginning - if something follows, we don't parse it as a SECOND version string - we look at it as the GA or RC or similar marking. (thus JON300.GA is compared to JON.3.0.1.GA - we do NOT see this as 3.0.0 compared to 3.0.1). My proposal to work around this is to simply hardcode a check for "4.2.0.JON.3.0.1.GA" and in-memory change it to 4.2.0.JON301.GA to match our older version format. We should then release future versions by continuing our version format. Either that or change "4.2.0.JON300.GA" to "4.2.0.JON.3.0.0.GA" in memory and continue with our new version format. We need to hardcode the fix to make this easily patched WITHOUT screwing up third-party/community plugins that are following our current version syntax rules. We then need to ensure our next release(s) use version strings that are compared as we expect them. The code for this (and a unit test) is ComparableVersion[Test] git commit to master b83f264 after some back and forth, in the end, this commit simply introduces a hack that converts the old version string to the better, new one. This limits the impact and therefore has less risk. Was thinking about introducing a customization feature where we can add bad versions to some XML file so if this happens again we can just update the XML with the bad versions. But that would require storing that file on all servers in the HA cloud and the question is where to put the file. In the end, didn't waste more time on this by implementing a more complicated solution - we just modify ComparableVersion so it hardcodes the bad version and converts it to the good. There is a unit test method that checks that it works. I tested JON 3.0.0 -> JON 3.0.1 upgrade - specifically looking at RHQ_PLUGIN table and watched the version column get upgraded as the new plugins got deployed and updated. moving back to on_dev - after discussing with ccrouch, we are going to change the version strings in the future back to what they were before - no dots in the JON version string. So in the hack, we'll convert the JON.3.0.1.GA to JON301GA. (In reply to comment #4) > moving back to on_dev - after discussing with ccrouch, we are going to change > the version strings in the future back to what they were before - no dots in > the JON version string. So in the hack, we'll convert the JON.3.0.1.GA to > JON301GA. git commit to master 32137ba this also adds a set of unit tests that check versions from past, current and several future versions of RHQ and JON. git commit to master 56eb5ef - i messed up the version string in the test for 3.0.2. this fixes it. we want to match exactly what we will be using Bulk closing of BZs that have no target version set, but which are ON_QA for more than a year and thus are in production for a long time. |