Bug 679139
| Summary: | RFE: A supported wallaby db patching tool | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Robert Rati <rrati> | |
| Component: | wallaby | Assignee: | Robert Rati <rrati> | |
| Status: | CLOSED ERRATA | QA Contact: | Lubos Trilety <ltrilety> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | high | |||
| Version: | Development | CC: | iboverma, jneedle, ltrilety, matt, mkudlej, willb | |
| Target Milestone: | 2.1 | Keywords: | FutureFeature | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | wallaby-0.10.7-1 | Doc Type: | Enhancement | |
| Doc Text: |
The new remote configuration base database packages contain fixes and updates that must be loaded into wallaby in order to take effect. However, loading a database replaces the contents of wallaby, which could have caused user changes to be removed. These updated packages include a wallaby shell command that allows the database to be upgraded so that new versions of the remote configuration base database package can be applied to an existing system without removing a customized configuration.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 706967 (view as bug list) | Environment: | ||
| Last Closed: | 2012-01-23 17:25:55 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 706967, 743350 | |||
|
Description
Robert Rati
2011-02-21 17:44:11 UTC
Added on branch: BZ679139-patching-tool Merged to master
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
C: New remote configuration base db packages contain fixes and updates that must be loaded into wallaby to take affect.
C: Loading a database will replace the contents of wallaby, thus removing any customer changes.
C: Created a wallaby shell command that allows upgrading a database.
R: Changes from new versions of the remote configuration base db package can be applied to an existing system without destroying customer changes.
Tested on: wallaby-0.12.0-1 What is the option -f (--force) good for? I didn't see any difference when I use it or not. The database upgrade command uses patches that contain expected values for the entities they are updating, and will only update if the expected value is the same as the current value in the database. For example, if the patch is updating the description on a parameter, then the patch will contain an "expected" value for the parameter's description in addition to the new value. If the value in the database is different than the expected value, the tool will error out. This is because a user is free to change the database as they like, and we aren't going to overwrite their changes without their consent. The -f option will force the upgrade, meaning the tool will ignore differences between the "expected values and the current values in the database and perform the updates. (In reply to comment #6) > The database upgrade command uses patches that contain expected values for the > entities they are updating, and will only update if the expected value is the > same as the current value in the database. For example, if the patch is > updating the description on a parameter, then the patch will contain an > "expected" value for the parameter's description in addition to the new value. > If the value in the database is different than the expected value, the tool > will error out. This is because a user is free to change the database as they > like, and we aren't going to overwrite their changes without their consent. > The -f option will force the upgrade, meaning the tool will ignore differences > between the "expected values and the current values in the database and perform > the updates. In that case I think it should also check if there is not the same item as added one. User can accidentally use the same name. E.g. --- before patch 1.15 add CAROD # ccs -l -p CAROD Parameter "CAROD": Name: CAROD Type: string Default: test value Description: test description MustChange: False VisibilityLevel: 0 RequiresRestart: False Dependencies: Conflicts: --- after successful upgrade db without '-f' option # ccs -l -p CAROD Parameter "CAROD": Name: CAROD Type: String Default: $(SBIN)/carod Description: The location of the carod daemon MustChange: False VisibilityLevel: 0 RequiresRestart: True Dependencies: Conflicts: Agreed the command should check for existing parameters before adding them. Please log a BZ for that. Tested with: wallaby-0.12.0-1 Tested on: RHEL5 x86_64, i386 RHEL6 x86_64, i386 For issue in Comment 7 a new Bug 748826 was created. No other issues were found. >>> VERIFIED
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,4 +1 @@
-C: New remote configuration base db packages contain fixes and updates that must be loaded into wallaby to take affect.
+The new remote configuration base database packages contain fixes and updates that must be loaded into wallaby in order to take effect. However, loading a database replaces the contents of wallaby, which could have caused user changes to be removed. These updated packages include a wallaby shell command that allows the database to be upgraded so that new versions of the remote configuration base database package can be applied to an existing system without removing a customized configuration.-C: Loading a database will replace the contents of wallaby, thus removing any customer changes.
-C: Created a wallaby shell command that allows upgrading a database.
-R: Changes from new versions of the remote configuration base db package can be applied to an existing system without destroying customer changes.
*** Bug 706967 has been marked as a duplicate of this bug. *** 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. http://rhn.redhat.com/errata/RHEA-2012-0045.html |