Bug 916380 - add dbupgrade step to fix problem when an old bundle version was deleted in previous JON version
add dbupgrade step to fix problem when an old bundle version was deleted in p...
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: Provisioning (Show other bugs)
JON 3.0.1
All All
medium Severity medium
: ER01
: JON 3.2.0
Assigned To: John Mazzitelli
Mike Foley
:
Depends On: 826995 826998
Blocks: 828905
  Show dependency treegraph
 
Reported: 2013-02-27 18:40 EST by Charles Crouch
Modified: 2015-02-01 18:28 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 826995
Environment:
Last Closed: 2014-01-02 15:43:06 EST
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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 133893 None None None Never

  None (edit)
Comment 1 Charles Crouch 2013-02-27 18:49:20 EST
This bug is meant to capture the work needed to make sure that people who ran into the original problem (i.e. delete a bundle version then upload a new bundle version) on an older version of JON will not need to execute any custom SQL to resolve the issue once they have upgraded to JON320.

[This is distinct from 826995 which made sure that if you were running JON311 that you could no longer get into a bad state simply by deleting then uploading a new bundle version).
Comment 2 John Mazzitelli 2013-02-28 15:31:38 EST
git commit to master: 9759daf74bf650e13764d80ef8fc4f67d1b8d269

To test this, you first have to get the database table rhq_bundle_version in a bad state. you can either follow the directions in this issue's description (From a JON 3.0.1 install, upload a bundle version 1, then a bundle version 2, then delete bundle version 1, then upload bundle version 3) or you can just artificially mess with the ordering by executing this simple UPDATE SQL - "update rhq_bundle version set version_order=2" (you do this against your database that already has a bundle versions in the db - if you do not, then you must upload some).

Note that to really test this, you need to have more than one bundle in the database. So, for example, upload 3 bundle versions for bundle "foo" and upload 3 bundle versions for bundle "bar". You then delete both bundle version #2 for each bundle (or just run that SQL UPDATE to artificially alter them that simulates the bug).
Comment 3 John Mazzitelli 2013-02-28 15:35:32 EST
(In reply to comment #2)
> git commit to master: 9759daf74bf650e13764d80ef8fc4f67d1b8d269
> 
> To test this, you first have to get the database table rhq_bundle_version in
> a bad state. you can either follow the directions in this issue's
> description (From a JON 3.0.1 install, upload a bundle version 1, then a
> bundle version 2, then delete bundle version 1, then upload bundle version
> 3) or you can just artificially mess with the ordering by executing this
> simple UPDATE SQL - "update rhq_bundle version set version_order=2" (you do
> this against your database that already has a bundle versions in the db - if
> you do not, then you must upload some).
> 
> Note that to really test this, you need to have more than one bundle in the
> database. So, for example, upload 3 bundle versions for bundle "foo" and
> upload 3 bundle versions for bundle "bar". You then delete both bundle
> version #2 for each bundle (or just run that SQL UPDATE to artificially
> alter them that simulates the bug).

Of course, to test the fix, after you get the bundle versions in a bad state, you must then install/upgrade to the latest version such that the db-upgrade is triggered (and thus the fix is run).

So:

1) get several bundles uploaded as per instructions above
2) make sure you have the db in a bad state by making sure this SQL returns at least 1 row:

select name, version_order, count(version_order)
  from rhq_bundle_version t1
  group by name, version_order
 having count(version_order) > 1;

3) install the latest version which will run the db upgrade
4) once the db upgrade is run, if you look in RHQ_BUNDLE_VERSION, all the version_order column values should now be valid. You will know its fixed if this SQL returns 0 rows now:

select name, version_order, count(version_order)
  from rhq_bundle_version
  group by name, version_order
 having count(version_order) > 1;
Comment 4 Larry O'Leary 2013-09-06 10:31:37 EDT
As this is MODIFIED or ON_QA, setting milestone to ER1.

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